SMACC and Version 4

stéphane ducasse ducasse at iam.unibe.ch
Wed Apr 14 07:10:15 UTC 2004


hi dan

that's really good news. I imagine that this way we will have a good 
visitor on the AST. This also
means that we will be able to reuse the refactoring engine (note that 
romain already cut the UI from the engine and that now we can get all 
the refactorings into at least four browsers).

Stef

On 13 avr. 04, at 23:45, Dan Ingalls wrote:

> Folks -
>
> For the most part, we anticipate the changes underlying Version 4 to 
> be invisible to the average user.  However, one change has come up 
> that extends into a number of adjacent areas, so I want at least to 
> warn everyone of its coming.
>
> The change is to replace our barnacled old ST-80 compiler with a shiny 
> new SMACC-based compiler.  The decision to do so was originally 
> motivated by the fact that Anthony's closure support, which will be a 
> part of Version 4, is based on SMACC.  Then, when the topic came up 
> for discussion on the VM-developers list, the move to SMACC was 
> further endorsed because  the old compiler is such a mess, the 
> Refactoring Browser already uses SMACC,and it is likely that any 
> future compiler work (such as Marcus's parse tree experiments) will 
> also be based on SMACC.
>
> Marcus Denker has kindly offered to prepare a changeSet that 
> introduces SMACC into the innards of Squeak without significant 
> perturbation.  He has some other work to complete first, but it is 
> likely that this change could be ready for test around Mid May.  We 
> are requesting that this be brought into 3.8 alpha as soon as it seems 
> reasonably solid (we'll announce when this is so).  Also, since Marcus 
> has plenty of other things on his plate, it would be nice if other 
> folks could help with testing of this change when it is ready, as it 
> impinges on a number of sensitive adjacent areas such as 
> decompilation, source code selection in the debugger, and the 
> universal tiles used by the browser's view-as-tiles feature.
>
> There will be a number of upsides to this move, not the least of which 
> is the introduction of Anthony's closure support soon thereafter, with 
> accompanying VM support to follow soon as well.
>
> If anyone knows a reason why not to make this move, please speak now 
> or forever hold your peace.
>
> Thanks
> 	- Dan
>




More information about the Squeak-dev mailing list