Two important issues...

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Mon Feb 17 08:25:33 UTC 2003


Hi all!

(not much time, but a few remarks)

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> > I understand this, and so does hopefully we all. Btw, I only used "the
> > guys in Berne" because I don't know a better name for you guys! :-) It
> > was not meant as an "insult".
> 
> We never saw it like that :) We are five squeakers interested in 
> languages.

Goodie. :-)
 
> > Ok, so this means that we should not and probably will not see Traits
> > coming into Squeak core for quite some time (because even if we go full
> > steam ahead there's a lot of work to do).
> 
> We will assess that soon nathanael should provide us an analysis of the 
> parts
> that could be fixed, replaced.

Yes, we/I am looking forward to that "report".

> > We all want a better browser, a better parser/scanner/AST whatever and 
> > a
> > clean kernel.
> >
> 
> For the scanner/ast if anthony builds something on top of SmaCC this is 
> perfect
> for us.

Without having looked at SmaCC (I have used T-gen in that past though
and also ehrm... Flex, Bison etc) I guess that it might be time for
Squeak to move over to a declaratively generated Scanner/Parser instead
of a handmade one.

Are there any disadvantages of this that I am not aware of? Ooops -
there could be a BIG one here. What license is SmaCC under? We need
Squeak-L and it seems to use some other license (couldn't find it but SM
has it listed under "other") if we are going to base Squeak core stuff
on this.

And another thing - does it depend on RB? The SM entry doesn't say, but
somewhere I think I saw that the devpart depends on RB...

Anyway, don't forget about these things - they are IMPORTANT. We can't
let anything enter core that isn't under Squeak-L. And I am not sure,
but we don't want to drag too much stuff into the core - right?

> > Someone will have to do these things (surprise) and the parser/scanner
> > stuff might already be in the pipe since I read that Anthony is 
> > thinking
> > in moving the new Compiler in this direction. But for the rest I have 
> > no
> > idea - but why should anyone be opposed to these things? Stephane has
> > almost sounded as if there is a resistance in the community and AFAIK
> > there is none. Again, this is probably unintentional of Stephane and he
> > just wanted to tell us about your different "problems".
> >
> > So I think this boils down to if you want to play together with us in
> > the community or not. I mean, if Traits enter Squeak as a "core" 
> > package
> > then it will not be "yours" anymore to do with whatever you please.
> 
> But we never had problem with that.

Good. :-)

No, but seriously - I just got the impression that... well, this can get
hard to express in a non-native language. Hmmm. It sounded to me that if
Squeak as a community "wouldn't do this and that" then you would simply
leave and pick another Smalltalk.

And that got me a bit scared. :-) Well, today it doesn't matter - but
tomorrow when Traits is all over the place and Nathanael has rewritten
large parts of the core ;-) then it would be devastating if you suddenly
decided to just dump Squeak.

I simply want to be reassured that people who are going to rewrite
(possibly) large parts of the Squeak kernel/core are *really committed*
to Squeak and to the community.

I hope I managed to explain this without offending anyone. :-)

> > But lets say we get these things fixed together. What then? I am still
> > wondering about where Traits would "end up" in the different groupings
> > of packages and I am still wondering what this means - is Squeak not
> > Smalltalk anymore? And does it matter? It will still be some form of
> > superset of Smalltalk I presume.
> > ---
> >
> > Ok, perhaps the above thoughts weren't that structured. In short I (me,
> > Göran that is) would like us to all cooperate in getting the core 
> > pieces
> > done right (browser, compiler, kernel) - regardless of Traits. That is
> > simply about doing things right.
> 
> Exact.
> for example having a visitor on an AST for prettyprinting, multiple 
> syntax,
> eventually byte code emition would be cool

Agree.

> > And then eventually I would like to see Traits enter core Squeak. I
> > think this would revitalize Squeak as a tool moving into the future and
> > not only being a mimic of some cool stuff people did in the early 70s.
> > Seriously.
> 
> Me too. But this is why we need feedback as andreas pointed it. We only 
> have 24 h a day
> and too much ideas, papers to write.

I know. Unfortunately we are all so busy... :-) 

> > And I would like to feel that the people working with Traits consider
> > Squeak both as the home of Traits but also as the community where 
> > Traits
> > grew and evolves.
> 
> Goran what is important is the synergy: if we come up with a cleaner 
> stabler squeak,
> then we could get a cleaner, stabler Traits model. After we can build 
> academic evolution
> and the Squeak Traits can stay or evolve at wish of the community.
> I think that what is important is that nobody got frustrated in both 
> sense.
> That's why I liked the email of andreas. Right now I'm looking at how 
> metaclasses property composition behaves in presence of traits but this 
> does not mean that we would have to refactor everything upfront.
> 
> Stef

Finally - I am confident we will make the best of this all. We just need
to start thinking in terms of how to manage the cooperation in the
community. Earlier this was not a "problem" because we more or less had
a benevolent dictatorship (SqC). Now when we are moving over into a
community shared mode with distributed "ownership" of packages etc, the
"tending" of the community turns into a much more complex job.

And given this I would like us to formulate - as a start - these package
groups I was talking about and how they should be allowed to depend on
each other. This will give us a "planning table" where we can place the
packages and see how they should/would/could relate to each other.

I think I need to fire up that issue again in another thread. It was a
mistake to put both in the same thread. ;-)

regards, Göran



More information about the Squeak-dev mailing list