This is the mail archive of the
mailing list for the Guile project.
- To: "Mikael Djurfeldt" <email@example.com>
- Subject: Re: `undefine'
- From: "Marisha Ray & Neil Jerram" <firstname.lastname@example.org>
- Date: Fri, 14 May 1999 01:42:31 +0100
- Cc: <email@example.com>
Mikael Djurfeldt <firstname.lastname@example.org> 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
>[[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.