the := operator (affectation

Dennis Brown see3d at writeme.com
Fri Jun 24 10:23:05 EDT 2005


Jim,

On Jun 23, 2005, at 10:40 PM, Jim MacConnell wrote:

> Dennis,
>
> First.. thank you for your intelligent reply to my:
>
>>> okay.. back into my hole...
>>>
>> Yes, Please stay there.
>>
> It is good to so easily learn so much of the people we correspond  
> with. I'm not surprised that I touched a nerve but I am surprised  
> at the scream ... sorry ;-{ )

My apologies, I was a bit over the top yesterday in my reply.  Yes, I  
want to make intelligent discussion not hyperbole.  We all have our  
bad days.  I felt like I was being ambushed, and that you were going  
to retreat out of the conversation.

> Second..
>
>> var := x
>> var == x
>> var = x  --this is a bit tougher
>> var isAssignedToTheValueOf x
>> var gets x
>>
>> are all the same thing!
>>
> Well.. they are close.  They all may have the same result at a  
> machine code level... (although I believe var == x resolves to TRUE  
> if var and x are the same (false otherwise).. and usually the same  
> for (var = x) if it is parentheses? )

Oops, but at least you knew what I meant .  APL left arrow was  
supposed to go into that spot.

> but the discussion is not about values of variables or what the  
> machine does... or at least my contribution wasn't. It seemed to  
> me, the discussion was about consistency in a language and the  
> inclusion of semantically different operators in addition to those  
> that are inherently  ones. Seems like you didn't understand rather  
> than me.

I did understand you, and I can accept that a var gets x is not xTalk  
as long as var := x is also not xTalk.  That was my point.  The gets  
"term" was my suggestion as being more xTalk than := and could be  
related semantically to the get command which is also left assignment.

> Third...
>
>> You say one is a good construct and another is an inconsistent  
>> construct!  That makes your argument inconsistent.
>>
> Maybe reread my post? I don't see in my message where I said any of  
> those was a good construct for an xTalk. I said "put x into var"  
> was a good construct for an xTalk language because it is consistent  
> with the concept of telling the object what "It" should do as  
> opposed to a variable being assigned something...  It may seem a  
> trivial point but it is at the root of the discussion...

" I personally have nothing against ":=" and "=" for variable  
assignment" --I took to be your acceptance as good.

> Or perhaps the point is that if all of the above are the same but  
> are non-xTalk friendly conceptually, is it appropriate for us to  
> worry about whether Transcript includes any of them.... Of course  
> you left the "put x into var" out of the list even though I would  
> assume that from your point of view it is also the same thing....  
> So why did you leave it off?  it appears to be the only one that is  
> 100% consistent with the xTalk construct..... Could it be you agree  
> with me at some level?

Put x into var is a right assignment command.  Not the same thing.   
The whole thread is about a left assignment operator and the desire  
to conceptually have a left assignment as an extension of the  
language.  And, yes, I do agree with you at some level, just not the  
way you argued for your point.  I tend to take an argument to the  
extreme opposite position in order to discover the core issue.  It  
makes everyone (including myself) think more clearly.  I also test my  
code with values of "-infinity", -1,0,1,"+infinity",empty.  I find  
the flaws faster with the edge conditions.

> Finally...
>
>> You just don't get it ;-)
>> I can't say I can get it into your head, though I can put it into  
>> your head.
>> Perhaps Jim gets it now.
> ... telling someone their argument is inconsistent or that they  
> don't get it when it appears you maybe didn't  actually listen to/ 
> read what they were saying does little to build your credibility.  
> Following the same with a condescending cute smiley does not help.  
> This list is a great place for constructive discussion and it  
> should stay that way. Keep your personal comments to yourself.. and  
> I'll be lighter on the " ...some renegade variable is off filling  
> itself with data..." comments.

I guess I was a bit too obscure.  The ;-) was the clue that the  
statements were an example of get, put, gets syntax and a  
lighthearted jab not meant to be taken too literally:

You just don't "get it", because "get it" is a no op.
I can't say I can "get it into" your head, because "get...into" is  
bad syntax mixing left and right assignment, showing the difference  
between get and put.
Perhaps Jim gets it now... new syntax of left assignment that is  
English like syntax.

However, from the various replies to my gets suggestion, I don't  
think gets is the best choice for a left assignment for Transcript  
because of the lack of imperative.  In BASIC the LET was the  
imperative  to LET var=x.  The LET was redundant from a parsing point  
of view, so eventually fell away.  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!

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?

Dennis


More information about the use-livecode mailing list