www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dynamic array syntax proposal

reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Would it be possible to support this syntax:

int[][] a;
a.length = y, x;

It would be equivalent with the following piece of code:

int[][] a;
a.length = y;
foreach(inout int[] row; a) row.length = x;

I really don't understand why this comma-syntax is legal now that the 
latter parameters simply seem to vanish. Setting the array length should 
take only one parameter or as an alternative support this proposed syntax.
Nov 02 2005
next sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
The comma-syntax is legal because the comma in D behaves just like the 
'operator ,' in C/C++: all the expressions are executed and the (return) 
value is the value of the last expression. Silly example follows:

/* comma example */
import std.stdio;

int two() { writef("two"); return 2; }
/* two() is executed, but 3 is returned */
int three() { return two(),3; }

void main() { writef( three() ); }

Output:
two3

<OT>
I would love, however, a python-like tuple syntax, which would open the door 
to code similar to what you've written. Or maybe a generalization of the 
current property principle would be enough: a method set_length(int) can 
already be invoked with set_length = x. Add a 'method' length(int,int) to 
two dimensional arrays and change the meaning of the comma. This would allow 
array.length = x,y!

Combine this with another generalization, namely treating return values as 
implicit "out" parameters, so that get_length(out int, out int) could be 
used as x, y = get_length and the tuples are done ;-)
</OT>

L. 
Nov 02 2005
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Lionello Lunesu wrote:
 The comma-syntax is legal because the comma in D behaves just like the 
 'operator ,' in C/C++: all the expressions are executed and the (return) 
 value is the value of the last expression. Silly example follows:

IMHO, nearly all uses of the return value of the comma operator are silly. In fact, I'm sure that I have never seen a sensible example. The only good use for it that I have seen is by overloading the comma operator -- for emulating tuples! I'm really surprised that Walter included the comma operator in D. Probably, if was forbidden except in the last part of for() statements, nobody would notice it was gone. IE change syntax of for() to: for(declarations; boolexpression; expr[, expr [,expr ] ]) and forbid comma everywhere else, freeing it up for something more useful (like tuples). Maybe someone else has a different experience?
 
 /* comma example */
 import std.stdio;
 
 int two() { writef("two"); return 2; }
 /* two() is executed, but 3 is returned */
 int three() { return two(),3; }
 
 void main() { writef( three() ); }
 
 Output:
 two3
 
 <OT>
 I would love, however, a python-like tuple syntax, which would open the door 
 to code similar to what you've written. Or maybe a generalization of the 
 current property principle would be enough: a method set_length(int) can 
 already be invoked with set_length = x. Add a 'method' length(int,int) to 
 two dimensional arrays and change the meaning of the comma. This would allow 
 array.length = x,y!
 
 Combine this with another generalization, namely treating return values as 
 implicit "out" parameters, so that get_length(out int, out int) could be 
 used as x, y = get_length and the tuples are done ;-)
 </OT>
 
 L. 
 
 

Nov 02 2005
next sibling parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
 Maybe someone else has a different experience?

Nope, same here. The comma must be one of the reason obfuscated code contests work so well in C/C++... I see no other reason for it besides (unreadably) short code. We might have freed up a usable token just now! Instead of the usual "what token can we use instead of <X>"-discussions, we can discuss the opposite: "what can we do with , !" L.
Nov 02 2005
prev sibling next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Don Clugston wrote:
 Maybe someone else has a different experience?

Actually i use , sometimes, it can be usefull, example: while(i=readInt(), i!=0) { }
Nov 02 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 02 Nov 2005 17:53:02 +0100, Ivan Senji wrote:

 Don Clugston wrote:
 Maybe someone else has a different experience?

Actually i use , sometimes, it can be usefull, example: while(i=readInt(), i!=0) { }

Another way for doing this idiom is while( (i=readInt()) != 0) {} However, I always thought that the comma operator was the used to guarantee the order of execution of a set of statements. Statements in a block may be reordered by the compiler so long as the effect is the same but a comma-separated list of statements is never reordered. Is this true or was I dreaming? -- Derek Parnell Melbourne, Australia 3/11/2005 6:52:35 AM
Nov 02 2005
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Derek Parnell wrote:
 On Wed, 02 Nov 2005 17:53:02 +0100, Ivan Senji wrote:
 
 
Don Clugston wrote:

Maybe someone else has a different experience?

Actually i use , sometimes, it can be usefull, example: while(i=readInt(), i!=0) { }

