Re: Where should guile modules store meta data?

["Marisha Ray & Neil Jerram" <mpriz@dircon.co.uk>]

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.
>
[...]