Block Closure Semantics (obsolete)
Last updated at 6:07 pm UTC on 19 July 2013
This is obsolete; full Closures are part of the main image
Also see Squeak Central project Closures, the recently complete version by Anthony Hannan, Closures and Are Squeak blocks like Scheme blocks.
Status
I've stopped working at this project: so ToDo probably remains forever.
Overview
Though there is the BCS implementation from Anthony Hannan now, I've decided to bring my own approach to a working state: here it is!
Though I haven't taken a deeper look into Anthony's BCS implementation so far - no time! - I assume - from what I've seen at the ML and the Swiki - that it is the conceptual better one.
This is a quick'n'dirty implementation, but it isn't as quick and as dirty as this sentence may suggest... Quick'n'dirty in the sense, that I've avoided to read much theory and tried to go my own way with some pressure of not spending too much time (in theory...).
Please read the Draft for Block Closure Semantics for Squeak if you want to understand what I have done. It closely corresponds to the current implementation; differences should be visible in the ToDo list.
Design goals
- as less new context classes as possible;
- reusing as much as possible;
- compatibility with old images;
- coexistence of non BCS and BCS blocks;
- semantic comes first, then implementation speed, runtime speed last.
Results
Semantics
All tests from ClosureTestCase-rww-bg are running OK.
Results with respect to the design goals
- Just one (!) more context class BCSBlockContext.
- The BCS compiler is weired, but hey, it works! I'm not very happy with the many stacks introduced in BCSEncoder; there should be a better way: they are used to avoid additional passes of the parse tree.
- The BCS VM runs without problems with standard images, as far as I've seen.
- Fulfilled.
- Fulfilled, but now it is almost as fast as the 3.2gamma VM (for classical BlockContexts).
The BCS VM is slightly slower for classical BlockContexts and probably slower for BCSBlockContexts (to be checked), since
- I haven't read too much theory;
- I haven't followed the 'activation records on a larger stack' theory (so far);
- there are runtime switches between BCS and non BCS block contexts, which could be removed for an all over BCSBlocks image;
- there is room for optimizations.
When does it make sense to use it?
- Since there is a user preference to switch between BCS and non BCS compilation this BCS implementation could help for migrating an image to BCS semantics step by step. There is no need to convert an older image in one run;
- If someone wants to have both semantics in parallel for a longer time (to BCS or not to BCS) and doesn't need speed in the first place...
How to get it work
- BCS VM
- fileIn changeset BCSInterpreter,
- generate the VM as described there, and
- compile it.
- BCS Compiler
- fileIn changesets BCSCompiler1 and BCSCompiler2,
- start the image with the BCS VM generated by the 'BCS VM' steps,
- perform the tests described in BCSCompiler2,
- after that you can also test with ClosureTestCase-rww-bg: switch on BCS compilation before filing it in.
- BCS Debugger
- this is a start: sometimes it is possible to view and change variables, sometimes not;
- for some (far from perfect) BCS debugging fileIn changeset BCSDebugger (you live better with than without this cs).
ToDo
- General
- speed improvements
- exploiting readonly temps
- documentation
- class documentation
- description with focus on differences to Anthony's implementation
- BCSInterpreter
- speed improvements
- selective cloning of BCSBlockContexts
- BCSDebugger
- increase the visibility of BCS variables
- show original var names; renamed ones only, if shadowing has occured
- BCSCompiler
- rework to get a better and more transparent implementation
- Personal
- looking into Anthony's implementation to get
- an impression about how far or short my implementation is...
- ideas for improvements.
On top of the list is 'BCSDebugger: increase the visibility of BCS variables'.
Done
History
I've started a long time ago with drafts for BCS. Some interesting comments of very experienced people suggested another implementation. Since I wanted to see if my ideas are working and did understand them better I followed them further. Then there has come the announcement of Anthony that he would work at an ambitious implementation. This demotivated me somewhat and work has stood still for a while. But it has taken time and time without visible code... Now I know why!
I've restarted again with this project and then Anthony's very concrete announcement for New Year has come followed by his code: Congratulations!
But in spite of this - and being aware of coming late ;-) - I decided to come to some end - I don't like long projects without any result - and to give the code to the masses...
As a personal result I have learned a lot, especially by the wrong paths which I've followed before coming to the correct ones.
And here it is.
Questions, wishes and comments
Add them here or mail to Stephan Rudlof.