Another way for doing this idiom is while( (i=readInt()) != 0) {} However, I always thought that the comma operator was the used to guarantee the order of execution of a set of statements. Statements in a block may be reordered by the compiler so long as the effect is the same but a comma-separated list of statements is never reordered. Is this true or was I dreaming?

Really? I have never heard of it. And if it was a dream then it was a really strange dream :)
Nov 02 2005
prev sibling next sibling parent BCS <BCS_member pathlink.com> writes:
In article <dkan0c$2vgm$1 digitaldaemon.com>, Don Clugston says...

IE change syntax of for() to:
for(declarations; boolexpression; expr[, expr [,expr ] ])

Maybe someone else has a different experience?

how about: for(decls [, decls [, decls ] ]; boolexpression; expr[, expr[, expr ] ])
Nov 02 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Don Clugston wrote:
 Lionello Lunesu wrote:
 
 The comma-syntax is legal because the comma in D behaves just like
 the 'operator ,' in C/C++: all the expressions are executed and the
 (return) value is the value of the last expression. Silly example
 follows:

IMHO, nearly all uses of the return value of the comma operator are silly. In fact, I'm sure that I have never seen a sensible example. The only good use for it that I have seen is by overloading the comma operator -- for emulating tuples! I'm really surprised that Walter included the comma operator in D. Probably, if was forbidden except in the last part of for() statements, nobody would notice it was gone. IE change syntax of for() to: for(declarations; boolexpression; expr[, expr [,expr ] ]) and forbid comma everywhere else, freeing it up for something more useful (like tuples). Maybe someone else has a different experience?

I think this sounds both reasonable and potentially quite useful.
 Or maybe a generalization of the current property principle would
 be enough: a method set_length(int) can already be invoked with
 set_length = x. Add a 'method' length(int,int) to two dimensional
 arrays and change the meaning of the comma. This would allow
 array.length = x,y!
 
 Combine this with another generalization, namely treating return 
 values as implicit "out" parameters, so that get_length(out int,
 out int) could be used as x, y = get_length and the tuples are done


Hmm. Possibly this would not bee so hard to implement. And it would give some more flexibility to usage, exatly the same way as set_length(int) can now be used as set_length = x. However, this kind of syntactic sugar tends to do its utmost to create hurdles for those just learning the language. Which would be a step in C direction. So we need proper use cases before any decision can be made.
Nov 02 2005
prev sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Lionello Lunesu wrote:
 The comma-syntax is legal because the comma in D behaves just like the 
 'operator ,' in C/C++: all the expressions are executed and the (return) 
 value is the value of the last expression. Silly example follows:
 
 /* comma example */
 import std.stdio;
 
 int two() { writef("two"); return 2; }
 /* two() is executed, but 3 is returned */
 int three() { return two(),3; }
 
 void main() { writef( three() ); }
 
 Output:
 two3

Ok, it works - for some reason I've never though of this possibility with expressions before :) Still I don't find it that useful. These two lines are equivalent: int three() { return two(),3; } int three() { two(); return 3; } One another example: int b = (a.length = 1, two(), 3); a.length = 1; two(); int b = 3; But it's nice to have multiple expressions in for/while-loops: for(a=0; a<10; a++, i--) { ... } I think Walter has put this comma-syntax on too high a level in the grammar. Now it's not possible to initialize multiple array levels conveniently.
 
 <OT>
 I would love, however, a python-like tuple syntax, which would open the door 
 to code similar to what you've written. Or maybe a generalization of the 
 current property principle would be enough: a method set_length(int) can 
 already be invoked with set_length = x. Add a 'method' length(int,int) to 
 two dimensional arrays and change the meaning of the comma. This would allow 
 array.length = x,y!

IMO it should be set_length(int[]). It's always boring to initialize the arrays with multiple for/foreach-statements.
 
 Combine this with another generalization, namely treating return values as 
 implicit "out" parameters, so that get_length(out int, out int) could be 
 used as x, y = get_length and the tuples are done ;-)
 </OT>

This sounds very practical. You could also use default return values easily with such a syntax.
Nov 02 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 02 Nov 2005 18:44:49 +0200, Jari-Matti Mäkelä wrote:


[snip]
 
 But it's nice to have multiple expressions in for/while-loops:
 
    for(a=0; a<10; a++, i--) { ... }
 

