Selectors with underscores

> At Fri, 12 Mar 2010 20:01:41 +0100,
> Stéphane Rollandin wrote:
>>
>> > IMHO, both := and _ are wrong choices. To be consistent with selector
>> > conventions, it should have been =: ( for assign:). But I guess it is too late
>> > now.
>>
>> ah, but _ is not a selector
>>
>> now if a newly created identifier symbol was automatically bound to a
>> specific instance of ProtoObject, instead of nil which is the sole
>> instance of UndefinedObject, then =: could be implemented in ProtoObject
>> as syntactic sugar for becomeForward:
>>
>> or am I wrong here ?
>
>  Hehe.  But if a variable (say an instance variable "x" of an object
> "obj") already has a non-nil value, what does that mean?
>
>  In Smalltalk 72, the left arrow was a message to an atom, in deed.
> The index finger hand literal object can be sent a string to get an
> atom object and it in turn can receive an left arrow message with an
> argument.  You can assign atom into another variable.  You can define
> the left arrow message for a collection to mean "add" instead assign.
> For an instance variable, you can use "'s" message followed by a
> string also to get the corresponding atom in the reciver context.
>
> -- Yoshiki
>

>
> 2010/3/17 Yoshiki Ohshima <[hidden email]>:
> > At Fri, 12 Mar 2010 20:01:41 +0100,
> > Stéphane Rollandin wrote:
> >>
> >> > IMHO, both := and _ are wrong choices. To be consistent with selector
> >> > conventions, it should have been =: ( for assign:). But I guess it is too late
> >> > now.
> >>
> >> ah, but _ is not a selector
> >>
> >> now if a newly created identifier symbol was automatically bound to a
> >> specific instance of ProtoObject, instead of nil which is the sole
> >> instance of UndefinedObject, then =: could be implemented in ProtoObject
> >> as syntactic sugar for becomeForward:
> >>
> >> or am I wrong here ?
> >
> >  Hehe.  But if a variable (say an instance variable "x" of an object
> > "obj") already has a non-nil value, what does that mean?
> >
> >  In Smalltalk 72, the left arrow was a message to an atom, in deed.
> > The index finger hand literal object can be sent a string to get an
> > atom object and it in turn can receive an left arrow message with an
> > argument.  You can assign atom into another variable.  You can define
> > the left arrow message for a collection to mean "add" instead assign.
> > For an instance variable, you can use "'s" message followed by a
> > string also to get the corresponding atom in the reciver context.
> >
> > -- Yoshiki
> >
>
> Even in st80, instVarAt:put: and tempAt:put: still are messages
> anyway. It's just that there is a nicer syntax, and an optimized
> byteCode, but strictly speaking, Smalltalk does not require any
> assignment, nor does it require jumps.
> Think of basicAt:put:, it does nor even have a special syntax nor a
> byteCode (well, maybe I should check new closure byteCodes, but no
> image running).

> At Fri, 12 Mar 2010 20:01:41 +0100,
> Stéphane Rollandin wrote:
>>
>>> IMHO, both := and _ are wrong choices. To be consistent with selector
>>> conventions, it should have been =: ( for assign:). But I guess it is too late
>>> now.
>>
>> ah, but _ is not a selector
>>
>> now if a newly created identifier symbol was automatically bound to a
>> specific instance of ProtoObject, instead of nil which is the sole
>> instance of UndefinedObject, then =: could be implemented in ProtoObject
>> as syntactic sugar for becomeForward:
>>
>> or am I wrong here ?
>
>    Hehe.  But if a variable (say an instance variable "x" of an object
> "obj") already has a non-nil value, what does that mean?

> Le 17/03/2010 19:32, Yoshiki Ohshima a écrit :
>>
>> At Fri, 12 Mar 2010 20:01:41 +0100,
>> Stéphane Rollandin wrote:
>>>
>>>> IMHO, both := and _ are wrong choices. To be consistent with selector
>>>> conventions, it should have been =: ( for assign:). But I guess it is
>>>> too late
>>>> now.
>>>
>>> ah, but _ is not a selector
>>>
>>> now if a newly created identifier symbol was automatically bound to a
>>> specific instance of ProtoObject, instead of nil which is the sole
>>> instance of UndefinedObject, then =: could be implemented in ProtoObject
>>> as syntactic sugar for becomeForward:
>>>
>>> or am I wrong here ?
>>
>>   Hehe.  But if a variable (say an instance variable "x" of an object
>> "obj") already has a non-nil value, what does that mean?
>
> Well, a variable always has a value, nil or non-nil, so I don't really see
> your point. The thing with the nil value, is that it is shared by all other
> objects having a nil value. If all nils weren't the same nil, we could
> becomeForward: any of them into existence as a defined object (in contrast
> with an UndefinedObject)
>
> Is there a reason, historical or technical, why we need to have only a
> unique instance of UndefinedObject ?
>
> Stef
>

>
> Le 17/03/2010 19:32, Yoshiki Ohshima a écrit :
> > At Fri, 12 Mar 2010 20:01:41 +0100,
> > Stéphane Rollandin wrote:
> >>
> >>> IMHO, both := and _ are wrong choices. To be consistent with selector
> >>> conventions, it should have been =: ( for assign:). But I guess it is too late
> >>> now.
> >>
> >> ah, but _ is not a selector
> >>
> >> now if a newly created identifier symbol was automatically bound to a
> >> specific instance of ProtoObject, instead of nil which is the sole
> >> instance of UndefinedObject, then =: could be implemented in ProtoObject
> >> as syntactic sugar for becomeForward:
> >>
> >> or am I wrong here ?
> >
> >    Hehe.  But if a variable (say an instance variable "x" of an object
> > "obj") already has a non-nil value, what does that mean?
>
> Well, a variable always has a value, nil or non-nil, so I don't really
> see your point. The thing with the nil value, is that it is shared by
> all other objects having a nil value. If all nils weren't the same nil,
> we could becomeForward: any of them into existence as a defined object
> (in contrast with an UndefinedObject)

