Re: About modules

[Klaus Schilling <Klaus dot Schilling at munich dot netsurf dot de>]

Neil Jerram writes:
 > I agree that environments do not directly provide an easy-to-use
 > module system.  But Marius was suggesting that Guile should not have
 > an official module system, but rather a mechanism for managing
 > namespaces, on top of which an application could add whatever module
 > system it needed.
 > 
And that's exactly what i need for my game 'Naos' , a mechanism to 
provide an game-internal package system to maintain code that is
randomly accessed and altered at runtime, by independant authors
and the gamedriver itself. That situation is similar to those of
certain networked games called LPMUDs, but all in all very peculiar
and not really useful outside, except some ideas. So it is really
application specific. A form of eval will be needed there in any case,
unless K. Wright can convince me not to do so :)
Runtime in this case also includes the downtime of the game engine 
between two game sessions, especially parsing the savefiles I can't
imagine without doing a lot of calls to eval.

 > So I think the implication was that the namespace mechanism would be
 > quite low-level, and I wondered whether environments provide that
 > low-level mechanism, or whether Marius was thinking of some other
 > functionality that environments don't provide.
 >
I haven't understood that at all. Boekemeyer talked about first-class
locations, woithout either explaining what that is or whether those
are already implemented ... anyone have any idea about those?
 
 >    > It seems to me that environments do provide the required mechanism,
 >    > except perhaps that they are more complex than we need.  To implement
 >    > the type of module system described by Jonathan Rees, for example, all
 >    > we need is a single environment type, in which the entry for a
 >    > particular name can hold, in addition to its vcell, a pointer to an
 >    > entry in another environment.  We still need an observer mechanism,
 >    > but per-entry rather than per-environment.
 > 
 >    You may be entirely correct that the environments are too complex.  I
 >    don't know.
 > 
 >    A lot of that complexity is there to handle the case where you edit
 >    and re-load a module.  I think this is something that people will
 >    often do while developing.  In this situation, bindings will
 >    arbitrarily appear, change, and disappear.  It seems fragile to have
 >    to announce each binding change individually; the code to track that
 >    seems more complex and error-prone than my proposal.  But that's just
 >    an intuition; I'd be interested in seeing evidence otherwise.

And that's very much needed by Naos. And yeah, having to restart the game 
for even simple vchanges is stupid. Changes should be integrable on the
fly, as the upload command in LPmuds does.

Klaus Schilling