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

[Mike Anderson]

parasti wrote:
> 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.  :)

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.

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

Your example is closer to what I would like to use, but I don't think
that means that we can't give the new syntax a try.

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

Only the <category> is new, you know. If you are saying that you find
Smalltalk syntax ugly in general, I don't agree.

Mike