This is the mail archive of the guile@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: module interface changed or changing?



; <AOL> Yes, please! </AOL>
<MSN> Me, too! </MSN>

; I really wonder why this hack is not in the Guile README or something.
; One small step - and you can write modularized code and not make it
; Guile-specific at the same time.

It's not there becuase the module system is going to be changed RSN
(has been for a year or more)

; > Here's my wish-list for a module system:
; > (1) Make names available outside of module with an export clause instead of
; > different define/defmacro
; > (2) Allow selective imports from a module
; > (3) Allow renaming of imported names
; > 
; > Maybe all this can be done with the current module system already ... I'm
; > not an expert.
; 
; (1) See the code above
; 
; (2) You can lookup individual symbols in modules, so some magick macro
; can probably be written.

I recomment using @ so you can get things of the form:
((@ ice-9 hcons) make-hash-conser ...)

; (3) Ditto.

Yeah.  You can do stuff like:

(define ice-9-apropos (@ ice-9 apropos)) ; just one
(define mod (lambda (x) (@ a long module name x))) ; a whole module
 ((mod func) args)
I don't think that string-level mangling on module names is valuable
(eg: prepend the string "foo" to all imported symbols)

; > I do like Scheme48's module system (Jonathan Rees: Another
; > Module System for Scheme) a lot better than the current one. Has anybody
; > ported that to Guile already ?
; 
; I guess not.  Would be cool - I like it too.  In fact, the mailing
; list archive seems to suggest that everybody here likes it :)

I only just found an online description of it.  It's a bit hard to
understand, but it's at 
http://www.cs.hmc.edu/~fleck/envision/scheme48/module/module.html

I'm not sure I understand it, but it sounds like a very good module
system to implement.  A few improvements I see:

Well-defined/documented.
Behaves well in the presence of changing modules (I keep having to
restart guile to reload my modules)
Handles dynamically linked modules in a reasonable way.
I don't know if it has nice syntax to do the things above...

Does anyone want to port it/implement it on top of guile? 
Would the maintainers be interested if someone did?

It would probably have to replace the current module system. 

Andrew