Re: Modules and interfaces

[Simon L Peyton Jones]

The goal of having a human-written interface is to give the programmer the
opportunity to say (and document) just what the interface of a module is.  I
think of this as analogous to specifying a type signature for a function...
often illuminating, but should not be obligatory.  Especially when
writing abstract data types I'd like to be able to write a signature
for a module, but currently I have no way to do so that is (a) part of the
language and hence in some standard form, and (b) checked.

Machine written/read ones are fine for conveying info between compilation
units, but they don't need to be specified as part of the language.  Current
Haskell 1.2 interface files sit uneasily between the two worlds.

Simon

| From: [EMAIL PROTECTED] (F. Warren Burton)
| Date: Tue, 26 Sep 1995 16:22:34 -0700
| Simon and John,
| 
| In practice, when do you want an interface other than the automatically
| generated one?  In practice, except in the case of mutual recursive
| modules, do you ever need to modify an interface in order to get a program
| to do what you want?  In theory, to what extent can the information in an
| interface file differ from what a compiler would generate?  Do you look at
| an interface file while writing a module that uses the interface?
| 
| I have only recently realized that I am not really clear on the purpose of
| interface files!  Am I the only one on the committee who is a bit confused?
| 
| Warren
| 
| 

Re: Modules and interfaces

[F. Warren Burton]

Simon and John,

In practice, when do you want an interface other than the automatically
generated one?  In practice, except in the case of mutual recursive
modules, do you ever need to modify an interface in order to get a program
to do what you want?  In theory, to what extent can the information in an
interface file differ from what a compiler would generate?  Do you look at
an interface file while writing a module that uses the interface?

I have only recently realized that I am not really clear on the purpose of
interface files!  Am I the only one on the committee who is a bit confused?

Warren

Re: Modules and interfaces

[Peter Thiemann]

Hi all,

as I am also a former sufferer from Modula-2's module system I'd like
to support Manuel's opinion.  But we do not need to reinvent the
wheel, Wirth already corrected some problems with modules in M-2 in
the design of Oberon! The idea is that each module is just *one* piece
of human written code. This ensures that all information is gathered
in one place and therefore in sync. Now if you want to export
something you have to attach an EXPORT MARKER (which is * in the case
of Oberon) to it.

Interface files are *automatically* generated by a browsing tool which
extracts the items marked for export. They are never read by the
compiler, they are only intended for documentation purposes. [A real
development system would probably generate them on-the-fly from a
source code database; without revealing the implementation code, of
course] The compiler generates binary symbol files which are *only*
used to convey low-level information between separate compilation
steps which is a GOOD THING imho (as it speeds processing of imports).

This scheme should be rather simple to implement as it is *not*
radically different from the current design. The changes involved are:
- introduce markers for exported stuff (might be tricky given the
  number of symbols already in use, but * or . might work out. I could
  also imagine some interference with infix stuff)
- I'd second Manuel's proposal to mark comments for inclusion into the
  interface: this makes the generated interface description really useful 
- implement an "interface browser" which extracts the interface: this
  is just a hacked down version of the parser
- In an intermediate phase, the old interface files could be used as a
  substitute for the symbol files.
In summary, it's very simple to understand and implement, it is tested
by lots of Oberon users, improves the code duplication issue, and
breaks every program using modules (but then, which proposal
doesn't?).

I include a short excerpt of an Oberon module below, just for the flavor.

-Peter

==
MODULE Boards;

CONST
   fsfs = 10;  (* a private constant *)

  TYPE
Board* = POINTER TO BoardDesc;
Note* = POINTER TO NoteDesc;
BoardDesc* = RECORD
 list1, list*: Note;
 list2 : SET;
END;

(* Board, Note, and BoardDesc are exported types,
   only the "list" field of BoardDesc is externally visible, not the
   list1 and list2 fields *)

(* ... *)

Reader* = RECORD
N: Note;
END;

CONST   (* exported constants *)
poste* = 0;  discard* = 1;  move* = 2; toTop* = 3;  BoardFileId = 31697;

VAR (* private variables *)
minW, minH: INTEGER;  (* minimal size of a note *)

(* a private procedure *)
PROCEDURE Max (i, j: INTEGER): INTEGER;
BEGIN IF i = j THEN RETURN i ELSE RETURN j END
END Max;

(* ... *)

(* an exported procedure *)
PROCEDURE Poste*(B: Board; N: Note);
VAR M: UpdateMsg;
BEGIN
Append(B, N);
M.id := poste;  M.note := N;  M.board := B;
Viewers.Broadcast(M);  (* send poste message *)
END Poste;

(* ... *)

BEGIN
minW := 20;  minH := 15;  
END Boards.