Parse trees (Re: emacs with guile instead of elisp)

[Telford Tendys <telford@triangle.triode.net.au>]

> > What about maintaining a common heap store which can be memory mapped
> > read-only into a fixed address space of the process?
> 
> Hmmm... I can't claim that I'm not speaking from my ass now, but this
> sounds like RScheme, assuming their persistent store can hold closures.
> 
> OTOH, Rscheme is compiled to pseudo-code (not parse trees AFAIK), and
> why shouldn't you be able to store arbitrary binary code in persistent
> store? Need to look at this stuff closer...

Stop me if I go wrong here...

Symbols are stored in a common hash table so that the actual symbol string
value is only stored once. As new code comes in through the `read' parser
the symbol hash table grows to handle the new symbols comming in
and all instances of a given symbol get exactly the same SCM value
(which points to the string value and some properties and things).

If you have memory mapped chunks, do these chunks store symbols in full
string form? If they do, then you will have to reparse the memory mapped
chunks which defeats the purpose. Do they store symbols as references to
their own hash table? If you do then you must merge the incoming hash table
with the currently resident hash table or else have multiple system
hash tables floating around (making it difficult to look up the value
of a symbol). Do you try and create universal SCM values for all of the
common symbols? If you do this then you are heading for a versioning
nightmare with the prospect of maintaining a database of symbol values
that is set in stone for all time.

Unless someone has either a way to make one of the above options work
or some new option, there is no way to handle symbols in these memory
mapped modules!

	- Tel