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