[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax
Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax
Sat, 10 Mar 2007 13:11:08 +0000
Thunderbird 220.127.116.11 (X11/20061025)
> Paolo Bonzini wrote:
>> Hi everybody,
>> in the next few months, Daniele Sciascia will work on the
>> implementation of a scripting syntax for GNU Smalltalk. The aim of
>> this is to provide a better programming experience than is possible
>> with the file-out (bang-separated chunks) format.
> Hi Paolo. First of all, I have only been reading this list for a couple
> of months, so I might not be aware of all the reasons behind such
> changes. I did find and read a related discussion in the archives,
> though. If there's anything I'm missing, please let me know.
> I'm also a Smalltalker for a bit longer than I've been reading this
> list, but one thing that I can immediately name as the reason I'm not
> looking back is the single-paradigm approach which actually works and is
> well reflected in Smalltalk's own syntax. Which in turn is the main
> reason why I prefer the bang-separated format over the proposed.
> The biggest issues I have with the syntax are:
> * block-like delimiters
> First, they're block-like, but they're not really blocks, which is
> nothing but confusing. Second, the introduction of these seems to be a
> step in a direction other than where most "modern" languages, such as
> Ruby, Python or Lua, are headed. They use keywords, a keyword, or even
> white space to separate chunks. Even without following "the lead",
> using a bang seems like a non-intrusive (brackets degrade readability)
> and natural (with respect to Smalltalk's use of semi-colons and periods)
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.
> * <keyword: some arguments> syntax
> This is something I'm not fond of in the bang-separated format either.
> Special syntax for call-ins is acceptable (as a preprocessor kind of
> thing), but is not for integral stuff such as class comments and
> class/method categories.
> * class and method definitions
> By that I mean things such as "Class name: NullChessPiece extends:
> Object [" and "ChessPiece class >> test: side [". They look like
> message sends, with the difference that one of them references an
> undefined variable "NullChessPiece" and both contain syntax errors. If
> they're meant to look like message sends, then please make them look
> like valid message sends. Or, you could make them look entirely
> different, but that would just introduce another special case in the syntax.
Although I don't object to the syntax quite as much as you do, I do
think that some of the examples seem to violate the normal selector
precedence, and that is a Bad Thing. In particular this:
ChessPiece class >> test: side [ ... ]
Class name: RandomInteger class [ ... ]
> Then there are also a few minor other things that most people would not
> find to be a problem at all:
> * "Object subclass: #SomeClass" is shorter and more to the point than
> "Class name: SomeClass extends: Object".
I agree. My opinion is that the first advertises the fact that
Everything Is An Object. Still, I can live with it.
> * 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?
> * Class method definitions alongside instance method definitions is messy.
> * Category per method seems redundant. There are usually several
> methods per category.
In a subclass, I think that tends to be untrue. One of the annoyances I
find in writing in the chunk format is having to have a separate
#methodsFor: for each new method. In fact, I tend to just shove
everything into an 'everything' category to save the effort.
> Of course, I should say that none of this is a big deal if the changes
> are made entirely optional. But I really like to think that they got it
> right in the seventies and that the minimalistic bang-separated format
> pretty much follows that approach.
> Jānis Rūcis
>  http://lists.gnu.org/archive/html/help-smalltalk/2006-09/msg00095.html
- [Help-smalltalk] [RFC] Smalltalk scripting syntax, Paolo Bonzini, 2007/03/09
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, Stefan Schmiedl, 2007/03/09
- 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,
Mike Anderson <=
- Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax, parasti, 2007/03/10
- 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