Resilient (was: The Weekly Juan #4: "Smalltalk, Direct Manipulation and End User Programming")

Lex Spoon lex at cc.gatech.edu
Thu Nov 23 13:57:00 UTC 2006


"Francisco Garau" <fgarau at gmail.com> writes:
> Hi Lex,
> 
> >
> >  http://wiki.cs.uiuc.edu/Resilient/Issues
> >
> > This claims, and I had heard, that its blocks cannot be returned or
> > stored in the heap.  IMHO that is such a major limitation that it is
> > hardly Smalltalk any longer.
> >
> 
> That limitation was there from the begining. Lars Bak explained in ESUG 2003
> that it made the implementation of the Smalltalk interpreter much simpler. I
> specially liked the idea because it would make concrete type inference
> possible on those systems. And one of his students followed that path
> 
> http://blogs.sun.com/ahe/resource/peter-ahe-thesis.pdf


I would agree it makes type inference more precise, as does any
language change that narrows down the flexibility of runtime dispatch.
I would argue with the "possible" part, though.  You and I have both
written Smalltalk type inferencers that are not foiled by the presence
of blocks.

Anyway, I had the impression the main motivation was to make the
Resilient run fast, and that type inference benefits were secondary.
After all, Resilient targets less powerful devices.


> In my opinion, without blocks Smalltalk would taste very differently. But I
> must agree with Marcel Weiher when he says that Smalltalk is not a pure OO
> language. Because of the blocks it can be characterized as hybrid, mixing
> elements from OO and FP.

Well, it's pure in the sense that it has all the OO fundamentals,
*and* all the values act like proper objects.  So let's say it's not
"merely" OO instead of it's not "pure" OO.  It takes all of OO, plus
parts of FP.

Anyway, all this said, it sounds like Resilient's blocks are at least
sufficient for the collection methods like do: and select: to work.
Those, IMHO, are some of the most useful applications of blocks in
Smalltalk, the ones I'd miss the most if blocks were removed entirely.


-Lex




More information about the Squeak-dev mailing list