In effect the syntax for 'for' is for ( <block>; <booleanexpr> ; <block>) <block> so could have ... for( {a=0; i=10;}; a<10; {a++; i--;}) { ... } to eliminate commas in the complex cases and leave the simple case as it now is. -- Derek Parnell Melbourne, Australia 3/11/2005 6:48:55 AM
Nov 02 2005
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Derek Parnell wrote:
 In effect the syntax for 'for' is 
 
     for ( <block>; <booleanexpr> ; <block>) <block>
 
 so could have ...
 
    for( {a=0; i=10;}; a<10; {a++; i--;}) { ... }
 
 to eliminate commas in the complex cases and leave the simple case as it
 now is.
 

Sorry, I'm not sure what you're aiming at. Actually I meant that we should abandon the following syntax: http://www.digitalmars.com/d/expression.html#Expression Expression: AssignExpression | AssignExpression, Expression and start supporting the following (this version is by Don Clugston): http://www.digitalmars.com/d/statement.html#for ForStatement: for(declarations;boolexpression;expr[, expr [,expr ] ]) or something similar. The idea behind this was that once we get rid of comma as a high level grammar rule, we can fill the gap with new, convenient functionality. However, I think it looks pretty ugly to use block brackets inside the for(...)-statement. So D could support commas inside for-loops (and maybe while-loops too) as a special case. Like I previously wrote, supporting the comma-syntax everywhere makes it all too easy to write really obfuscated code (especially inside conditional (: ?) expressions.
Nov 02 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 02 Nov 2005 23:19:07 +0200, Jari-Matti Mäkelä wrote:

 Derek Parnell wrote:
 In effect the syntax for 'for' is 
 
     for ( <block>; <booleanexpr> ; <block>) <block>
 
 so could have ...
 
    for( {a=0; i=10;}; a<10; {a++; i--;}) { ... }
 
 to eliminate commas in the complex cases and leave the simple case as it
 now is.
 

Sorry, I'm not sure what you're aiming at. Actually I meant that we should abandon the following syntax: http://www.digitalmars.com/d/expression.html#Expression Expression: AssignExpression | AssignExpression, Expression and start supporting the following (this version is by Don Clugston): http://www.digitalmars.com/d/statement.html#for ForStatement: for(declarations;boolexpression;expr[, expr [,expr ] ]) or something similar. The idea behind this was that once we get rid of comma as a high level grammar rule, we can fill the gap with new, convenient functionality. However, I think it looks pretty ugly to use block brackets inside the for(...)-statement. So D could support commas inside for-loops (and maybe while-loops too) as a special case. Like I previously wrote, supporting the comma-syntax everywhere makes it all too easy to write really obfuscated code (especially inside conditional (: ?) expressions.

I wasn't "aiming" for anything really. It was just yet another suggestion for removing the comma operand from D so that we didn't need special cases for it. I don't find {} ugly inside 'for' statements, especially as it would be rarely used. If people are really concerned about the comma operand then this is one (of many possible) ways to remove it from D. Personally, I'm not bothered by the comma at all. If someone wants to use for tuple element specification then why not treat that as a special case, or even use a different delimiter for tuple elements. -- Derek (skype: derek.j.parnell) Melbourne, Australia 3/11/2005 9:37:10 AM
Nov 02 2005
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Derek Parnell wrote:
 I wasn't "aiming" for anything really. It was just yet another suggestion
 for removing the comma operand from D so that we didn't need special cases
 for it. I don't find {} ugly inside 'for' statements, especially as it
 would be rarely used. 
 
 If people are really concerned about the comma operand then this is one (of
 many possible) ways to remove it from D. Personally, I'm not bothered by
 the comma at all. If someone wants to use for tuple element specification
 then why not treat that as a special case, or even use a different
 delimiter for tuple elements. 
 

