I know I'm a heretic for even daring to mention things like alternative
syntaces for Smalltalk, but I've currently got a little
thought-experiment of designing a language with extremely intuitive
syntax for building abstractions, and because Smalltalk is a good point
to start at, I'm trying to improve on SmalltalkSyntax.  While not as
syntax-heavy as C++ or even Java, Smalltalk still has much more syntax
(and thus more that has to be learned on that side) than, say, Lisp or
Forth.

Some of these syntactic changes will also change the semantics of the
language.  It would be nice if people more familiar with Smalltalk than
myself would comment on their implications: for instance, if losing some
specific syntax will make some nifty programming idiom hard or
impossible, etc.

The ideas are:

0. abolish the difference between parenthesised expressions and blocks.

''A parenthesized block would execute all statements contained therein; returning the last statement, I assume?  ''(yes, quite consistently with the idea of abolishing ^, below.)''  What of empty parens?  Might be a good shortcut for self.'' (I don't know, I don't have any useful (and intuitive) semantics for empty parens in this scenario.)

Both parentheses and blocks contain code to be executed.  With blocks, it is deferred and may take parameters; with parentheses, it is immediately executed and may not take parameters.  It should be easy enough to defer only those parenthesised expressions that do not take parameters, or even all parenthesised expressions (using them as message
receivers would then force them to be evaluated.)

''Are parenthesized expressions objects in this scheme?  It appears not.''

Yes, they are.  They are blocks, and blocks are objects; but for example, nullary blocks could have a unary #value message that would force them to be evaluated...

1. define blocks with inline, rather than separate, variable declarations.

For example,
 [ :foo :bar | foo for: 'life' frobnize: bar ]
would become
 ( :foo for: 'life' frobnize: :bar )
or even, Arc-like
 ( _ for: 'life' frobnize: _ )

The syntax for these "inline variable declarations" could be something
else.  For example, instead of using colons, names beginning with
lowercase letters might always be variable names.

2. call blocks with descriptive, rather than generic, messages.

For example, if myBlock contained the block given in the previous point,
 myBlock value: aFoo value: aBar.
would become
 myBlock foo: aFoo bar: aBar.
Arc-like block definition could use the default message name, value:.

This would enable users to bind block parameters in different orders.
Moreover, the code looks cleaner.  There is a nice symmetry in foo: x
and :foo.

3. replace assignment with a set: message for symbols.

For example,
 a := 3
would become
 #a set: 3

Probably instance variables should have some special syntax.  How
about this (used by Self, I reckon?):
 address: anAddress
  address := anAddress
would become
 address: anAddress
  address: anAddress

4. abolish syntax for local variables.

Assignment is mostly needed in connection with local variables.  Local
variables are already better handled by using blocks; for example,
 |foo| foo := 2*bar. self speed: foo
becomes
 (self speed: :foo) foo: 2*bar.

If this "postfix binding" seems too weird or cumbersome, we could
introduce a "prefix message" syntax:
 foo: 2*bar (self speed: :foo)

5. get rid of ^.

Rather, just return the value of the last statement.  If one wants to
return "self", that's easy enough to write on the last line.

For example,
 name
  ^name
would become
 name
  name

And
 name: newName
  name := newName
would become
 name: newName
  name: newName
  self

(setting instance variables could also return self so the explicit self would be
unnecessary)

-- PanuKalliokoski

You really don't understand ^ if you think it's even possible, let alone a good idea, to eliminate non-local returns.

''I don't pretend to ''understand'' Smalltalk very well.  I'm just using it as a basis for this thought-experiment.  I'd like to see an example of a method that benefits a lot from ^.''

And what justification do you give for it? Just that Smalltalk doesn't return the value of the last expression, which is something completely independent of non-local returns.

Further, ^ can be turned into a message just as easily as :=. ^ is a message send to thisContext to unwind the stack.

''Well, I'm trying to drop off special syntax that seems unnecessary to ''me''.  The hypothesis is that all syntax adds to the effort of learning a language.  That hypothesis is challenged below -> ''

See also SyntaxVsSemantics for an explanation of the distinction between bad syntax and good syntax. You assume that having less syntax is automatically a good thing. It is not. For example, Lisp's lack of special syntax for lambdas is evil as far as I'm concerned. And your reinventing Lisp in Smalltalk isn't particularly inventive.

''I'm not assuming less syntax is automatically a good thing, but I think in general it is.  The precise reason I'm asking here about this is that I hope people to point out situations where this decrease of syntax does not pay off.  I'm not trying to score points off inventiveness, either.''

''On a less related track, Lisps have a lot of special syntaxes for lambdas.  For example, (defun) is one.  Or of course, it depends on what you consider "syntax".''

''Of course I'm trying to invent good syntax.  As I state at the beginning of this page, the purpose is to provide intuitive syntax for abstractions.''
----
See also SmalltalkLanguage

CategorySyntax