www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Better distinguishing reference and value in the syntax?

reply Gou Lingfeng <goughost yahoo.com.cn> writes:
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).
Jan 01 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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.
 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).

- Alex
Jan 02 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
 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.
Jan 02 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 03-01-2012 07:53, Gou Lingfeng wrote:
 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.

That's uglier than 'is'.
 On the other hand, if "is" is introduced, it should make some special
 sense than "==", like this:

Introduced? It's a feature in the language today.
 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 "==".

- Alex
Jan 03 2012
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 01/03/2012 12: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 has a consistant meaning everywhere: whether a and b refer to exactly the same memory location. And there's no redundency.

Sortof. There are shortcomings to thinking about it that way ;) Here's my take: 'is' is the /identity/ operator. It is true when the two operands hold the same thing, the same instance. '==' is the /equality/ operator. It is true when the two operands hold things which are equivalent. Here is an example: import std.stdio; void main() { string str1 = "foo"; string str2 = str1.idup; if ( str1 == str2 ) writeln("str1 == str2"); if ( str1 !is str2 ) writeln("str1 !is str2"); } It should print this: str1 == str2 str1 !is str2 In this case the strings are equal because they share the same contents, but they are not identical because they are different (instances of) strings.
Jan 02 2012
prev sibling next sibling parent Gou Lingfeng <goughost yahoo.com.cn> writes:
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.
Jan 02 2012
prev sibling parent Gou Lingfeng <goughost yahoo.com.cn> writes:
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 "==".
Jan 02 2012