Things are a little better than you think -
Anthony has made the Closures independent of image format changes. The
only "incompatibility" is the fact that a new VM is required, but even
that isn't really a break, because it merely requires added prims, which
presumably can be either a plugin (so they can be added to existing VMs)
or added the the next batch of VMs without breaking compatibility with
old images. 

So given a little time for the VMs to catch up, the only kind of
incompatibility that would arise is that image with the changes *active*
(methods actualy compiled with closures) would run very slowly with old
VMs. 

I agree it doesn't make sense to pile changes up if its not absolutely
needed, and they aren't.

What are the issues for integration? (I'm just raising them here, not
judging how severe they are)
- As you mention, the new compiler framework based on RB and a generated
parser, can be a less crufty base to build new stuff (alternative
syntaxes, pretty printers, analyzers). Another benefit is that stuff
written to work on the RB AST will be pretty portable to other
Smalltalks (ignoring {.} and other dialect variations). On the down
side, it does mean inserting all this new code into the image, and
making sure it replaces the existing parsers fully, with all the
algorithms and hooks they've accreted over the years. The fact that
there's a preference that can be switched on and off will make this
easier to handle.
- As Goran mentions, there is still uncertainty about the freeness of
the SmaCC generation tools. I agree this is a problem, because Squeak is
self-hosted to the extent that everything in it can be modified by tools
at least as free as Squeak-L. On the face of it, if tommorrow SmaCC
turns proprietary, and people want to experiment with alternate
syntaxes, we might have a problem. 

That's what I know of right now. As a first approximation - If the
license issues are resolved, it might be possible to get this stuff into
3.7alpha. To better understand what would need to be done before this
happens, I would really want more feedback from the community about the
first issue (functional coverage) - file this in, recompile everything,
remove the old compiler classes, and let us know what breaks.

Daniel

Marcus Denker <marcus at ira.uka.de> wrote:
> On Tue, Mar 25, 2003 at 03:32:42AM -0500, Anthony Hannan wrote:
> > Hello All,
> > 
> > A new version of my closure compiler is ready at
> > http://minnow.cc.gatech.edu/squeak/ClosureCompiler (also linked from
> > SqueakMap).  The runtime has not changed (closures, context
> > enhancements, continuations, three new primitives, etc.), but the
> > compiler itself has been refactored (once again).  This time it uses the
> > SmaCC parser generator and the Refactory abstract syntax tree.  Also, the
> > back-end has been refactored a bit and the decompiler has been totally
> > rewritten.  A special thanks goes to John Brant and Don Roberts for
> > creating both Smacc and the Refactory Browser, and to Markus Gaelli
> > and Daniel Vainsencher for porting them, respectively, to Squeak.
> > Below is a short description of the closure compiler copied from the
> > Compiler class comment.
> > 
> 
> Wow, that's nice!
> 
> We really need to start thinking about how to move this stuff into
> the main release...
> 
> Question: There has in the past been the impression that we would
> do all "incompatible" changes in the (mythical) Version 4.
> 
> Does it really make sense to pile up all these changes (e.g. Tim's simpler
> compiled methods) and then postpone adoption indefinitly (because the
> change is so big)?
> 
> The rational for not doing these changes incrementally was allways
> compatibility: You should be able to run old images on new vms and
> new images with old vms. 
> Is this really important? We ship new VMs with each release anyway,
> and the old vm's are available via ftp forever, so doing incompatible 
> changes shouldn't actually be so problematic in practice.
> 
> I'd really like to see Tim's CompiledMethod changes and the ClosureCompiler 
> added to the main release soon.
> 
> And, because I really think the SmaCC-and-Refactory bases compiler
> is really important, maybe it would even make sence to "backport" 
> this to the current non-closure block implementation and inlcude this 
> even as soon as 3.6.
> 
>     Marcus
> 
> -- 
> Marcus Denker marcus at ira.uka.de  -- Squeak! http://squeak.de