Real closures

Mathieu mathk.sue at
Sat Oct 7 20:49:13 UTC 2006

Andreas Raab a écrit :
> bryce at 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.

Witch boring issues are you talking about?

> [*] 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

More information about the Squeak-dev mailing list