[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax
From: |
parasti |
Subject: |
Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax |
Date: |
Sat, 10 Mar 2007 21:36:40 +0200 |
User-agent: |
Icedove 1.5.0.9 (X11/20061220) |
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
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, (continued)
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, Sungjin Chun, 2007/03/09
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, parasti, 2007/03/09
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax,
parasti <=
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, Mike Anderson, 2007/03/11
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, parasti, 2007/03/11
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, Paolo Bonzini, 2007/03/12
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, parasti, 2007/03/12
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, Paolo Bonzini, 2007/03/13
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, Stewart Stremler, 2007/03/13
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, Paolo Bonzini, 2007/03/13
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, Stewart Stremler, 2007/03/14
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, Mike Anderson, 2007/03/13
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, parasti, 2007/03/13