Jecel Assumpcao Jr jecel@merlintec.com writes:
Someone mentioned that the language had been changed from Smalltalk, but it is impossible to tell from the information on the company site (though you can register to download it and see for yourself). A good starting point for information about this system is:
More info here:
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.
-Lex
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
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.
http://www.metaobject.com/papers/HOM-Presentation.pdf
Cheers, Francisco
"Francisco Garau" fgarau@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
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
squeak-dev@lists.squeakfoundation.org