Re: Where should guile modules store meta data?

[Clark McGrew <mcgrew@ale.physics.sunysb.edu>]

>>>>> "Jost" == Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

I've chopped pretty brutally, but this highlights my point...

    Jost> This may be easier for the user but I like the two files
    Jost> solution better.

If the one file solution is easier for the user that's a pretty
conclusive argument for it.  Guile is an extension language so it's
module system is exposed to the user.

I also think it's important to be able to create and extend modules
from the keyboard.  How would that be done in a two file system.

    Jost> module == file + interface 

module == interface + implementation is closer.

A file only makes since in the context of a file system.  

    Jost> It is (and should) be impossible
    Jost> to write several modules in a single file.

Why?  I still don't understand what the connection between a file and
a module.  A file is a collection of data.  A module is a programming
construct.  It's true that the data describing a module will usually
exist in a file, but that is about as far as it goes. 

    Jost> A package is a directory with several modules using each
    Jost> others interface and exporting protected variables to each
    Jost> other.

A directory is a file system concept.  A package is a collection of
modules.  Clearly directories are a convenient way to implement a
package, but a directory is not equivalent to a package.

    David> One weakness of the current module system is that the notation
    David> does not delimit the extent of a define-module, but rather
    David> knows when one define-module is done by the fact that (a)
    David> another define-module starts or (b) an end-of-file is
    David> encountered. This muddles the distinction between files and
    David> modules. I wouldn't mind a notation where the implementation of
    David> the module is contained inside the define-module form, just as
    David> it is for ordinary define's; it would be a lot cleaner.

I suppose that a fully paren'ed syntax might have nicer theoretical
properties.  The current notation has the advantage of being easy on
the simple user.  One possible solution is to have a module delimited
by a finish-module form or an end of file.

Using the syntax of the old module system from the keyboard or in a
file it might work like this:

(define-module (my hack))
(use-modules (my other hack))
(define a 134)
(define b (lambda () a))
(export b)
(finish-module)

Cheers,

Clark