www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Assignment Expression Idea

reply Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Lastly I was writing a huge buck of Python code and then came
back to D and unintentionally used a nice syntax sugar (getting
a compile error), that's possible in a lot of cool languages,
among them Python and Lua (maybe one of the next D versions?).

Say you got a bunch of variables:

int a1, a2;
char b1, b2;
float d1, d2;
class T{...}; T t1, t2;

Then in Python you can perfectly write

a1, b1, c1, t1 = a2, b2, c2, t2;

but also such fancy stuff like swapping

a1, a2 = a2, a1;

and if the types are compatible or there have been conversion
operators been introduced

d1, t1 = a1, b1;
d2, t2 = a2, a2; // a2 get's assigned to both d2 and t2

I don't think that this would introduce ambiguties. The semantics
of the ','-operator could be changed, that the result is a tuple
and that tuples get read and assigned right to left (making
tuples a L value). If for example one writes 

a1, a2, d1 = b1, b2;

This would evaluate

d1 = b2;
a2 = b1;
a1 = nil;

Well, nil is not defined this way in D and thus I'd let raise
this a syntax error, but

a1, a2 = b1, b2, b3;

would be safe

a2 = b3;
a1 = b2;

No assignment of b1, which is consistent with the old syntax.
An implementation must take care, that in assignments like

a1, a2 = a2, a1;

temporary registers are used.

-- 
Wolfgang Draxinger
Jun 08 2006
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <e69bni$2jr$1 digitaldaemon.com>, Wolfgang Draxinger says...

Lastly I was writing a huge buck of Python code and then came
back to D and unintentionally used a nice syntax sugar (getting
a compile error), that's possible in a lot of cool languages,
among them Python and Lua (maybe one of the next D versions?).

Say you got a bunch of variables:

int a1, a2;
char b1, b2;
float d1, d2;
class T{...}; T t1, t2;

Then in Python you can perfectly write

a1, b1, c1, t1 = a2, b2, c2, t2;

but also such fancy stuff like swapping

a1, a2 = a2, a1;

and if the types are compatible or there have been conversion
operators been introduced

d1, t1 = a1, b1;
d2, t2 = a2, a2; // a2 get's assigned to both d2 and t2

I don't think that this would introduce ambiguties. The semantics
of the ','-operator could be changed, that the result is a tuple
and that tuples get read and assigned right to left (making
tuples a L value).


Changing the , operator to make tuples is a pretty big change. In particular it
would have to change precedence. In my Cx extensions I implemented multiple
return values using the syntax
[a,b,c] = foo();
where the brackets [] indicate the new behavior. The behavior of multiple return
functions is exactly like MATLAB (where is it very handy). If you're curious
about how it works in Cx surf around starting at
http://tinycx.sourceforge.net/multival.html, for example. If you do poke around
I'd appreciate any feedback you have.


 If for example one writes 

a1, a2, d1 = b1, b2;

This would evaluate

d1 = b2;
a2 = b1;
a1 = nil;

Well, nil is not defined this way in D and thus I'd let raise
this a syntax error, but

a1, a2 = b1, b2, b3;

would be safe

a2 = b3;
a1 = b2;


This is backwards from how MATLAB (and Cx) does it. The assignment goes left to
right. If you return more values that destinations then unused values are
discarded (much like you can discard the return value of a regular one-output
function).
In terms of D I would expect that it would end up getting a library tuple
support much like C++ has planned. But we'll see.


No assignment of b1, which is consistent with the old syntax.
An implementation must take care, that in assignments like

a1, a2 = a2, a1;

temporary registers are used.

-- 
Wolfgang Draxinger


-Ben
Jun 08 2006
parent Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Ben Hinkle wrote:
 

 Changing the , operator to make tuples is a pretty big change. In
 particular it would have to change precedence.


I understand what you mean and

i = a, j = b;

would be ambigous if the expression evaluated left to right.


 This is backwards from how MATLAB (and Cx) does it. The assignment goes
 left to right. If you return more values that destinations then unused
 values are discarded (much like you can discard the return value of a
 regular one-output function).


LTR is also how Lua and Python do it, but the RTL reading would have
retained the old semantics, and it would solve the ambiguty of above
example. In the current syntax, which is identical to C
<http://www.digitalmars.com/d/expression.html#Expression>

i = a, j = b

i would get assigned the value of the last statement in the comma operator,
which is j, which gets assigned b. With the RTL-tuple syntax this would
mean "assign the last element of the tupel (a, j) to i, which is j, and j
gets assigned by b. a wouldn't be affected at all".

This is, why I used RTL syntax: It keeps the old semantics and doesn't
introduce ambiguties and keeps the operator precedence.

OTOH LTR reading is much more common for tuple expressions. But I think
tuples should be introduced into D as a syntactic sugar. For example one
could use tuples to assign values to arrays (static and dynamic) and
intialize static arrays with them. This would naturally introduce []
brackets as a tuple designator if used as a L value. This brings me to
another idea: Using tuples as index values, i.e. if a tuple is used as an
index for array dereferencing the result is a tuple of the indexed array
elements (which could the again be used as array initializer).

int[] A;
int[5] B=A[[1, 5, 10, 3, 4]];

Or
A[[2, 7, 6, 8]] = [1, 2, 3, 4];

And another implication
[1, 2, 3, 4][0] == 1;
[1, 2, 3, 4][1] == 2;
.
.
.

The special case would be, if a tuple is used as an L value. In this case
the contents of the tuple must be L values, too, and the tuple implicitly
holds references.

Wolfgang Draxinger
Jun 09 2006