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
|