Ok, I see your point now. :) I really don't know if the comma-syntax would be a good way to handle n-dimension arrays. I hope Walter has a better vision on this. I still hope he doesn't run out of delimiters, if some other syntax looks better (I think the # and $ are already reserved for other purposes) ;)
Nov 02 2005
prev sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:e3dbkps2rk2b.6r0ugtlyce9l.dlg 40tude.net...
 On Wed, 02 Nov 2005 18:44:49 +0200, Jari-Matti Mäkelä wrote:


 [snip]
 But it's nice to have multiple expressions in for/while-loops:

    for(a=0; a<10; a++, i--) { ... }

In effect the syntax for 'for' is for ( <block>; <booleanexpr> ; <block>) <block> so could have ... for( {a=0; i=10;}; a<10; {a++; i--;}) { ... } to eliminate commas in the complex cases and leave the simple case as it now is.

//or: a=0; i=10; while (a<10) { ... a++; i--; } If one really wanted to use a comma in a for-statement, there's always 'while' as an alternative. No need for "{}" inside the for. L.
Nov 02 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 3 Nov 2005 09:39:32 +0200, Lionello Lunesu wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:e3dbkps2rk2b.6r0ugtlyce9l.dlg 40tude.net...
 On Wed, 02 Nov 2005 18:44:49 +0200, Jari-Matti Mäkelä wrote:


 [snip]
 But it's nice to have multiple expressions in for/while-loops:

    for(a=0; a<10; a++, i--) { ... }

In effect the syntax for 'for' is for ( <block>; <booleanexpr> ; <block>) <block> so could have ... for( {a=0; i=10;}; a<10; {a++; i--;}) { ... } to eliminate commas in the complex cases and leave the simple case as it now is.

//or: a=0; i=10; while (a<10) { ... a++; i--; } If one really wanted to use a comma in a for-statement, there's always 'while' as an alternative. No need for "{}" inside the for.

This is true. And to retain the scoping aspects of the 'for'... { // Begin a new scope block int a=0; int i=10; while (a<10) { ... a++; i--; } } But this starts to lose the simplicity of the 'for'. -- Derek (skype: derek.j.parnell) Melbourne, Australia 3/11/2005 6:50:13 PM
Nov 02 2005
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
In article <1moow0ntydg9i$.1r99qh45tgq2m$.dlg 40tude.net>, Derek Parnell says...
On Thu, 3 Nov 2005 09:39:32 +0200, Lionello Lunesu wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:e3dbkps2rk2b.6r0ugtlyce9l.dlg 40tude.net...
 On Wed, 02 Nov 2005 18:44:49 +0200, Jari-Matti Mäkelä wrote:


 [snip]

for ( <block>; <booleanexpr> ; <block>) <block> so could have ... for( {a=0; i=10;}; a<10; {a++; i--;}) { ... } to eliminate commas in the complex cases and leave the simple case as it now is.



The problem with the first block is when you want to declare variables: {int a = 0; int i = 10}... (They go out of scope)
 If one really wanted to use a comma in a for-statement, there's always 
 'while' as an alternative. No need for "{}" inside the for.

This is true. And to retain the scoping aspects of the 'for'... { // Begin a new scope block int a=0; int i=10; while (a<10) { ... a++; i--; } } But this starts to lose the simplicity of the 'for'.

And the 'while' alternative also loses the 'continue' semantics. So use goto cont; instead of continue: # { // Begin a new scope block # int a=0; # int i=10; # while (a<10) # { # ... # cont: // continue label # a++; i--; # } # } Neat? :) Of course, the comma operator helps: :) # { # int a = -1; # int i = 11; # while(a++,i--,a<10) # { # ... # } # } /Oskar
Nov 03 2005
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Oskar Linde wrote:
But this starts to lose the simplicity of the 'for'.

And the 'while' alternative also loses the 'continue' semantics. So use goto cont; instead of continue: # { // Begin a new scope block # int a=0; # int i=10; # while (a<10) # { # ... # cont: // continue label # a++; i--; # } # } Neat? :) Of course, the comma operator helps: :) # { # int a = -1; # int i = 11; # while(a++,i--,a<10) # { # ... # } # }

Now come on guys, this was a serious proposal. I'm pretty sure nobody wants to use gotos anymore. And yes, we should have comma-syntax inside the for-statement, it's extremely easy to implement now that we already have the same syntax on another hierarchy level. I hope Walter has time to comment this issue.
Nov 03 2005
prev sibling next sibling parent reply Oskar Linde <Oskar_member pathlink.com> writes:
In article <dka86i$2h6k$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
Would it be possible to support this syntax:

int[][] a;
a.length = y, x;

[snip]
I really don't understand why this comma-syntax is legal now that the 
latter parameters simply seem to vanish. Setting the array length should 
take only one parameter or as an alternative support this proposed syntax.

I know this has been suggested before, but I say it again: :) I would like the comma operator to become depreciated. This could would open the door to future syntax enhancehments (tuples maybe). As I see it, the comma operator: a) Can be confusing when unexpected. b) Is very seldomly used in C/C++/D (except in for-loops) c) Has parsing problems: needs parenthesis when used in parameter lists, array literals, etc... d) Is a functional programming artifact that is malplaced in C and descendants. Comment about b): The only regular place I have seen the usage of the comma operator outside for-loops is where a {}-block would have done equally well, like: if (a) b++,c++; I have actually never seen code that used the comma operator as an expression. (Or maybe I have but can't remember.) (this reinforces a) ) The for-loop is a strange beast... I guess that with foreach, for-loops are less common in D than in C. Many for-loops could be replaced by something python like: foreach(int i; range(10)) But this does not help in those cases where you wanted a comma operator in the first place... The best option is probably to give commas in for-loops special treatment. /Oskar
Nov 02 2005
next sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Oskar Linde wrote:
 In article <dka86i$2h6k$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
 
Would it be possible to support this syntax:

int[][] a;
a.length = y, x;

[snip]
I really don't understand why this comma-syntax is legal now that the 
latter parameters simply seem to vanish. Setting the array length should 
take only one parameter or as an alternative support this proposed syntax.

I know this has been suggested before, but I say it again: :) I would like the comma operator to become depreciated. This could would open the door to future syntax enhancehments (tuples maybe). As I see it, the comma operator: a) Can be confusing when unexpected. b) Is very seldomly used in C/C++/D (except in for-loops) c) Has parsing problems: needs parenthesis when used in parameter lists, array literals, etc... d) Is a functional programming artifact that is malplaced in C and descendants. Comment about b): The only regular place I have seen the usage of the comma operator outside for-loops is where a {}-block would have done equally well, like: if (a) b++,c++; I have actually never seen code that used the comma operator as an expression. (Or maybe I have but can't remember.) (this reinforces a) ) The for-loop is a strange beast... I guess that with foreach, for-loops are less common in D than in C. Many for-loops could be replaced by something python like: foreach(int i; range(10)) But this does not help in those cases where you wanted a comma operator in the first place... The best option is probably to give commas in for-loops special treatment. /Oskar

Nov 02 2005
prev sibling parent BCS <BCS_member pathlink.com> writes:
Comment about b):
The only regular place I have seen the usage of the comma operator outside
for-loops is where a {}-block would have done equally well, like:

