[Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)

goran.krampe at bluefish.se goran.krampe at bluefish.se
Mon Jun 23 01:08:54 CEST 2003


Hi guys!

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
[SNIP]
> But ClosuresCs does not depend on SmaCC. It has been generated using  
> SmaCC which
> is different. I do not need to include bison because I use a parser  
> developed with it.
> Or there is something wrong.
> Can you let me know if I'm wrong?
> Stef

The problem with the above reasoning is that it assumes people only
want/need to *use* the Compiler and not *change* it.

Before we had a Compiler that was written in Squeak - and thus also
modifiable in Squeak using Squeak itself (all under Squeak-L).

If we choose to move over to a SmaCC generated Compiler (which of course
would be technically great) we will have a Compiler that can not be
modified using only Squeak itself. Unless SmaCC gets included into
official Squeak of course - which it could if it came under Squeak-L,
which it doesn't.

People may think this is a "small" issue. Personally I think it is a
quite important issue. Every other little piece of the Squeak image is
modifiable by Squeak itself. The VM too - though not to the full extent
(you need a C compiler etc). This would suddenly make the Squeak image
"non self hosted".

Hopefully we can though still somehow get SmaCC under Squeak-L and the
problem would be solved. 

Then Stephane wrote comments on the other extensions and I agree to the
comments (but I haven't looked at the code) made. Just adding a little
method in base classes here and there may seem "innocent" enough but
they add up and eventually turns into a mess.

regards, Göran

PS. People may find it tempting to simply drop the "golden rule" sofar
that everything in official Squeak should be under Squeak-L. That would
probably (as Andrew Greenberg has pointed out multiple times) lead to a
legal minefield and be very bad for Squeak.


More information about the Squeakfoundation mailing list