Re: Where should guile modules store meta data?

[Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE>]

Hi,

sorry for being so terse yesterday.  

Yes, I think we should split the module into two separate files.  An
interface file which holds scheme code that defines the module's
interface:

--------------------
; Interface file ice-9/test1.i
; for module ice-9/test1
;
(module-define
 '(ice-9 test1)
 '((system root))
 '((a mutable-location) (b immutable-location))
 '()
 '(begin 
    (define a 1)
    (define (b) (display a))))

(display "loading definitions for ice-9/test1\n")
(module-load-definitions 'ice-9/test1)
--------------------


And a definition file which can be guile-scheme, elisp, ctax, etc.

For example:
--------------------
; Definitions file ice-9/test1.scm
; for module ice-9/test1

(display a)
(b)
(define a (+ a 1))
(define intern 1)
... do something useful

--------------------

Note that this is a two-step process:
1. load and execute the interface which in turn is responsible to
2. load and execute the definitions.

The interface code is always executed in the config module.  The interface
code must create a new module and load/execute the definitions in
the new module (in its newly created eval-environment to be exact).

The reason why I like the two files solution is that it is easy 
to implement.  When you use a single file you must read the first
line, execute it, change the current environment to the module's
eval environment and read and execute all subsequent lines in this
new environment.  When you use two files you can do the following:
(load file.i config-env) (load file.scm (find-eval-env-for-module file))
After that you are still in your old environment but you can
start a new repl in the new module by calling
(top-repl (find-eval-env-for-module file))


Now the next question would be: Should guile store all interfaces into
one special file (i.e. one interface per package) or should guile use
one interface file per module?  For example let the package "GUS"
consist of four modules: gus1 gus2 gus3 gus-misc.  We can use either a
single interface file for the whole package say "gus.i" or we can use
4 separate interface files named gus1.i, gus2.i ...gus-misc.i.

When we use one interface per package, all modules from package "GUS"
will be loaded when someone acesses a function exported from gus-misc,
as in scheme-48.  I don't have the experience to decide if that's
a good behaviour or not.

> Since module-define specifies all the module's imports and exports, does
> this mean that the implementation code is pure non-modulish scheme?

Yes.  See file ice-9/test1.scm


> We can also start implementing autoload...

When typing (module-go '(ice-9 test3)) or (module-ref '(ice-9 test3)
'a) modules test[1-3] will be automatically loaded.  Note that
internally modules are represented as symbols. So '(ice-9 test1) can
also be written as 'ice-9/test1.


> (module-define '(package1 test-module)  '<imports> '<exports> <protects>
> <inits>)
> One more question.  module-define is now a huge procedure that does
> everything. 

This is possible.  But you have to make sure that the <init> section
is called *before* you create the export environments `export' and
`protect' for your module.  You can do this by either using a lock
"error, exported variables <exports> do not exist, please specify the
initial variables" or by using a single function as above.


Jost