This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: nested modules / anonymous modules


>>>>> "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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]