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: A new module system for Guile


Hi,

    >> keep the same high level user interface

    Jost> What is
    Jost> more important and what distinguishes my module system from
    Jost> others [1,2] is that in this module system a module is _not_
    Jost> a first-class object. 

What's the advantage.  It would seem like you'd want modules to be
first-class.  Sorry for being so naive.

    Jost> Programmer A can contribute a module "A"
    Jost> and can put other modules into his private subdirectories
    Jost> (e.g. "A/mod1") so can programmer B. The collection of "A"
    Jost> with all its subdirectories "A/mod1", "A/mod2", "A/B/mod"
    Jost> etc. is called a "package".

This sound cool, but it also sounds complicated and hard to maintain.
(the modules, not the module system).  Doesn't this mean that
programmer A and B will have different visible interfaces for module
A.  If I understand it, when programmer C writes a program that uses
module A, programmer A and B will get different behaviour when they
compile it.

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

This is off topic, but why not standardize on one of the existing
object systems (there must be at least 4 or 5 major ones).  That gets
guile an "Official Object System" *now* and make sure we are all reading 
from the same "object hymnal".  Later it can be re-implemented in
libguile and optimized to come up to speed.  

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

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

It seems like (mod-ref a b) could be syntatic sugar for a.b.  I was
more concerned that a.b looks like C.  We can't have that can we? :)

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

    Jost> Hmm, maybe a firewall?

No, It's working now.  Thanks,

Cheers,

Clark