Eliminating assignments and variable syntax (accessors)

Marcel Weiher marcel at system.de
Thu Aug 5 07:44:35 UTC 1999


> From: Alan Lovejoy <sourcery at pacbell.net>
> >
> > I *have* thought about the consequences, and yes, they are bad.   
The
> > only point of the exercise is that they are a *little less bad*  
than
> > today.  Today I have to rewrite, with the change the compiler can   
> > recompile.  Which part of "a little better" don't you understand? 
>
> Well, I don't (yet) think your proposal is better (but who knows
> what I'll think tomorrow?).  Anyway, the crux of my objection to
> your proposal is that it is too static (binding is too early).

If that is your primary concern, once again, I don't understand why  
you don't see it as a little better, because it is a little less  
static than what we have today.

If we were designing from scratch, I could see this, but this is an  
idea for addressing some slight problems with the current setup.  The  
way I understood these problems was that on the one hand, direct  
instance var access makes code brittle, but on the other hand always  
using accessors was (1) less convenient, (2) slower and (3) made  
private variables impossible.

Alan stated the problem in the following way while pointing to a  
general solution and describing the B5000 hardware:

> From: Alan Kay <Alan.Kay at disney.com>
[..]
> I agree Andreas -- but we could also point the finger at  
Smalltalk-80 and
> ask why doesn't it have a slot class that would allow us to change the 
> meaning without having to worry about what the code looks like ... 
[..]

My idea was to do just that:  have something that allows  
redefinition of what access means (within the bounds of what is there  
right now) without worrying what the code *looks* like, although  
admittedly only at the source code level.  A meta-level slot class  
(that can act either at compile- or runtime) would be even nicer, it  
should probably replace the fixed and somewhat idiosyncratic rules  
for access in my proposal.

Anyway, one possible solution to this right now would be to make the  
"always use accessors" rule mandatory and ignore those who want  
either (1) convenience or (2) speed or (3) privacy.

('Convenience' includes those who don't really care either way but  
(i) simply don't bother to define accessors and (ii) use the most  
convenient syntax for variable access in their code.  As I think this  
includes novices, it would be good to have their default syntax be  
one that doesn't break later on)

Another solution would be your proposal, which implements (3) but  
doesn't do anything about (1) or (2).  The easiest, most convenient  
syntax for variable access is still direct access, which still leads  
to code that is just as brittle as it is today, and the same goes for  
fast access.  There are now 3 ways of accessing instance variables,  
each one with a different syntax.  In addition, while reading  
instance variables in your proposal use message-syntax (while  
potentiall meaning something different), writing variables uses  
direct access syntax.  So you access method is syntactically  
consistent neither with one of the previous methods, nor with itself!

My idea is to make the most convenient syntax mean message sends so  
it is non brittle(1), while also adressing (2)+(3) with the exact  
same mechanism.  My mechanism for addressing all three at once  
detracts very slightly from achieving (1); adding your mechanism  
would solve that so (1)+(3) would be fully addressed with (2) being  
left out in the cold a little and with the problem of subclasses  
redefining direct access in superclasses (and it seems we can't  
figure out wether it is good or bad).

The question now is wether we can live with a bit of recompiling  
(considering that this is still an improvement over the present  
situation) for possibly quite a bit of speed and no changes necessary  
to the VM, or wether we want to really clean up, modify the VM and  
leave the re-compiling to some future JIT compiler.  I think the  
difference isn't really that great except that one is a lot of work  
and the other isn't, so if I have to do it, I know what I'd choose.

Either way, the proposal also simplifies the syntax by removing  
direct variable assignment, addressing another concern with the  
language as it is now.

> From: Alan Kay <Alan.Kay at disney.com>
[...]
>      The problem in Smalltalk-80 is that the assignment to a  
variable is
> nonoop. Self did it better and tried to use the compiler to make up the 
> speed difference.
[...]

The SELF way (which is similar to your mechanism) is certainly much  
more elegant than what I proposed, but at much greater expense.  I  
also use the compiler to make up for the difference, but with  
slightly more complicated semantics that (a) are closer to the way  
things work now in Smalltalk and (b) much simpler to  
implement/optimize.  In an ideal world, I would vote for the cleanest  
solution, but with what we have now I think my proposal is a good  
compromise.  I'd also not see it as an alternative to the clean  
solution, but as a small, incremental change in that direction (keep  
what people like for now, but simplify the language in the right  
direction).

>  I'm also
> worried that code will become harder to understand because one
> would always have to check whether or not what looks like a message 
> send is actually just a simple access (direct to iVar or via method), 
> or is actually some non-trivial computation (this is the downside
> of the Self-style syntax).  But I'm not sure whether the latter  
point is
> important enough to outweigh the benefits of the symmetry of
> the Self-style syntax.

This was also my biggest concern, but I have slowly convinced myself  
that it isn't really a problem, because with direct ivar access  
removed from the surface of the language, the fact that some accesses  
are direct is really just an optimization that is valuable for now.

[...much agreeance snipped...]

[ using _a := b to mean a message send ]

> I see no difference whatsoever.  Both syntaxes imply one thing, but 
> may actually result in something else.

The difference is that inlining a message send is a  
semantics-preserving optimiziation that does *not* mean something  
else and is actually performed by optimizing compilers behind users'  
backs all the time (this case can be slightly different because of  
the subclass-override).  OTOH, implementing an assignment as a  
message send is not at all semantics preserving.

In other words, when I see a message send, I expect the unexpected,  
including that it does something simple (it's the same as now, after  
all, a message send now may also do something simple or something  
complicated).  When I see an assignment, I expect something simple  
and NEVER expect something complicated.

> My proposal has the added benefit of not making instance variable  
access
> public just because you want to use a method to do the access.  In  
fact,
> that's one of its two major points (the other being the late,  
dynamic binding).

Well, I think what you have is actually two proposals wrapped up in  
one.  One is for private messages as an *addition* to the VM, which I  
think has been debated here a while ago.  My proposal is for a  
*simplification* of the syntax and semantics in the direction of pure  
messaging, while leaving enough direct access semantics that no-one  
needs to feel left out just yet :-)

> I would not yet vote for my own proposal, by the way. To me, it's just  
> a thought experiment that may eventually, after improvement, lead to  
> something I would actually want to put into a programming language. 
> Or perhaps not--I don't know yet, the thought experiment is still
> running.

Same here.

Marcel





More information about the Squeak-dev mailing list