Re: A new module system for Guile

[Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE>]

Hi Clark,


> keep the same high level user interface

By using these patches it shall be possible to create a module system
that looks like the current module system.

But please don't look at the syntax at the moment. What is more
important and what distinguishes my module system from others [1,2]
is that in this module system a module is _not_ a first-class object. A
module doesn't have a type, you can't create a new module at run-time and
you can't pass it as an argument to a function, it is just a synthetic
construct that encapsulates a collection of top-level bindings. Thus
allowing separate compilation and a separate name space.

Every module has a unique ID that distinguishes it from every other
module. Since guile sits on top of an operating system we can exploit
the unix file system abstraction to avoid name clashes: Programmer A
can contribute a module "A" and can put other modules into his private
subdirectories (e.g. "A/mod1") so can programmer B. The collection of
"A" with all its subdirectories "A/mod1", "A/mod2", "A/B/mod" etc. is
called a "package".  ("compound interface" in scheme48).

When the module system is finished, we should create a type/object
system for guile (based on structs), including signatures,
polymorphism, renaming of symbols, multiple inheritance and -- nested
objects if people want it (like java :>).

But it is important to differentiate between the module system and
the object system -- the authors of the current module system and 
the systems described in [1, 2] failed to do so.



> Personally I prefer using "define" and "export".  Can "export" be
> incorporated?

Yes, all we have to do is to create a symbol and set its "public" flag.
I will drop `define*' since all symbols have to be either public or
private. It should not be possible to `undefine' a public symbol and 
then define it as private.

And later, when the Object/Type system is finished, it would be nice if we
can specify the type of the exported symbols (as in [2]).


[instead of `module.symbol']
> (display (module-ref somewhere there))

Yes. Thanks. :)) Although this is a less general approach I like it, since it
makes the implementation simpler.


> translates to lnx05.tfh-berlin.de and then gives "service not

Hmm, maybe a firewall?

$ ftp -ni lnx05.tfh-berlin.de <<\end
> user ftp jost@
> cd pub/incoming
> ls
> end
total 106
drwxrwx---   3 ftpusr   ftpgrp       1024 Sep 27 19:51 .
drwxr-xr-x  10 ftpusr   ftpgrp       1024 Sep 30 04:30 ..
-r--r--r--   1 ftpusr   ftpgrp        288 Aug 13 13:27 .message
drwx------   2 chef     system      12288 Aug 13 13:04 lost+found
-rw-rw----   1 nobody   ftpgrp      92160 Sep 27 19:51 module.tar
$ 


Regards,
Jost

[1] /ftp@ftp.cs.hmc.edu:/pub/fleck/scheme48-0.50.tar.gz
[2]  http://www.cs.Princeton.edu/~blume/scm-sc.ps.gz