[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 03:32:00 +0200
User-agent: Icedove (X11/20061220)

I'm resending this mail because I think I messed something up and it
didn't make it to the list.  Sorry for any inconvenience.



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[1] 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)

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

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

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

  * Class method definitions alongside instance method definitions is messy.

  * Category per method seems redundant.  There are usually several
methods per category.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]