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,

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]


 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.






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:












Neat? :)

Of course, the comma operator helps: :)










/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:
 










 
 Neat? :)
 
 Of course, the comma operator helps: :)
 










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
 
 


Exactly! I hope Walter agrees.



 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