This is the mail archive of the guile@sourceware.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: Goops and the module system


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:


> As far as I know, we have not yet defined how the multi-language
> support is going to look like, so you should add that this holds in
> your proposal (which you don't refer to).

Ah, this reminds me of something.  Are there any old module proposals
or attempts thereof (I take everything :>)?  If so, where do I find
them?

> When you say "[there's] one REPL per module" you probably mean that
> each module specifies which REPL should be used when inspecting it.
> Since Guile is supposed to translate other languages into Scheme, it
> seems to me that it could be useful to inspect such a module both
> using a source language (like TCL) REPL and a Scheme REPL.

Yep.  The problem is that there are two repls, one that the module
exports for use by other modules (the tcl-repl) and one that
surrounding module/environment/config-language demands (the scheme
repl).

The solution is quite simple.  A collection of modules is called a
"program", "package" or "compound module".  If you want to use the
program, you start the program repl.  But if you want to extend one
module, you step into this module and start a repl that the module
exports.  

We have two scopes: a public interface which belongs to the compound
module and a public interface which belongs to a single module.  You
cannot visit a compound module, because it is only a virtual
construct.

The module config language `go' or ",in" calls the repl that the
module exports.  But a client module from a different package always
sees the repl of the compound module.


Jost

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