What was the distinction between module interface files and module implementation files before Oberon?

Question

I'm reading the book "The Go Programming Language" and this sentence in the preface section "The Origins of Go" has me puzzled:

One major stream of influence comes from languages by Niklaus Wirth, beginning with Pascal. Modula-2 inspired the package concept. Oberon eliminated the distinction between module interface files and module implementation files. Oberon-2 influenced the syntax for packages, imports, and declarations, particularly method declarations.

As with several other concepts which are mentioned in passing only to point out that Go doesn't have them, I'm looking around to get a high-level idea of what this means. I have searched the web a bit for "module interface vs module implementation," but found nothing promising. I skimmed through the Oberon Wikipedia article, but as it's mentioned that this distinction was eliminated in Oberon, I wasn't too hopeful about that resource in the first place.

I understand modules to some extent — I've already read many chapters of "The Go Programming Language" and I've previously done some fooling around in Python — but I am not sure what is meant by "module interface files" and "module implementation files" or what code might have looked like before this distinction was eliminated.

Can someone please fill me in on the background of this concept so I can understand this sentence more fully?

(I can guess—but it's complete speculation—that maybe in previous languages (which?), the API for a module would have to be declared separately from the actual code which made it work, something like the rule in some languages that variables must be declared before they can be initialized. But I don't like inventing details when I really don't know.)

Answer 1

From what I recall of the long-gone university days of using Oberon: yes, you're quite right. A module interface file is nothing but the public declarations of a module separated into an external file, to encourage reasoning about the contract of a module rather than its implementation.