This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: nested modules / anonymous modules
- To: jostobfe at linux dot zrz dot TU-Berlin dot DE
- Subject: Re: nested modules / anonymous modules
- From: Clark McGrew <mcgrew at ale dot physics dot sunysb dot edu>
- Date: Fri, 22 Oct 1999 18:29:25 -0400 (EDT)
- CC: clark dot mcgrew at ccmail dot sunysb dot edu, guile at sourceware dot cygnus dot com
- References: <199909131751.RAA12898@linux.zrz.TU-Berlin.DE> <xy7671ee89x.fsf@mdj-pc.nada.kth.se> <oflna9sxyo.fsf@chl.tbit.dk> <xy7k8pty0l3.fsf@mdj-pc.nada.kth.se> <m2ogf5mqkm.fsf@magnus.bothner.com> <xy7iu5ds8w9.fsf@mdj-pc.nada.kth.se> <xy77llng8t7.fsf@thalamus.nada.kth.se> <879063lowi.fsf@zagadka.ping.de> <m11ShfH-000H40C@debian> <87n1uiswly.fsf@sanpietro.red-bean.com> <xy73dwaladu.fsf@thalamus.nada.kth.se> <87k8plqvcq.fsf@sanpietro.red-bean.com> <xy7ogevahq9.fsf@thalamus.nada.kth.se> <199910152151.VAA06072@linux.zrz.TU-Berlin.DE> <m11dGYp-000UuBC@boxer.physics.sunysb.edu> <p2t3dv47ejo.fsf@pampelmuse.zrz.tu-berlin.de>
- Reply-to: clark dot mcgrew at sunysb dot edu
>>>>> "Jost" == Jost Boekemeier <jostobfe@linux.zrz.TU-Berlin.DE> writes:
Jost> I am aware of Jonathan Rees' and Matthias Blume's work but I
Jost> can't say anything about module systems designed by
Jost> Mr. Tung, Lee, Friedman, Curtis or Rauen. (What is "&c"
Jost> btw?)
They are mostly variations on the theme. Lee and Friedman is
interesting since it doesn't use modules, but extents which are sort
of like environments. They define a nice (theotetical) way of dealing
with namespaces. (The "&c" is the literature that I missed. There
are lot's module systems floating around for scheme.)
Jost> 4. One file -- one module
>> This has the advantage of being C-like so it's easy for
>> C-philes to grok.
Jost> Java like. :)
One of the (very) few things I like about perl is the way it handles
packages. (Uh oh... Now I'm going to get it...) The syntax is a
little strange, but the results are nice.
>> Why? I don't see any problem with compiling a file which
>> contains more than one module.
Jost> Not really a problem but what how should the following be
Jost> compiled:
Jost> ;; in file ice-9 test
Jost> (define-module (ice-9 test))
Jost> (define-module (ice-9 test1))
Jost> (define-module (ice-9 test2) :use-module (ice-9 test1))
Jost> ;; in file ice-9 my-test
Jost> (define-module (ice-9 my-test))
Jost> (define-module (ice-9 test1))
Jost> (define-module (ice-9 test2) :use-module (ice-9 test1))
I There are a couple of reasonable ways to handle this.
The "ld" appoach would be to to make it an error to use both (ice-9 test) and
(ice-9 my-test). That's a bit brutal but it's simple.
Another approach is that when a module is multiply defined, like
(ice-9 test1), to just combine the symbols into the same environments.
The rule is that all variables must be bound as a file is loaded. The
drawback is that ice-9/test.scm:(ice-9 test2) and
ice-9/my-test.scm:(ice-9 test2) would see different definitions
depending on the load order. I claim that is not a problem. There are
three cases:
1 test.scm:(ice-9 test2) only depends on definitions in
test.scm:(ice-9 test1) so it can be loaded independent of
my-test.scm. (and visaversa)
2 my-test.scm:(ice-9 test2) depends on test.scm:(ice-9 test1), but
test.scm:(ice-9 test2) does not depend on my-test.scm:(ice-9
test1) so test.scm must be loaded before my-test.scm. The user
would be required to make sure that condition is met.
3 there is a circular dependency.
There is clearly no problem with 1, but 2 is asking for trouble and 3
is always an error.
I think a much more likely usage pattern is:
-- my-file.scm
(define-module (my-file internal) :use-module (some module))
(export stuff)
(define-module (my-file) :use-module (my-file internal))
(stuff ...)
--
Another usage pattern is:
-- file1.scm
(define-module (m1))
(export stuff1)
(define-module (m2))
(export stuff2)
-- file.scm
(load "file1.scm")
(use-modules (m2))
--
This might be useful for building a user interface where you want
lot's of modules available, but not all symbols visible.
It would also be nice to see modules spread across several files:
--00file.scm
(define-module (a module))
(export d00)...
--01file.scm
(define-module (a module))
(export d01)...
--a/module.scm
(define-module (a module))
(load "00file.scm")
(load "01file.scm")
--test.scm
(use-modules (a module))
(d00 ...)
(d01 ...)
--
I actually use this particular idiom for a ui. In my case (a module)
loads all of the files that it finds in a particular sub-directory.
Is there a spec out for the new module system (kind of like a srfi)?
Everything I know about the new system has been infered from email.
Thanks,
Clark