assignment (was: macros / code construction)

["Jecel Mattos de Assumpcao Jr." <jecel@lsi.usp.br>]

On Thu, 31 Aug 1995 00:03:54 +0200,
rainer@physik3.gwdg.de (Rainer Blome) wrote;
>imagine doing assignment another way.  assignment is a hack (from the
>functional point of view).  it manipulates its context.  one should make
>that explicit by revealing the reflection involved in assignment.  first
>get an object that represents the place (the slot).  that is the reflective
>part.  then send it a normal message with the new value as an argument:
>
>(reflect: self slot: "x") store: 1

On Wed, 30 Aug 1995 16:26:55 -0700,
ungar@self (David Ungar) wrote:
> We have had lots of discussions about
> assignment, but what it boils down to for me is
> that containers are appealingly intuitive notion,
> and so I am happy to ground out where it does.
> Going deeper does not seem to me to buy so much.

Here is who I did it in tinySelf: every slot in a map has a name,
a value and a "type". The type is actually just a pointer to some
code that gets called with the value as an argument. Right now
this field points to C functions, but it would point to pre-compiled
Self code in the future, allowing the user to create new slot
types. Currently, these are the types that are avaiable:

    - constant: this code simply pushes the value on the stack

    - data: this code pushed *(self+value) on the stack

    - assignment: this code pops the stack and stores it in *(self+value)

    - code: this calls the interpreter with value, which is a method
            object

When I write the compiler later, it could simply replace the pointer
to the interpreter in "type" by a pointer to the newly generated code
( which would ignore "value", of course ). I won't do it this way,
but the main idea it that "compiled code", "primitives" and the
"assignment primitives" should all be made from the same stuff.

On Mon, 15 Oct 90 14:40:43 PDT ( note the date - I have a good memory ;-),
ungar@thoreau (David Ungar) wrote:
> We believe strongly in the benefits of reusing the same code with different
> representations. This implies that the code may not distinguish between 
> reading a variable and invoking a function.
>
> How to model this in a programming language?
>
> One way would have been to have different kinds of slots: data slots and 
> code slots. Had we done this we could have had functions which only 
> evaluated when fetched out of a code slot.
>
> We rejected this approach on two grounds:
>         1. clutter caused by multiple slot types
>         2. functions considered harmfull.
>                 In OOP a receiver gets to decide what code to run. But if
>                 you have functions they always do the same thing no matter
>                 what the objects are.
>                 I believe that functions perniciously weaken the power of 
>                 data abstraction by taking control away from the objects,
>                 and by packaging up code without data.
>
> So, we opted for one slot type, and a model that says that an object is
> always executed when fetched from a slot. Most objects simply return 
> themselves when they execute.
>
> As a result, you cannot have a naked method in Self, because it would have
> run when you fetched it, and you would have gotten the result of the method.
> So, we have mirrors. A mirror is a way to handle an object without 
> evaluating it, much like a "ten foot pole". When doing reflective 
> computation (as your example does) always stick with mirrors.

I am not very happy with my solution of slot types, but I don't expect
it to break any existing code. It is true that if you store a method
object into a data slot, it will *not* be executed when you try to
fetch it. But I don't think it is even possible to store a method in
a data slot in Self 4.0, is it?

It is strange how close assignment is to argument initialization -

           (| x |) x: 9

           [| :x | ... ] value: 9

I used a block in this example to ignore the cloning that goes on in
the argument initialization. The difference is that arguments are
initialized by the *position* while the assignment works by *name*.

Beta almost managed to unify these two notions, but didn't quite
manage it. BTW, the more I learn Beta, the more I like Self! 
( though I did find Beta much more fun than Oberon or C++ )

-- Jecel