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