"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C8E3ABB.52289F45@deming-os.org...
> OddesE wrote:
>
> > I definitely agree with you that you normally compare by value
> > by default, however, what about assign? Now assigning one
> > reference to another *is* quitte common. More common in
> > fact than assigning by value (I think?). So now what?
> > Making compares act on values by default and assigns on
> > references is just sooo inconsistent, the thought alone makes
> > me shiver. Now here is my reasoning:
>
> Ouch.  Good point.
>
> I think, however, that we have already solved it (of sorts) with arrays:
>
>     a = b;    // assign by reference
>     a[] = b;    // assign by value
>
> Maybe we could use the dereferencing operator (  *  ) analagously:
>
>     Object a,b;
>     a = b;    // assign by reference
>     *a = b;    // assign by value
>
> Earlier, somebody (myself or somebody else, I forget who) suggested using
the
> array syntax for comparisons; the same could work for references:
>
>     int[] a,b;
>     Object c,d;
>     if(a == b)    // compare by reference
>     if(a[] == b)    // compare by value
>     if(c == d)    // compare by reference
>     if(*c == d)    // compare by value
>
> --
> The Villagers are Online! villagersonline.com
>
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
>
>

Ok, but at least make it symmetric!

if(*c == *d)    // compare by value, notice the second *

Otherwise it makes no sense, I want the value of both arguments.
But now we have a situation where we need to dereference
almost allways using any operator but assignment...
Introducing a second assignment operator is dubious to
say the least but it offers some huge advantages with operator
overloading, because now you can safely treat all operators
(except the special assign-by-reference operator =) as having
value semantics, which matches the way they are normally used
in math and on basic types in D.

Now two assignment ops is a lot, but assignment is a very
special case, in math but also in D, because in math it
doesn't exist  :)  and in D it assigns references, which is
probably unexpected behaviour for non programmers,
and even for some C/C++ programmers. Java and Delphi
programmers will feel right at home though... :)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

OddesE wrote:

> Ok, but at least make it symmetric!
>
> if(*c == *d)    // compare by value, notice the second *
>
> Otherwise it makes no sense, I want the value of both arguments.

Agreed, although Walter currently uses the "mark only one" idea for array setting.  IMHO, array setting should require both sides to include the [], but I suppose I could live without it.

> But now we have a situation where we need to dereference
> almost allways using any operator but assignment...
> Introducing a second assignment operator is dubious to
> say the least but it offers some huge advantages with operator
> overloading, because now you can safely treat all operators
> (except the special assign-by-reference operator =) as having
> value semantics, which matches the way they are normally used
> in math and on basic types in D.

I might go with this if you reverse the operators.  If we are going to say that the default paradigm is by value, then the existing operator = should be the same.  The new operator := should have the unusual syntax (assign by reference).

> Now two assignment ops is a lot, but assignment is a very
> special case, in math but also in D, because in math it
> doesn't exist  :)  and in D it assigns references, which is
> probably unexpected behaviour for non programmers,
> and even for some C/C++ programmers. Java and Delphi
> programmers will feel right at home though... :)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C8E609D.E569A7E6@deming-os.org...
> OddesE wrote:
>
> > Ok, but at least make it symmetric!
> >
> > if(*c == *d)    // compare by value, notice the second *
> >
> > Otherwise it makes no sense, I want the value of both arguments.
>
> Agreed, although Walter currently uses the "mark only one" idea for array setting.  IMHO, array setting should require both sides to include the [],
but
> I suppose I could live without it.
>

I agree that both sides should require []. However, an object matches an array less closely than a reference matches a pointer, so whatever the syntax for array slicing is, to me doesn't really matter. I think we should go for pointer semantics here, which means I want to dereference both of them.


> > But now we have a situation where we need to dereference
> > almost allways using any operator but assignment...
> > Introducing a second assignment operator is dubious to
> > say the least but it offers some huge advantages with operator
> > overloading, because now you can safely treat all operators
> > (except the special assign-by-reference operator =) as having
> > value semantics, which matches the way they are normally used
> > in math and on basic types in D.
>
> I might go with this if you reverse the operators.  If we are going to say
that
> the default paradigm is by value, then the existing operator = should be
the
> same.  The new operator := should have the unusual syntax (assign by
> reference).
>

