bryce at kampjes.demon.co.uk wrote:
> There are two separate issues:
> 1) Why Anthony's VI4 work was rejected?

Anthony's work moved away from the linked-frame representation and put 
(overlapping) frames into stack segments, and pretty much everyone who 
looked at it didn't like the exposure of stack segments (there are some 
interesting issues with stack manipulation when you do that). The 
general feeling was that if a VM wants to play these tricks they should 
be hidden under the hoods and the "user model" should remain simple 
linked frames.

> 2) Why we haven't yet incorporated the new compiler work that Anthony
> did then Markus has been maintaining?

It's not complete. The last time I tried using it I gave up after the 
umphteenth "Token not expected" error message (which is apparently the 
only error message that SmaCC knows). Also, decompilation was never 
completed, the compiler is about 4x slower than the current one etc.

Seriously, if you wanted closures a better bet may be to take the 
existing infrastructure and hack that support in the current 
compiler[*]. If you know what you're doing this takes a couple of weeks 
but then it's done. The trouble with that new compiler is that while 
it's used for a lot of exciting research there doesn't seem to be anyone 
who is willing to spend the time to address the "boring" issues that are 
so important for the non-research users of a compiler.

[*] And I may yet do that for Croquet because we have plenty of non-lifo 
blocks which may need #fixTemps and I don't really want to explain to 
people when and where exactly they need to do it. That's why I looked at 
the new compiler in the first place. Unfortunately, given the choice 
between (the relatively rare) #fixTemps and the (very common) "Token not 
expected" error message, I choose to live with the former every time.


Cheers,
   - Andreas