A final word.
Once we will decide which Smalltalk we use we will be commited because 
we need it for other ideas :)


Stef


On Monday, February 17, 2003, at 09:25 AM, goran.hultgren at bluefish.se 
wrote:

> 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
>
>
>
Prof. Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes