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] |
I think that the one file approach is easier for the module user, but there is no reason why the module implementer should not split one file into two: $ #the interface to (package1 test-module) $ cat test-module.scm (module-define '(package1 test-module) '<imports> '<exports> <protects> <inits>) (load "test-module-i.scm") $ #the implementation of test-module (part of `package1' package) $ cat test-module-i.scm (define ...) This is so easy that I don't think the module system needs to provide any special support for it. Since module-define specifies all the module's imports and exports, does this mean that the implementation code is pure non-modulish scheme? I.e. no more need for define-public etc.? This would be a big advantage IMO, and make it easy to load an arbitrary scheme file as a Guile module. Talking of which, how about a load-as-module procedure, something like (define (load-as-module path module . exports) (module-define module '() exports '() '()) (load path) ;; Something here to indicate the end of the module definition?? ) We can also start implementing autoload... but I'm getting carried away. (Hmm... autoload is just a promise, isn't it?) One more question. module-define is now a huge procedure that does everything. Would it be better to break out some parts of module-define, e.g. module-export to specify exported bindings? This would also provide a natural place for export documentation. It looks like Godot is nearly here! Neil -----Original Message----- From: Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> To: guile@cygnus.com <guile@cygnus.com> Date: 1999 June 02 13:49 Subject: Where should guile modules store meta data? > >A module is a structure used to encapsulate related data and functions >with a restricted view from the outside. Typically, modules are used >to hide implementation details through a well-defined set of functions >called the interface. The module consists of two main parts: the >head, where you store the information what and how something should be >visible and the body, where you define your functions and data >structures. > [...]
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |