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

[parasti]

Hi Mike,

> My personal feeling is that you can regard [] as indicating a block of
> code (not a BlockClosure) with deferred execution, as opposed to (),
> which indicates a block of code with immediate execution. Although the
> real situation is more complicated than that, I don't think that it is
> particularly misleading. After all, blocks themselves can be full blocks
> (closures) or not, and it is up to the programmer to recognise the
> difference if it matters.
> 
> The bang-delimited syntax is difficult to parse properly, even with full
> parser. This is because #methodsFor: switches the compiler from one mode
> to another. If you were to wrap it in another method, the parser would
> be unaware that that method is also 'special'. With the [] syntax for
> methods, you do not have this modality, so the situation does not arise.

Thanks for the explanation.  I had suspected that it might have
something to do the internals of the compiler, but I'm afraid I don't
know much about that.  I do, however, recognize it as a valid concern,
unlike, say, the "let's make Smalltalk accessible" approach which is
really the "let's make Smalltalk some other language" approach.  :)

To the point, what I do not really understand is why special syntax is
necessary.  I mean, why:

    Class name: SomeClass extends: Object [
        <category: 'some category'>
        printOn: aStream [
            <category: 'printing'>
            "..."
        ].
    ].

instead of:

    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), just so that it
looks like proper Smalltalk, putting emphasis on "if classes are created
by sending messages, then methods must be as well!"  Or is the special
syntax exactly the solution to the problem?  I'm quite sure that the <>
syntax is not necessary for that.

>>   * Readability issues in message definitions where
>>
>>       <category> is followed by a
>>       "comment", some
>>       | temporary variables |, and an
>>       ^answer.  That's now four kinds of delimiters/operators each on
>> its own line.
> 
> I would hope that the syntax is still free-form, and all four of those
> are optional, are they not?

Of course, you're absolutely right.  :)  It's just something I use as a
general guideline when it comes to programming:  "if it looks ugly, it
probably is," and it does look ugly.  But, as I said, not everybody
would find that to be a problem.

Jānis