Two important issues...
goran.hultgren at bluefish.se
goran.hultgren at bluefish.se
Tue Feb 18 09:05:18 UTC 2003
Avi Bryant <avi at beta4.com> wrote:
> On Tue, 18 Feb 2003 goran.hultgren at bluefish.se wrote:
> > Hmmm, ok. I don't think the community wants such an important part of
> > Squeak as the Parser/Scanner to be produced using tools that are not
> > included in base Squeak (the dev part)!
> Why is that a problem? I was envisioning just the runtime and the
> generated parser being part of the base image, where you would only load
Well, "part of the minimal packages needed to run Squeak normally".
> the RB and SmaCC if you wanted to hack the syntax. License considerations
Yes, but shouldn't the Squeak tools for evolving Squeak also be in
Squeak core? I think so.
Like for example VMMaker, or whatever tool.
> aside, this seems like the best way to go in the modular world we're
> trying to create, and if we're not putting the full SmaCC environment in
> the base image anyway,
I am not sure what you mean with "the base image". In my perception of
the future there simply is no such thing. There are only groups of
packages, and some of them are "core" to Squeak which means they are
under Squeak-L and can be depended upon, the community takes care of
But perhaps that is what you mean.
> why do we care about the license as long as it's
> freely available?
Ok, but what happens in the future when John and the guys decide to turn
SmaCC into a proprietary product? Then we have a core piece of Squeak
that we can't change without using a non "Squeak free" tool.
Personally I think it is an important problem. And principally it would
feel much better IMHO if all parts of Squeak where under Squeak-L -
including the tools inside Squeak. For example, what would your reaction
have been if SqueakMap was not under Squeak-L?
Sidenote: It could probably even be argued that improving the
Scanner/Parser in Squeak can not be done without publishing those
improvements under Squeak-L. What we are essentially doing now is that
we are using a tool to produce those improvements. This means that the
"source code" has now moved over into the SmaCC grammar and that source
can not be "compiled" without using non-SqueakL tools. Well, I am not
sure where I am going with this chain-of-thought, but it doesn't feel
right to me. Squeak is "self hosting", all classes inside Squeak is
changeable using Squeak itself - this would change that property.
I hope that John Brant and Don Roberts can consider to release *the
Squeak port* of SmaCC dev and runtime under Squeak-L. In essence, this
would mean that you are free to use SmaCC dev and runtime under Squeak-L
*in Squeak*, but not in other Smalltalks. It *could* also mean that
improvements done to the Squeak-SmaCC must be published openly under
Squeak-L, but I would like to get Andrew's confirmation on that.
This would also still let John/Don choose whatever license they like for
the other Smalltalks, which is probably what they want to be able to.
More information about the Squeak-dev