Eliminating assignments and variable syntax (accessors)

Ivan Tomek ivan.tomek at acadiau.ca
Mon Aug 2 21:18:01 UTC 1999


I would like to join those who oppose this valiant proposal. The main 
problem for me is that it complicates the beautifully simple and uniform 
syntax of Smalltalk: As an example, a: b does not have a receiver. I 
consider the simple syntax one of the great things about Smalltalk 
both for learning and for code readability.

If anything were to be done with variables, I would suggest making 
them first-class objects. As they are, they are different from 
everything else and break the uniformity of the language. 
Assignments could then be handled for example as

var assign: x

thus removing the need for the assignment statement while 
maintaining the syntax. A lot of other things could also be done more 
easily such as (pseudocode)

(Array with: selectedVariables) do: [:var| var assign: Strinbg new]

instead of

a := ''.
b := ''.
c := ''.
etc.


Ivan

> Thanks for taking the time in looking over my (admittedly pretty  
> rough) idea.
> 
> > From: "Jarvis, Robert P." <Jarvisb at timken.com>
> >
> > I don't like the idea of implicit targets.  One of the great  
> beauties of
> > Smalltalk is its simple and very regular grammar.  In my opinion adding
> > implicit targets would make the grammar more complex and less regular
> > without a corresponding gain in clarity or expressiveness.
> 
> Yes, I also don't want to mess the syntax up.  However, for  
> 'reading' accesses, there is no (visible) change in syntax, it's just 
> that what used to be variable references are now interpreted as  message
> sends.  That seems like a simplification to me.
> 
> The only 'addition' is that for assigning values, instead of writing:
> 
>  a := b.
> 
> you would write
> 
>  a: b.
> 
> Considering that the colon syntax is also already in use, and that  
> := gets removed, that also seems to be a simplification of the  
> visible syntax, overall (a slight complication and a medium  
> simplification).  As a matter of fact, the compiler could treat  a:=   as
> equivalent to a:  I have to admit that I haven't considered what  this
> will do to the compiler, though.
> 
> > I just don't see
> > a great advantage here.  It seems more like a hint to the compiler  
> than an
> > aid to the human.
> 
> Well, the aid is that there is now only message sends, assignments  
> have been eliminated from the language or at least hidden from view.   The
> practical benefit I have in mind is that the decision wether  access to an
> instance variables is direct or via accessors is made in  one place
> instead of everywhere the variable is accessed.   Currently, if I have
> direct instance variable access, I write.
> 
>  myInstanceVar doSomething.
> 
> If I have accessors, I write
> 
>  self myInstanceVar doSomething.
> 
> *everywhere* I use myInstanceVar.  The same goes for write-access:
> 
>  myInstanceVar := newValue
> 
> versus
> 
>  self myInstanceVar:newValue.
> 
> The problem is that changes to the access policy are very expensive 
> because every method *accessing* the instance-var/accessor has to be 
> changed.  Therefore, your (absolutely correct, IMHO) proposition that  all
> instance var access be done with accessors first and directly  only when
> absolutely necessary means that a lot of code has to  potentially be
> modified in the latter case.  With lots of coders  being prone to
> premature optimiziation, they will opt for direct  access instead,
> especially since it is also less typing.
> 
> With my proposal, code can always be written as if it is using  
> accessors, making it non-brittle, but at the same time it enjoys all  the
> benefits cited for direct variable access (privacy, speed, less  typing,
> etc.)  So, I just write
> 
>  myInstanceVar doSomething.
> and
>  myInstanceVar:newValue.
> 
> and this very same code will use accessors if available or direct  
> access if not.
> 
> >  Also, if := is eliminated how is a reference assigned to
> > a temporary variable?
> 
> Trickery.  Just like with instance variables, the compiler detects  
> that there is a local variable of that name and emits the direct  
> access code instead.  I know this sounds a little insane (turn the  
> access into a message send and then auto-reduce it back to an  
> access), but there is some method to the madness :-)
> 
> Regards,
> 
> Marcel
> 



Ivan Tomek,

Jodrey School of Computer Science
Acadia University
Wolfville,
Nova Scotia, Canada, B0P 1X0

fax: (902) 585-1067
voice: (902) 585-1467


> Hey, it's monday, I haven't woken up properly yet!

It must take you a couple of days because its Tuesday
where I am (and all of the world by now) <gg>

8-)





More information about the Squeak-dev mailing list