November 02, 2005
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.
November 02, 2005
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.


November 02, 2005
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. 
> 
> 
November 02, 2005
> 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.


November 02, 2005
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


November 02, 2005
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.
November 02, 2005
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.
November 02, 2005
Don Clugston wrote:
> Maybe someone else has a different experience?

Actually i use , sometimes, it can be usefull,
example:

while(i=readInt(), i!=0)
{
}

November 02, 2005
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
November 02, 2005
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
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home