> At Wed, 17 Mar 2010 22:35:31 +0100,
> Stéphane Rollandin wrote:
>>
>> Le 17/03/2010 19:32, Yoshiki Ohshima a écrit :
>> > At Fri, 12 Mar 2010 20:01:41 +0100,
>> > Stéphane Rollandin wrote:
>> >>
>> >>> IMHO, both := and _ are wrong choices. To be consistent with selector
>> >>> conventions, it should have been =: ( for assign:). But I guess it is too late
>> >>> now.
>> >>
>> >> ah, but _ is not a selector
>> >>
>> >> now if a newly created identifier symbol was automatically bound to a
>> >> specific instance of ProtoObject, instead of nil which is the sole
>> >> instance of UndefinedObject, then =: could be implemented in ProtoObject
>> >> as syntactic sugar for becomeForward:
>> >>
>> >> or am I wrong here ?
>> >
>> >    Hehe.  But if a variable (say an instance variable "x" of an object
>> > "obj") already has a non-nil value, what does that mean?
>>
>> Well, a variable always has a value, nil or non-nil, so I don't really
>> see your point. The thing with the nil value, is that it is shared by
>> all other objects having a nil value. If all nils weren't the same nil,
>> we could becomeForward: any of them into existence as a defined object
>> (in contrast with an UndefinedObject)
>
>  Oh, I interpreted what you said as something like:
>
>    | a b | "create new variables.  (identifier symbols?)"
>    a gets: b.  "???"
>    a gets: 3.  "one of such ProtoObject is becoming 3".
>    a gets: 4.  "???"
>
> and didn't know what would happen.
>

> it won't go that way, because #becomeForward: replacing all references
> to same object:
>
> a := z.
> b := z.
> (here a and b pointing to same object - z)
>
> b := x.
>
> now, 'a' should still point to 'z', while 'b' should point to 'x'.
> but if you do z becomeForward: x , then both a and b will point to x.

>> it won't go that way, because #becomeForward: replacing all references
>> to same object:
>>
>> a := z.
>> b := z.
>> (here a and b pointing to same object - z)
>>
>> b := x.
>>
>> now, 'a' should still point to 'z', while 'b' should point to 'x'.
>> but if you do z becomeForward: x , then both a and b will point to x.
>
> right. that's what I missed :)
>

>
> 2010/3/18 Stéphane Rollandin <[hidden email]>:
>>> it won't go that way, because #becomeForward: replacing all references
>>> to same object:
>>>
>>> a := z.
>>> b := z.
>>> (here a and b pointing to same object - z)
>>>
>>> b := x.
>>>
>>> now, 'a' should still point to 'z', while 'b' should point to 'x'.
>>> but if you do z becomeForward: x , then both a and b will point to x.
>>
>> right. that's what I missed :)
>>
>
> But, if you add an indirection, that every object slots is a unique objects,
> then you can make an assignment as a message , implemented
> primitively, which replacing its contents, i.e.
> if 'a' is an instance variable of 'object', then
>
> a := b.  =>  object slotA setValue: b.
>
> a  => object slotA value

> E.g. this
>
> | a b |
> a := 42.
> b := a.
> ^ b
>
> is fully equivalent to
>
> | a b |
> a := 42.
> thisContext at: 2 put: (thisContext at: 1).
> ^ b

> On 18.03.2010, at 09:53, Igor Stasenko wrote:
>>
>> 2010/3/18 Stéphane Rollandin <[hidden email]>:
>>>> it won't go that way, because #becomeForward: replacing all references
>>>> to same object:
>>>>
>>>> a := z.
>>>> b := z.
>>>> (here a and b pointing to same object - z)
>>>>
>>>> b := x.
>>>>
>>>> now, 'a' should still point to 'z', while 'b' should point to 'x'.
>>>> but if you do z becomeForward: x , then both a and b will point to x.
>>>
>>> right. that's what I missed :)
>>>
>>
>> But, if you add an indirection, that every object slots is a unique objects,
>> then you can make an assignment as a message , implemented
>> primitively, which replacing its contents, i.e.
>> if 'a' is an instance variable of 'object', then
>>
>> a := b.  =>  object slotA setValue: b.
>>
>> a  => object slotA value
>
> Hehe. Now how do you implement setValue:? ;)
>

> Assignment simply is a meta-operation. If you have the expression
>
>        a := b
>
> then it is totally irrelevant what a points to currently. 'a' just designates where the object refered to by 'b' should be stored.
>
> Assignment is a message to the object that holds a reference, not to the referred object itself. Depending on the kind of variable it can be implemented by sending messages to the appropriate objects.
>
> E.g. this
>
>        | a b |
>        a := 42.
>        b := a.
>        ^ b
>
> is fully equivalent to
>
>        | a b |
>        a := 42.
>        thisContext at: 2 put: (thisContext at: 1).
>        ^ b
>
> because a and b are temps. In the case of instance variables, assignment is equivalent to #instVarAt:put:. In the case of global variables, it's #value:.
>
> In any case, assignment has *nothing* to do with become.
>

>
>> E.g. this
>>
>> | a b |
>> a := 42.
>> b := a.
>> ^ b
>>
>> is fully equivalent to
>>
>> | a b |
>> a := 42.
>> thisContext at: 2 put: (thisContext at: 1).
>> ^ b
>
> thanks for the clarification.
>
> can the
> | a b |
> part also be rewritten by sending messages to thisContext ?
>
> Stef