Re: `undefine'

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

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

>In a sense, this means that Guile uses the word "space" for two
>different things: one, a collection of Scheme code which imports
>bindings from other spaces, and exports some bindings to other spaces,
>and two, an object representing a namespace.  We do not use two separate
>terms, however, because the meaningful operations on the first kind of
>space are the same as those on the second kind, and also because we
>expect the distinction to be clear from context.  [[Not sure about this;
>we could use 'spaces' for the objects, and 'spaces' for the Scheme-level
>things; what do folks think?]]

Yes, that would be much clearer.  I think we should call continuations
'spaces' too.

>[[I've got some half-baked thoughts about allowing a space named (FOO)
>to handle resolution of all names (FOO BAR ...).  Then we could have a
>root space named (), which implements all the path searching semantics,
>etc, and could be replaced for non-filesystem-based environments.  Also,
>we could integrate other space systems into Guile's; for example (slib
>mumble) could do an slib-style (require 'mumble) and pack that up as a
>space.  If we try to find a space (FOO BAR ...), and there's a
>subdirectory in the path called FOO, we could load a file called
>FOO/guilemod.scm (think index.html), and the space it creates would be
>used to resolve BAR, etc.  The root space could provide loading
>FOO/BAR.scm as default behavior.]]


This sounds really interesting, but I don't follow exactly how the mechanism
would work.  Could you explain further, or maybe give an example?

>@node Modules and Spaces
>@section Modules and Spaces
>
>[[How do we implement modules, given spaces?]]

It feels like it would be easy to implement any module system - including
the existing module interface - on top of these spaces.  To judge from the
frequent complaints on this mailing list, though, it seems that there are
perceived problems with the existing module interface (unless I have
misunderstood those complaints).  So the hard part is to define clearly a
module interface that everyone will find useful.

>A space finds a symbol's binding either by looking up the symbol in a
>hash table (as for a local space), or by delegating the search to other
>spaces.  This means that the full symbol lookup process is too
>expensive to perform on each variable reference.  Thus, Guile uses
>memoization and caching to avoid repeating the search for a given
>variable's binding, unless the space's configuration has changed.

I know I should really go and read the code, but I don't understand the
benefit of memoization.  Why is looking up a value in a GLOC so much quicker
than looking it up in a value cell?

>@node Primitive Spaces
>@section Primitive Spaces
>
>[[Pretty obvious stuff.  This should be the standard way for C code to
>define Scheme-visible primitives, and so shouldn't be hidden here in the
>back of the section on spaces.]]


Primitive spaces rule.

Thanks very much for an interesting read.

    Neil