Re: ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
[email protected] Mon, 23 Jun 2003 00:08:54 +0100
| Newsgroups | gmane.comp.lang.smalltalk.squeak.foundation |
|---|---|
| Message-ID | <[email protected]> |
Hi guys! Stephane Ducasse <[email protected]> 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.