alternative to arithmetic assignment
Alan Kay
Alan.Kay at squeakland.org
Thu Jun 20 06:42:29 UTC 2002
Allen --
I've always been a fan of single assignment expressions ...
Cheers,
Alan
------
At 3:06 PM -0700 6/19/02, Allen Wirfs-Brock wrote:
>Who needs assignment! It actually would be pretty easy to eliminate
>the assignment operator from Smalltalk:
>
>1) Treat method and block parameters as immutable bindings of the
>names to the argument values.
>2) Automatically generate setter methods for all instance variables.
>3) If you care, define a message based setter protocols for
>Global/Pool/Class variables.
>4) Remove the assignment operator from the compiler.
>
>Of course, it can be argued that naming intermediate results by
>assigning them to appropriately named local "variables" makes
>methods more readable. If you believe that then consider keeping the
>assignment operator but treat is as a "static single assignment".
>Only one assignment is allowed to each name in any scope and the
>assignment must precede the first reference.
>
>Have fun,
>
>Allen
>
>
>
>
>
>
>
>
>
>
>
>
>
>At 12:39 PM 6/19/2002 -0700, you wrote:
>>Why not solve this in a somewhat more object oriented fashion and in a way
>>that perhaps fits in a little more nicely with Smalltalk syntax?
>>
>>If we introduce a notion of a "locative", a reference to an
>>assignable location, as found in Lisp, then the update operations
>>themselves can be expressed as normal messages:
>>
>> x is + 4.
>>
>>Of course, "is" has to be special syntax (if you don't like "is",
>>it could be "becomes" or "changesBy" or maybe just "by"). The compiler
>>would transform this into the equivalent of "x := (x + y)",
>>giving you the same efficiency as a dedicated "+=" operator,
>>although it looks and behaves just as if a locative object
>>had been created.
>>
>>Since this would work only for variables, one might also consider
>>extending it in a way somewhat analogous to "setf" definitions in Lisp:
>>something like "(x foo: i bar: j) is + 4" might get transformed by the
>>compiler into "x foo: i bar: j is: (x foo: i bar: j)".
>>
>>For more general transformations, you might allow locatives to
>>be created and manipulated:
>>
>> x at += 4.
>>
>>Again, for non-variable LHS's, this might turn "(x foo: i bar: j) at"
>>into "(x foo: i bar: j at: nil)", which should return a locative.
>>
>>To make it easy to write methods that perform updates on locatives,
>>by default, all messages to a locative should be forwarded to the
>>same selector on the object contained in the location pointed to,
>>with the locative as the first argument and the remaining arguments
>>passed along after that.
>>
>>A simple representation of locatives is a lexical closure.
>>With lexical block closures, "x at" would turn roughly
>>into "[:val | x := val]", although updating should probably
>>happen via an "update:" method.
>>
>>So, to summarize the different possibilities:
>>
>>Level 0:
>>
>> Add a little bit of syntax that turns "x is something" into
>> "x := (x something)".
>>
>>Level 1:
>>
>> Add a little bit of syntax that turns "(x sel: y) is something"
>> into "x sel: y is: ((x sel: y) something)", but give the
>> compiler freedom in whether to evaluate "x" and "y" once or twice.
>>
>>Level 2:
>>
>> Introduce a "Locative" class with an "update:" method and forwarding.
>> Add a little bit of syntax that turns "x at" into
>> a Locative referring to the variable.
>> Add a little bit of syntax that turns "(x sel: y) at" into
>>
>>Note that neither "is" nor "at" are currently used as selectors in the
>>standard Squeak image.
>>
>>Tom.
>>
>>--- Andreas Raab <Andreas.Raab at gmx.de> wrote:
>>> Richard,
>>>
>>> Just two little notes on your message: a) I never claimed to solve
>>> *your* problems as you seem to be implying. I solved a problem that I
>>> have (and no amount of theoretical discussion will change this). b) Yes,
>>> I know this is Smalltalk but I don't give the least bit. If I want to do
>>> an experiment I'll do it ;-) It's your right to hate it or love it, but
>>> *please* don't start telling me that I must not do any experiments just
>>> because "This is Smalltalk".
>>>
>>> Cheers,
>>> - Andreas
>> >
>>>
>>> > -----Original Message-----
>>> > From: squeak-dev-admin at lists.squeakfoundation.org
>>> > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On
>>> > Behalf Of Richard A. O'Keefe
>>> > Sent: Wednesday, June 19, 2002 5:08 AM
>>> > To: squeak-dev at lists.squeakfoundation.org
>>> > Subject: RE: [GOODIE] Arithmetic assignments (+= and friends)
>>> >
>>> >
>>> > I now understand the += proposal.
>>> > Let me see if I can respond to some of my own points.
>>> >
>>> > (1) += HAS to be a binary selector rather than a compound from a
>>> > binary selector and an assignment symbol because it IS a
>>> > binary selector.
>>> >
>>> > (2) There is a marked syntactic difference from other binary
>>> > selectors, however. The thing on its left must be a
>>> > simple variable.
>>> >
>>> > (3) The effect of var $= exp, for some selection of $ binary
>>> > selectors,
>>> > is
>>> > var := var perform: #$= with: exp
>>> > although presumably it would be implemented using a direct message
>>> > send rather than really using #perform:with:
>>> >
>>> > (4) The complaints by several people that writing x := x + y
>>> > just isn't
>>> > a big deal miss the point. The point is to have notational
>>> > uniformity between updating an object (which is the value of x)
>>> > that can increment itself and updating a variable (whose value
>>> > is immutable and cannot increment itself).
>>> >
>>> > (5) There could very well be an automatic relationship
>>> > between $= and $.
>>> > Add to object a bunch of methods like
>>> > $= anObject
>>> > "Implement the $= for immutable receivers.
>>> > Mutable receivers should override this with
>>> > something better."
>>> > ^self $ anObject
>>> > (Here as elsewhere, replace $ by +, -, *, /, and so on.)
>>> >
>>> > This proposal doesn't solve any problem that I have.
>>> > However, it does create some problems.
>>> >
>>> > (a) If I *should* happen to create a -= method for some class
>>> > (such as Polynomial, maybe) it will no longer be legal for me
>>> > to write (srs at: 1) -= monomial.
>>> >
>>> > It will need an exceptionally well worded error message to explain
>>> > why what seems like (and according to all current
>>> > textbooks, IS) an
>>> > ordinary binary selector "misbehaves".
>>> >
>>> > (b) If I *think* x and y hold oops to mutable things like Points,
>>> > but I'm wrong, then x += y will not only appear to succeed,
>>> > it will change the value of x, which may come as a nasty surprise.
>>> >
>>> > (c) There are a whole bunch of update assignments one would
>>> > like to have
>>> > such as raisedTo:=, min:=, max:=, for which the efficiency and
>>> > uniformity arguments are equally compelling, but which *cannot* be
>>> > handled this way. For somewhat different reasons, while
>>> > vectorwise
>>> > logical operations make sense, |= is unavailable.
>>> >
>>> > If this were Perl, I'd say "fine, go ahead, one more wart on the
>>> > gargoyle." This is Smalltalk. I think the idea creates more problems
>>> > and inconsistencies than it removes. The e-correspondence so far has
>>> > shown that it's quite good at confusing people.
>>> >
>>> > Nothing actually stops anyone writing
>>> > x := x += y
>>> > right now, and nothing (Smalltalk, got to love it) stops anyone
>>> > adding += and friends to Number. So most of the apparent benefits
>>> > can be obtained with no compiler changes.
>>> >
>>> > Now can I have {v1. v2. v3} := expr back? (:-) (:-)
>>> >
>>> >
>>>
>>>
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Yahoo! - Official partner of 2002 FIFA World Cup
>>http://fifaworldcup.yahoo.com
--
More information about the Squeak-dev
mailing list
|