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: Where should guile modules store meta data?


Clark McGrew <mcgrew@ale.physics.sunysb.edu> writes:


> Are you intending to force a two file configuration, or just support
> it. 

The problem is that the module's interface has to be evaluated in
a separate environment.  The interface code is responsible for creating
a new environment and then evaluating the module's definitions in
this new environment.

Something like this:

; Interface for module m1
(let ((new-environment (make-finite-environment))
  (eval <code-for-module-m1> new-environment)


It is possible to stick the interface into the module
itself.  But then you have to evaluate the whole module
twice.  The first time in the config environment and then
in the newly created environment (remember that environments
define how bindings are interpreted).  It isn't that bad
for small modules.


> I like the idea that modules *can* be split into separate files,
> but for an interactive system it's much better to have the module all
> in one place.

Umm.  I was talking about module loading.  When you use the repl,
you can create a new module within the config environment (module)
and then start a new repl in the new module you've created.


> so without a module system there are problems with namespace
> collisions and all we need is a crude module system that provides
> simple namespace separation.  

In this case you don't have to load the module system at all.
Just create a new finite environment and evaluate your code in
this environment.  You can use (ge <environment>) to jump from
one environment to another.


> Also, with a two file system it seems like you will force a tight
> binding between files and modules. 

Yes. This is neccesary.


> Why aren't modules and files orthogonal concepts.

A module *is* a file with an interface.  It seems to me that when you
are talking about modules, you really mean a different concept: name
spaces or "environments".


> convenient to define several modules within a single file. 

I don't think this is possible.  How would you interpret or 
compile this?



Jost

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]