Paolo Bonzini wrote: >> I may have given the wrong impression. The above is my opinion of the >> new syntax, and the reason why I think it's OK. It's not the official >> line, which is more "Let's make Smalltalk accessible", although that is >> perhaps a bit over-simplified. I think there is a consensus that the >> chunk format is unsatisfactory. > > The official line is actually a mix of "let's make Smalltalk accessible", > "let's make Smalltalk easier to parse" from external tools (i.e. your > motivation). And as far as accessibility is concerned, the point is > that *I* am also put down by the chunk format and would prefer a more > clear notion of scope in Smalltalk source. > > I don't want to transform Smalltalk into something else, I just think > that its strength is in the language and in the class library, not in > using message sends to define classes and methods.
I disagree: I think that its strength (one of many) lies in the consistency of the language - everything is (or can be) accomplished by message sends. I don't like magic in the compiler. >>> Object subclass: #SomeClass category: 'some category'. >>> SomeClass addMethod: 'printOn: aStream' for: 'printing' as: [ >>> " ... " >>> ]. > >>> It doesn't necessarily have to be a full-blown statement (by which I >>> mean that anything can be substituted for the literals) > > This gives me a more satisfying way to present the intended syntax! :-) > > Let's start from defining a new "message pattern" literal, which is > introduced by `( and terminated by ). We need a separate syntax > to distinguish the variable "negated" from the message pattern > `(negated). > > Now we can define methods as this: > > SomeClass define: `(printOn: aStream) as: [ :aStream | > ] > > So far so good. We have #define:as: defined in Behavior. > > An alternative possibility could be: > > SomeClass >> `(printOn: aStream) defineAs: [ :aStream | > ] This step starts to bother me: the CompiledMethod (SomeClass >> #printOn:) has been created before it has been defined. That wasn't true in the previous step. > Now, let's assume we can modify the compiler (as in Stephen Compall's > Presource thing!). Now, the `(...) delimiters for message patterns > are close to useless, because the syntax for binary or keyword messages > is unique and, for unary messages, the compiler could see the special > #defineAs: method and distinguish variables from message patterns. We > have thus: > > (SomeClass >> printOn: aStream) defineAs: [ :aStream | > ] > > This :aStream is useless too, because the compiler can fetch it from > the message pattern so that we have: > > (SomeClass >> printOn: aStream) defineAs: [ > ] > > and also > > (SomeClass >> printOn: aStream) category: 'foo' defineAs: [ > ] > > However, this adds to the repetitivity of the syntax, since every method > has to specify which class it is defined in. By using "scoped definitions" > as in the original proposal, we can drop "SomeClass >>". And by leaving > the "defineAs:" implicit, we can drop the parentheses at the cost of moving > the category inside the method as a pragma---which can also be seen as > an advantage. In fact, with scoped definitions it seems to me that all of the preceding arguments are moot. > If you would tell me which step bothers you the most, that could help > a lot. Actually, in spite of my comments, I *don't* have much of a problem with instance variables or instance methods at all. What bothers me is the class scoping and the class variables. What about declaring class variables using | | inside the class scope? Mike _______________________________________________ help-smalltalk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
