the := operator (affectation

[Dennis Brown]

>> So in Transcript left assignment might be better stated using the  
>> familiar syntax:  set var to x
>> The get command becomes the shortcut equivelent of:  set it to
>>
>> So you see Jim, now I get it!
>>
> Or,,, get is a shortcut for "put the propX into it"... the set -  
> put difference still rears its head

If the get syntax is to be a shortcut for "put x into it", then "get  
x" is really "put x" with an implied "into it".  That would make  
"get" and "put" equivalent. which they are not.  Get implies  
receiving or taking, while put implies sending away.  That is why I  
can only think of the get command as a left assignment --I'm going to  
go over there and grab the value from the expression to my right.   
Makes it more like a function call, or a handler.  I guess some  
clever programming could create the get command if it did not already  
exist.

>> I have always been bothered by the left right reversal between  
>> setting parameters (just another type of container), and putting  
>> into variables.  I have mistyped setting the parameter many times  
>> using the form: put x into the parameter of y.  The syntax is not  
>> ambiguous as far as I can tell.  Perhaps both set and put syntaxes  
>> should be regularized to allow either, and relegate parameters to  
>> the ordinary family of containers.  At least allow the setting of  
>> variables even if putting into parameters is kept exclusive.
>>
>> Comments?
>>
> When phrased this way, the left - right assignment  question  
> becomes one, not of ":=", "=>", etc. but rather........  Why can't  
> I "set a variable to x?"  and why can't I "put something into a  
> property?" .. that's simple enough for even me to get ;-{)
>
> Off the top of my head there are significant differences between  
> variables and properties: persistence (properties stay there when  
> you shut down), scope (you can access any property from anywhere  
> whereas variables must be explicitly defined as global and then are  
> available only if the stack is running and has assigned them a  
> value) and messaging (objects can respond to a change in their  
> properties (setProp & getProp)). Is that enough to justify a syntax  
> change for addressing them.... Hmmmm?

Don't forget, you can also put things into fields.

> It may be that last item that is key.
> "Set" sends a message to an object.... the one with the property...  
> and that object can react to that message appropriately with  
> setProp/getProp
> "Put" doesn't send a message anywhere... well.. execpt for the fact  
> that the object responds to a "put the propX into var" anyway with  
> a "call" to getProp
> So why couldn't an object respond to a "put var into the propX"  
> with the setProp structure...  it could......
> So maybe it doesn't matter? Am I coming around to a different  
> perspective?
>
> Of course.. none of this has to anything to do with assignment  
> operators...

That's right, Transcript does not have any assignment "operators".   
It only has assignment commands.  Introducing an assignment  
"operator" is inconsistent.  There I said it.  That leaves us with  
the only reasonable option of a left assignment command.  Set and put  
are already defined in a a way that the compiler could translate them  
to the appropriate low level codes.  Messages would be sent when  
accessing properties, and not for variables.  If set must be the  
purview of properties only, then we would need a different word, but  
I can' t think of a good one off hand --nor a good reason to have one.

Dennis