To me it doesn't really matter. Object Pascal uses := to assign references,
Java uses =. Neither of the two is really unusual, they are just different.
From a practical standpoint it would probably be better to choose
= as assign-by-reference for two reasons:

1)  It is wat D uses now, so no existing code will be broken
2)  Since D is a successor to C++ it's syntax should match
     C++'s (and Java's) closely whenever possible.

Just my two eurocents  :)


> > Now two assignment ops is a lot, but assignment is a very
> > special case, in math but also in D, because in math it
> > doesn't exist  :)  and in D it assigns references, which is
> > probably unexpected behaviour for non programmers,
> > and even for some C/C++ programmers. Java and Delphi
> > programmers will feel right at home though... :)
>
> --
> The Villagers are Online! villagersonline.com
>
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
>
>


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
________________________________________________________
Please remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> ha scritto nel messaggio news:a6lcrf$q0q$1@digitaldaemon.com...
> "Immanuel Scholz" <digitals-mars@kutzsche.net> wrote in message news:a6l6sv$ncm$1@digitaldaemon.com...
> >
>[...]
> I see two solutions for this problem:
>
> A) Introduce syntax to make the distinction between reference
>      and value semantics.
> B) Introduce a new assign-by-value operator.
>
> Solution A is more flexible, but will lead to problems, because reference semantics *have* to be the default because reference assignment is used so much.

We can use : as an operator prefix meaning "by value". For example:

 a = b   // by reference
 a := b  // by value
if (a == b)  // by reference
if (a :== b) // by value
c := a :+ b;  // add by value
...

Ciao

OddesE wrote:
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:3C8E609D.E569A7E6@deming-os.org...
> 
>>OddesE wrote:
>>Agreed, although Walter currently uses the "mark only one" idea for array
>>setting.  IMHO, array setting should require both sides to include the [],
> 
> but
> 
>>I suppose I could live without it.
>>
> I agree that both sides should require []. 

The problem with including [] on both sides of a comparison is: what if one side is a string constant?  would you say: if (a[] == "hello"[]) ... ? doubtful that would fly.

You're gonna want to say: if (a[] == "hello") ... , where the right side is just a plain array (and I'd guess that reason is also why Walter has the "mark only one" idea for array setting?)

	Barry

Hmm, I think reference assignment is used so much NOW because of
things like the inability to return more than one variable from
a function, etc. Things which D fixes with "inout" and "out" in
function declarations. I agree that two different symbols are
needed to differentiate between assign by value vs. assign by
reference, and compare by value vs. compare by reference.
Primitive values use the = operator to represent assign by value,
it just seems "natural" to do things that way. Maybe we could just
throw in a & in current operations to indicate that the operator
is meant for dealing with the addresses of the objects.

i.e:

  a = b // by value (as it is for primitive types)
  a &= b // by reference (kinda like a = &b if a is a pointer, b isn't)
  if(a == b) // by value
  if(a &== b) // by reference

The statement "c := a :+ b" scares the hell out of me! I am by no means
an experienced programmer, and perhaps that shows by my avoidance of
having to deal with all those pointers, but nonetheless, I think
the ability to pass objects by reference to functions with no need for
an intermediate pointer will make the need for assigning by reference
obsolete. I realize this is a bold statement, but its just my humble
opinion. Its also a big departure from C/C++/Java style, but if the
purpose of D is to help fix the problems with C/C++/Java in the first
place, maybe a solution like this is needed.

My two cents...


>>
>>Solution A is more flexible, but will lead to problems, because
>>reference semantics *have* to be the default because reference
>>assignment is used so much.
>>
> 
> We can use : as an operator prefix meaning "by value". For example:
> 
>  a = b   // by reference
>  a := b  // by value
> if (a == b)  // by reference
> if (a :== b) // by value
> c := a :+ b;  // add by value
> ...
> 
> Ciao
> 
> 
> 

"Barry Pederson" <barryp@yahoo.com> wrote in message news:3C89924D.2020507@yahoo.com...
> Let me throw this out:  arrays have a length and a pointer.  We can access
the
> length with the .length property, how about adding a .pointer (or .ptr, or
> .addr) property to access the pointer to the array's data (that would the
> appropriate type for the array).   So for example, given "ubyte[] b",
> b.pointer would have the type: (ubyte *)
>
> Then if you wanted to do a comparison of the RAM addresses of two arrays,
you
> could say:
>
>      if (a.pointer == b.pointer)
>          ...
>
> Instead of the more verbose:
>
>      if ((ubyte *) a == (ubyte *) b)
>          ...
>
> There's also the advantage that if you ever changed the array types for a
or
> b, you wouldn't have to go through and change the casts in any pointer comparisons.

