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

[Stephane Ducasse]

Hi goran

>> 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.

So what you load SmaCC changes it and you get a new one.

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

Ok I see your point.

The problem is that john does not understand all the implications of 
having
Smacc SqL, so we are a bit blocked.

I can try to ask him.

> 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.
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
>