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

[parasti]

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 personally feel that the use of message sends to do everything is a
defining characteristic of Smalltalk.

This is not related to your comment, but if there's anything that would
considerably help GNU Smalltalk's "acceptance", so to say, it's better
documentation, better package distribution, bindings to various external
libraries, and perhaps binaries for Microsoft's Windows platform.  It's
not changing GNU Smalltalk's syntax.

As I was typing an example of how Python compares to GNU Smalltalk in
order to show something that I no longer remember the details of, I
realized that I had it all wrong and the example incidentally quite
clearly demonstrates the shortcomings of the bang-separated chunk
format.  Heh.  I'm including the example.  This is copied from the
Python tutorial:

    class MyClass:
        "A simple example class"

        i = 12345

        def f(self):
            return 'hello world'


Here's the same code in GNU Smalltalk as I would have written it:

    Object
        subclass: #MyClass
        instanceVariableNames: 'i'
        classVariableNames:    ''
        poolDictionaries:      ''
        category:              ''!

    MyClass comment: 'A simple example class'!

    !MyClass class methodsFor: 'instance creation'!
        new
            ^super new
                initialize;
                yourself!
    !

    !MyClass methodsFor: 'initialization'!
        initialize
            i := 12345!
    !

    !MyClass methodsFor: 'random'!
        f
            ^'hello world'!
    !

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

I appreciate that you took the time to explain this in detail.  It's
helpful.  Now the only thing that bothers me is the "pragma" syntax for
categories and class comments.  I can not think of a different equally
distinguishable way to display a method's category, but that syntax
seems to suggest that a category is treated somehow specially.  However
true it may be, documentation features are best when they're integral.
What about keeping the parentheses and #for: (instead of #category:), or
using the first comment after the opening bracket to determine the category?

Here's how I imagine the example above would look with a new "scoped"
syntax:

    Object subclass: #MyClass.
    MyClass comment: 'A simple example class'.

    Class name: MyClass [
        i := 12345.

        f [
            "category: random"
            ^'hello world'
        ]
    ]

  * Classes are defined by sending #subclass: or #subclass:category:.
  * Classes are commented with #comment: as usual.
  * Method definitions and re-definitions are carried out the same way
with "Class name: MyClass [".
  * Class methods are defined and re-defined with "Class name: MyClass
class [".
  * Class and instance variables are defined the same way, except that
class variables are defined within class method definition scope and
instance variables -- within instance method definition scope.

One of the things that I consider important is the distinction or rather
lack of distinction between class methods and instance methods;  that
classes objects to the same amount their own instances are.  It was
something I was unaware of and Smalltalk made it instantly clear without
lumping them together.  I think it should be kept that way.

Something that I didn't notice in the examples was pool dictionaries.  I
can't say I've seen any examples of how they're actually used in
practice but since they have to be declared in the usual class
definition, they're probably used for something.  Will there be syntax
to handle them?

Jānis