Re: Better distinguishing reference and value in the syntax?

2012-01-02 Thread Gou Lingfeng
On Mon, 2012-01-02 at 13:18 +0100, Alex Rønne Petersen wrote:
 On 02-01-2012 06:25, Gou Lingfeng wrote:
  D's definitions of is and == have so much redundency. That might
  indicate some flaw. If references and values (for classes and arrays)
  could be clearly distinguished in the syntax, the is operator is not
  necessary at all.
 
 Of course it is. 'is' is strictly identity, while == would call an 
 overloaded opEquals, if any exists. This difference in semantics is 
 *very* important when you do *not* want to call opEquals.

My impression is that, in D, references are wrapped (protected)
pointers, and there are values behind. Although opEquals can be defined
anyway, it's usually some function depending on the values, not
pointers. If we could clearly show whether we wan't pointer comparison
or value comparison, then a is b would be pointer(a)==pointer(b),
and a==b value(a)==value(b).

Or is sould evaluate false for int is int, and true or false for
expressions like int is (ref int) and (ref int) is (ref int). So it
has a consistant meaning everywhere: whether a and b refer to exactly
the same memory location. And there's no redundency.




Re: Better distinguishing reference and value in the syntax?

2012-01-02 Thread Gou Lingfeng
On Tue, 2012-01-03 at 06:43 +0100, Timon Gehr wrote:
 On 01/03/2012 06:10 AM, Gou Lingfeng wrote:
  On Mon, 2012-01-02 at 13:18 +0100, Alex Rønne Petersen wrote:
  On 02-01-2012 06:25, Gou Lingfeng wrote:
  D's definitions of is and == have so much redundency. That might
  indicate some flaw. If references and values (for classes and arrays)
  could be clearly distinguished in the syntax, the is operator is not
  necessary at all.
 
  Of course it is. 'is' is strictly identity, while == would call an
  overloaded opEquals, if any exists. This difference in semantics is
  *very* important when you do *not* want to call opEquals.
 
  My impression is that, in D, references are wrapped (protected)
  pointers, and there are values behind. Although opEquals can be defined
  anyway, it's usually some function depending on the values, not
  pointers. If we could clearly show whether we wan't pointer comparison
  or value comparison, then a is b would be pointer(a)==pointer(b),
  and a==b value(a)==value(b).
 
  Or is sould evaluate false for int is int, and true or false for
  expressions like int is (ref int) and (ref int) is (ref int). So it
 
 ref is not a type modifier, it is a storage class, therefore, to compare 
 to ref int values a,b for identity, use a is b.

Or, a == b. If similar notations could apply to other types (arrays
and classes), binary is is not needed at all.

On the other hand, if is is introduced, it should make some special
sense than ==, like this:

import std.stdio;
int a=1,b=1;
void fun(ref int c,ref int d,ref int e){
  writeln('c is d' evaluates ,c is d,, should be true.);
  writeln('c is e' evaluates ,c is e,, should be false.);
  writeln('c is a' evaluates ,c is a,, should be true.);
  writeln('c is b' evaluates ,c is b,, should be false.);
}
void main() {
  writeln('a is b' evaluates ,a is b,, should be false.);
  fun(a,a,b);
}

  has a consistant meaning everywhere: whether a and b refer to exactly
  the same memory location. And there's no redundency.
 
 
 
 There will always be some redundancy, because a is b implies a == b.

Implication is not redundant, but equivalence is. And the current
definition of is for integers is equivalent to ==.



Better distinguishing reference and value in the syntax?

2012-01-01 Thread Gou Lingfeng
D's definitions of is and == have so much redundency. That might
indicate some flaw. If references and values (for classes and arrays)
could be clearly distinguished in the syntax, the is operator is not
necessary at all.

A related thing is element-wise operation. Consider
string[] a;
string[] b;
string[] c;
...
c[1..3]=a[1..3]~b[1..3];

and,

int[] a;
int[] b;
int[] c;
...
c[1..3]=a[1..3]+b[1..3];

The two pieces are very much similar, and I expect similar results. But
D doesn't provide element-wise concatenation, because it's not clear in
the syntax whether a[1..3] is a reference (for simple array
concatenation) or a value (for element-wise concatenation).