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