Thanks for the explanations.  What troubles me is that the grammar of the
language now becomes more complex, in my opinion, rather than simpler.  With
this proposal Smalltalk would now have "normal" message sends, of the form
"<object> <message> {<optional arguments and keywords>}" and "implicit"
message sends, of the form "<message> {<optional arguments and keywords>}".
Maybe I'm just in reactionary mode today (I'll be one of the first against
the wall when the revolution comes, no doubt :-) but it just doesn't seem to
"flow" as nicely to me.

Maybe we should go a step further and consider how to eliminate variables.
Without variables and their required assignment syntax this issue becomes
moot.  Functional Smalltalk, anyone?  (Before anyone gets too wound up about
this, let me hastily add that the functional languages I've seen are not my
cup of tea, heavy on the static strong typing and light on the practically
useful.  I do think that some of the ideas of functional programming, such
as the elimination of state and delayed expression evaluation, could be
potentially useful, but I haven't a clue how to go about this).

Bob Jarvis
The Timken Company

> -----Original Message-----
> From:	Marcel Weiher [SMTP:marcel at system.de]
> Sent:	Monday, August 02, 1999 3:16 PM
> To:	squeak at cs.uiuc.edu
> Subject:	Re: RE: Eliminating assignments and variable syntax
> (accessors)
> 
> 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