if (a) b++,c++;

I have actually never seen code that used the comma operator as an expression.
(Or maybe I have but can't remember.) (this reinforces a) )

void fn1(); void fn2(); void fn3(); void fn4(); bool A, B, C, D; // set A .. D //this ugly thing if(A && fn1(), B && fn2(), C && fn3(), D) fn4; // is the same as this just as ugly but longer thing if(A) { fn1(); if(B) { fn2(); if(C) { fn3(); if(D) fn4; } } }
Nov 02 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Using comma for tupple/array literal operator may bring some problems 
not just with "for" comma-sequence expressions, but also with function 
call argument lists. Hum... then again maybe not, as it didn't with 
comma-sequence expressions.

Anyway, here's an alternative ideia for tupple/array construction, which 
uses the '~' concatenation operator for that purpose:

   auto arr =  1 ~ 2 ~ 3;   // arr type is int[3]
   (1 ~ 4 ~ 9)[2];          // value: 9

One could also use it for slices instead of the slice operator:

   "Whatever"[4~8];         // value: "ever"
   slice = 4~7;             // slices are now first class entities.
   str[slice];              // value: "eve"

I'm not sugesting this syntax, just presenting it, as it has some 
disadvantages besides it's advantages.

Advantages:
* Short syntax allow to replace the slice operator [ .. ]
* Makes some conceptual sense because '~' is already used as a 
concatenation operator

Disadvantages:
* Cannot construct literals of arrays of arrays, just arrays of 
primitives/references.
* Doesn't visually look as clean/meaningful as the ',' comma operator.


One could have a similar syntax with the ',' token, changing some of the 
advantages and disadvantages. One would unfortunately maintain the first 
disadvantage, which is why I think something better should tried to be 
found.
Has this issue been discussed in the past, with any reasonable ideias 
brought up?

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Nov 03 2005
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
I' m going to join this tuple discussion too: Has anyone seen the syntax 
for anonymous structs in comega language? It goes something like this

struct{int,float} getTuple(){return new {1,2.5};}

...

struct{int,float} x = getTuple();

intPart = x[0];
floaPart = x[1];
Nov 03 2005