This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: variable binding
Keisuke Nishida <kxn30@po.cwru.edu> writes:
> Aha. Are you designing the new module system in the way that uses a
> pointer to a pointer to a location, as you illustrated by symbol ->
> variable -> location -> value?
Design yes, but I haven't thought about how it should be implemented.
But I think it's okay to rely on the update-protocol. (Other parts
need the update-protocol also).
The current evaluator is ugly because it mixes the compile, link and
execute phases. For example it memoizes _everything_, even syntax
just to unmemoize it in the next cycle. That means that the
update-protocol must store pointers to _all_ expressions so that some
expressions can be unmemoized later.
The symbol -> variable -> location -> value stems from FCE's and has
nothing to do with the above. If I remember correctly the environment
patch already uses this model.
> Although it will be slower than the current model, I think it is okay
> because 1) it is simpler and more flexible 2) top-level variable access
> is relatively rare so it won't slow down the system significantly.
Hmm, except for the evaluator problems mentioned above the
unmemoization protocol is okay. Shadowing defines and changes of the
export-list occur only while typing in new expressions, not during
program execution.
Jost