Comparing the pointers isn't sufficient, as two arrays aren't "equal" unless both the lengths and the pointers match. For conversions to a pointer, a cast to (void*) will have the properties you suggest, although I agree it is a little less appealing in appearance <g>.

Walter wrote:
> "Barry Pederson" <barryp@yahoo.com> wrote in message
> news:3C89924D.2020507@yahoo.com...
> 
>>Let me throw this out:  arrays have a length and a pointer.  We can access
> 
> the
> 
>>length with the .length property, how about adding a .pointer (or .ptr, or
>>.addr) property to access the pointer to the array's data (that would the
>>appropriate type for the array).   So for example, given "ubyte[] b",
>>b.pointer would have the type: (ubyte *)
>>
>>Then if you wanted to do a comparison of the RAM addresses of two arrays,
> 
> you
> 
>>could say:
>>
>>     if (a.pointer == b.pointer)
>>         ...
>>
>>Instead of the more verbose:
>>
>>     if ((ubyte *) a == (ubyte *) b)
>>         ...
>>
>>There's also the advantage that if you ever changed the array types for a
> 
> or
> 
>>b, you wouldn't have to go through and change the casts in any pointer
>>comparisons.
> 
> 
> Comparing the pointers isn't sufficient, as two arrays aren't "equal" unless
> both the lengths and the pointers match. For conversions to a pointer, a
> cast to (void*) will have the properties you suggest, although I agree it is
> a little less appealing in appearance <g>.

Agreed, but I wasn't claiming that pointer comparison would be a way to check if arrays were equal - it was just a suggestion for a way to implement the old C-style compare-by-address of two things: a and b, if it had been decided that  "a == b" was going to be compare-by-content.  The ".pointer" thing seemed nicely orthogonal to having the ".length" property.

But I think the later suggestion to use "a[] == b" to compare content is even better, since that seemed a good counterpoint to using "a[] = b" to copy content (and made the .pointer thing not quite so necessary)

I'm lukewarm to the proposal to use "===", I think it'd be awfully easy to slip-up and type "==", which would be perfectly valid to the compiler too.

On some screens or printouts or books, depending on the font, it might be hard to tell how many "="s are in there.   But given a choice between "===" and "string.cmp()", I'd take "===" I guess.

	Barry

"Barry Pederson" <barryp@yahoo.com> wrote in message news:3CA1433D.5050900@yahoo.com...

> But I think the later suggestion to use "a[] == b" to compare content is
even
> better, since that seemed a good counterpoint to using "a[] = b" to copy content (and made the .pointer thing not quite so necessary)

Since == is a binary operator, it is defined on arrays like this:

    c = (a[] == b);
    // is implemented as:
    for (int i = 0; i < a.length; i++)
        c[i] = (a[i] == b[i]);

That is, all elements are compared, and you get a bit array of results. I guess this is how it was supposed to work.

"Barry Pederson" <barryp@yahoo.com> wrote in message news:3CA1433D.5050900@yahoo.com...
> Agreed, but I wasn't claiming that pointer comparison would be a way to
check
> if arrays were equal - it was just a suggestion for a way to implement the
old
> C-style compare-by-address of two things: a and b, if it had been decided
that
>   "a == b" was going to be compare-by-content.  The ".pointer" thing
seemed
> nicely orthogonal to having the ".length" property.

Yes, it is nicely orthogonal.

> But I think the later suggestion to use "a[] == b" to compare content is
even
> better, since that seemed a good counterpoint to using "a[] = b" to copy content (and made the .pointer thing not quite so necessary)

That was my original plan, but it died a horrible death from ambiguities
with the array slicing
semantics.

> I'm lukewarm to the proposal to use "===", I think it'd be awfully easy to slip-up and type "==", which would be perfectly valid to the compiler too.

Yes, that is a weakness of that approach. I've seen === and !== used before (javascript), so it isn't a total invention of mine.

> On some screens or printouts or books, depending on the font, it might be
hard
> to tell how many "="s are in there.   But given a choice between "===" and "string.cmp()", I'd take "===" I guess.

I agree === is suboptimal, but I can't think of anything better.