Why we should remove {} from Squeak

Bijan Parsia bparsia at email.unc.edu
Mon Oct 1 16:02:59 UTC 2001


On Mon, 1 Oct 2001, Andreas Raab wrote:

[snip]
> [Re: Difference between @ and {}]
> > There is a big different @ is a message
> > not a parsed construct with specific rules!!!!!
> 
> Sorry, but that's wrong. @ (and all binary operators) 

Just to be tidy (I *hope* I'm being tidy), I think the parenthetical
comment is part of the point. binary messages (i.e., a message *form* 
which can take *only* one argument, no more, no less) are reasonably
generic. And even reasonable extensible...it wouldn't be *that* hard to
add prolog style op() for binary messages (oh hell, let's call them
operators). Indeed, we could unify more syntax under that rubric (e.g.,
:=) with some finessing.

> are just that: Parsed
> constructs with specific rules. From a point of purety we don't need them.
> We could just write:
> 	(1 add: 2) times: (3 add: 4)
> and get exactly the same result that we get today from
> 	(1+2) * (3+4).
> So fundamentally there is no difference whatsoever between @ and {} - both
> are parsed constructs and both have specific rules.

I take it that the intended difference in the examples is that #@ is the
exemplar of a piece of more general syntax (binary messages, which
themselves are instances of messages in general), thus could be replaced
with other examples of that syntax (e.g., #+). {} on the other hand is
relatively uniqure and definitely special case...in the way that #() is
special case, and, indeed, ^ and :=.


[snip]
> Simplicity and purety are two different things. "Simple" can mean different
> things to different people. Originally, Smalltalk was intended to be a
> language for kids (but, alas!, how far away has it gotten) and I don't think
> that kids who learn in school that 4+5*6 equals 34 will find it simple that
> Smalltalk evaluates this to 54.

But those reading it aloud might, or those entering into a simple
calculator. It's very nice to be able to accumulate an intermediate result
and forget all that came before.Precedence is rarely all *that* simple :),
by any measure (except, maybe, character count when you eliminate the
grouping parens). I would be very interested to know if there were studies
about precedence error...many programming style guides encourage adding
parens to indicate precedence (or brekaing complext expressions into
subparts).

> They might find it pure if they can
> comprehend the reasoning behind it ... but simple?!

Unexpected, yes. Hard to get used to...maybe. But why wouldn't they find
it *simple*? I mean, right to left vs. all over the place....that seems
like a no brainer. No, it might be *too* simple for certain
purposes...perhaps even by introducing more complexity elsewhere.

[snip]

There are a lot of issues here, of course. E.g., other smalltalks are
using {} for a variety of things; there are packages (the prolog and lisp
interpreters) which use {} as an "escaping" mechanism...and whether having
a certain special form, all by itself, is worth it.

Personally, I tend not to use it since I rarely think to and, since I
don't use it, I find it a bit annoying because I don't remember exactly
what it does and how.

However, I *do* think that it deserves a bit of special care since it's
one of the relatively few grouping punctuation. We already use () and []
(and, indeed, overload ()). So perhaps there's a more general syntax use
of {} that we might want to use it for?Embedding sublangauges, maybe, or
just for macros. Prefixed with a #, it could be used for extended, user
defined, literals. (e.g., #{<URL:http://www.foo.org/>} could be equivalent
to 'http://www.foo.org' asUrl...ok, that's not much of a win :), so
#{http://www.foo.org.}).

Hmm. Actually, maybe just extending #() is the right thing, like
lisp...#S(...) or #I(2+3*5) (an infix package).

Finally, perhaps a Preferance...browseWithoutBraceConstruct? :)


Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list