help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax
Date: Mon, 12 Mar 2007 09:25:56 +0100
User-agent: Thunderbird 1.5.0.10 (Macintosh/20070221)

> 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.

>>     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 |
    ]

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.

If you would tell me which step bothers you the most, that could help
a lot.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]