Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax

[Mike Anderson]

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