RE: Where should guile modules store meta data?

["Redford, John" <John.Redford@fmr.com>]

[Pardon the MS-centric format]

There are multiple questions here:
	Should interfaces be human readable?
	Should implementations be in the same files as interfaces?

For compiled languages, it is possible to make the only human-readable
interface be the documentation (perhaps auto-generated from the library
itself). When this is the case, it maximizes the integrity of the library.
This is in contrast to C, where interfaces are exposed in human readable
(and modifiable) header files. I am sure that everyone here has modified a
system header at some point, perhaps to change the typing of a function or
to add a prototype. That modification was likely beneficial, but it
contaminates the interface. Given a language with sufficiently late binding
and link-time initialization hooks, it is not necessary to modify interfaces
through editing. If an interface is not human readable, it need not be
distinct from the implementation.

Guile, so long as it is not compiled, does not have to worry about this.

The second question also is more involved for a pre-compiled language than
for a run-time parsed language. A distinct interface is a great benefit for
the author of the library because it permits complete freedom in
implementation of the interface. When implementation details are exposed, as
in C++ with 'private' data declarations, the holders of the interface both
have more information than they should have, and the author is forced to
change what they have if the implementation changes. There is no good reason
why an author should have to publicize the addition of a private data member
to an object (yes, I know why this is done - clients need to know the size
of objects for allocation on the stack; a bad reason, IMHO; it could at
least be made optional for objects meant to be heap allocated).

The other major benefit for compiled languages is that development may
proceed in parallel. It is possible to publish interfaces for a non-existent
implementation to permit others to begin coding.

Again, for Guile, there is no compelling reason to separate interface from
implementation. It is not compiled, and I do not think there are large
development efforts that would benefit from parallelism in the coding
process (a benefit you can get on the cheap simply by writing documentation
before you write code!).

There are many reasons for hiding implementations. The main one is to keep
people from making assumptions that what is true for one implementation will
be true for all others. However, there is another benefit, which is that a
person reading an interface with no implementation details does not get
distracted by extra information.

Lastly, I just wanted to comment that I don't find anything 'modern' in the
single-file option. Certainly not in the sense of being superior to a two
file system.

	-----Original Message-----
	From:	Jost Boekemeier [SMTP:jostobfe@calvados.zrz.TU-Berlin.DE]
	Sent:	Wednesday, June 02, 1999 8:12 AM
	To:	guile@cygnus.com
	Subject:	Where should guile modules store meta data?


	In traditional languages like C these where two separate files.  The
	advantage is that you can publish the interface without showing how
	things where implemented.  The disadvantage is that you have to
maintain
	two separate files.

	Modern languages like Java and Oberon do not use two separate files
	but instead store the information what is visible the the world
	inside the implementation file:

	With the new environment implementation we can have both.  A module
	system like scheme48's or a more modern module/package system that
doesn't
	split the module's declarations and definitions into two separate
files.

	My question is:  Should meta data (information about what is visible

	to the world, what package this module belongs to etc.)  be stored
	in a separate  file or should this information be part of module
itself?  
	How should guile's primary module interface look like?