Two important issues...
goran.hultgren at bluefish.se
goran.hultgren at bluefish.se
Mon Feb 17 08:25:33 UTC 2003
(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
> > 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
> 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
> 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
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.
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.
> for example having a visitor on an AST for prettyprinting, multiple
> eventually byte code emition would be cool
> > 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
> 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.
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. ;-)
More information about the Squeak-dev