Hi Avi,
> I read through the code in DeclarativePools-4.sar (note that I couldn't
> find a DeclarativePools-5.sar).  The changes are clean, sensible, and
> fairly contained.  I didn't see any problems in the code, and I think
> it solves an important problem.  I am not a harvester, but I am strongly
> in favor of including it.
thanks; the -4 version (on my website at
http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas) simply adds some
fixes to Andreas' original so that the browser can explain variables in
these new type of pool along with changing the fileout of pools so as to
_not_ try to fileout the new SharedPool pools. That is actually an
important issue in my estimation; should we
a) fileout the SharedPool subclass along with older Dictionaries
b) fileout only older dictionaries
c) stop both
d) something else I didn't think of.

Umm, I can't actually find any differences with the -5 version so maybe
I just wrote it out twice...

We also probably need to think of some policy for handling version
mismatches. For example, once the declarative pools are in use we ought
to have some way of preventing an out of date package loading (say the
current VMMaker for example) in favour of an updated one. It would be
nice if we could have SM cope with multiple packages of the same name
but specified for different versions. Or something. Andreas favours the
broken-eggs-for-an-omlette approach but I'd love to find a way to trap
and warn.

tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: CCC: Crash if Carry Clear