"Dario" <supdar@yahoo.com> wrote in message news:b8rf9e$2mmn$1@digitaldaemon.com...
> > Walter wrote:
> > > I've been thinking about this. I think you're probably right -
.reverse
> and
> > > .sort should return copies.
>
> > Burton Radons wrote:
> > Please no!  If one wants a copy, use .dup.sort.  If .sort copied, it
> > would be a time and memory hemmhorrhage that I would have no control
> > over.  I would have to write my own sort just to avoid this.
>
> It wouldn't necessary happen if the compiler optimized a statement like:
>     a[] = a.sort;
>
> That would literally mean (if sort made copies):
> 1) a new array is allocated;
> 2) the content of 'a' is copied in sorted;
> 3) the content of the sorted array is copied in 'a';
> 4) (the copy of 'a' is lost and becomes garbage);
>
> But the compiler should be able to optimize it so that the
> unnecessary allocation won't be done. This can be done, can't it?
> "a[] = a.sort" is now "a.sort" and "a = a.sort" is now
> "a = a.dup.sort".

It couldn't do that optimization, because a could point inside another array.

Which is why slices and arrays should be different beasts.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:b8u68i$28o8$1@digitaldaemon.com...
>
> "Dario" <supdar@yahoo.com> wrote in message news:b8rf9e$2mmn$1@digitaldaemon.com...
> > > Walter wrote:
> > > > I've been thinking about this. I think you're probably right -
> .reverse
> > and
> > > > .sort should return copies.
> >
> > > Burton Radons wrote:
> > > Please no!  If one wants a copy, use .dup.sort.  If .sort copied, it
> > > would be a time and memory hemmhorrhage that I would have no control
> > > over.  I would have to write my own sort just to avoid this.
> >
> > It wouldn't necessary happen if the compiler optimized a statement like:
> >     a[] = a.sort;
> >
> > That would literally mean (if sort made copies):
> > 1) a new array is allocated;
> > 2) the content of 'a' is copied in sorted;
> > 3) the content of the sorted array is copied in 'a';
> > 4) (the copy of 'a' is lost and becomes garbage);
> >
> > But the compiler should be able to optimize it so that the
> > unnecessary allocation won't be done. This can be done, can't it?
> > "a[] = a.sort" is now "a.sort" and "a = a.sort" is now
> > "a = a.dup.sort".
>
> It couldn't do that optimization, because a could point inside another array.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b8u7ht$29tg$1@digitaldaemon.com...
> Which is why slices and arrays should be different beasts.

It's not just slices, two handles can refer to the same array.

And the problem with sorting them then is...?  Maybe that's what the user wants.  Maybe he wants a copy instead.  (S)he needs to specify.

The problem is that sometimes you want to treat normally reference types as values, and sometimes you want to treat values as references.  We have to use two different sets of syntaxes and thus the type system is not unified. We can't really just say what we want, we have to remember what *type* the thing is and say it differently.  This impedes generic programming.

This sort issue, the in/out/inout issue, most of this is symptoms of kludges around this basic fact.  Trying to "make it easier" on people by introducing two separate programming models with the same syntax.

I wish there was no semantic difference between an class and a struct, or in fact between a class and a basic type such as int.  I should be able to program them all the same way, with method calls and operators.  And if I want a copy I should be able to say "make a copy" and if I want a reference I should be able to say "make a reference to x", of course with much terser syntax, but one that is explicit.  But it should be obvious what it is that I'm doing;  hiding references is a bad idea. I want the references to stick out to the naked eye, like & and * do in C.  I'd rather do something like this though:

int& g = 10; // reference to int

void inc(int& i)  // we're reinventing ++ today  ;)
{
    i = i + 1; // dereferencing is automatic
}

{
    int foo;  // init to zero, since we don't specify anything else
    inc(&foo);  // require making explicit reference to foo
    inc(foo);  // or don't, I'm not that picky, but the & helps to be clear
about what's going on.
    print(foo); // please?  how hard should this be?  prints 2
    int& dog = foo;
    inc(dog);  // passing a reference in is no problem, no need for &, which
would be redundant, unnecessary,
    print(dog); // prints 3
    dog = g;  // store a 10 into foo thru dog reference
    dog = &g;  // this is still only assigning a 10 into foo, because
references are automatically dereferenced if necessary during implicit
conversion.
    // they could be automatically created if necessary too, but this may
not be desirable.  I kinda like references being transparent though.
    &dog = &g; // assign reference to g to reference named dog
    inc(&dog);  // would form a reference to reference to int which
automatically implicitly casts to reference to int
    print(dog); // prints 11
    print(foo); // prints 10
}

But I bet that D is no longer malleable enough to make such a large change.

The compiler is always of course free to optimize away any physical reference if it can tell it is not needed.  The semantics have to be honored, though.  It must give the correct results.

How to deal with references to references to references (double/triple indirection in C with pointers)?  This would require some kind of way to explicitly dereference, so you can get to the desired level.  Or you could force the programmer to declare an intermediate reference of the right level or require an explicit cast.  Extra references should still be automatically dereferenced.

i.e.

int aa = 1, bb = 2;
int& a = &aa, b = &bb;
int&& selector = which ? &a : &b;
int& result = selector;
print(result);

I doubt a few &'s would clutter up your OO code that much.  And we could use the same &'s for dealing with arrays by reference, or, occasionally, ints. If you think that'll add too many &'s, invert the whole thing the other way and do everything by reference *unless* the user explicitly requests a copy. You could indicate a value type using #, and dereference a reference (promote to actual value, or "copy" it) by using the unary # operator.  We could have #= for by-value assignment (explicit copy) and #== for value comparison.

One problem with using = for assignment and == for comparison is then how you do make reference assignment and reference comparison?  D has gone the way of === for reference comparison and no explicit reference assignment. That leaves reference in the data realm, not operator realm.  I'd prefer to state intent at time of assignment or comparison, in an unambiguous way, using := for reference assignment and :== for reference comparison.

Am I crazy?  Things don't have to be this complicated.

Then maybe we can do fun things like build our own reference types and overload referencing/dereferencing.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:b8uigr$2lb4$1@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b8u7ht$29tg$1@digitaldaemon.com...
> > Which is why slices and arrays should be different beasts.
>
> It's not just slices, two handles can refer to the same array.

You're right, this does boil down to the difference between reference and value types. They do have fundamentally different semantics, while frequently using the same syntax.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b8vprv$o7u$1@digitaldaemon.com...
> And the problem with sorting them then is...?  Maybe that's what the user wants.  Maybe he wants a copy instead.  (S)he needs to specify.
>
> The problem is that sometimes you want to treat normally reference types
as
> values, and sometimes you want to treat values as references.  We have to use two different sets of syntaxes and thus the type system is not
unified.
> We can't really just say what we want, we have to remember what *type* the thing is and say it differently.  This impedes generic programming.
>
> This sort issue, the in/out/inout issue, most of this is symptoms of
kludges
> around this basic fact.  Trying to "make it easier" on people by
introducing
> two separate programming models with the same syntax.
>
> I wish there was no semantic difference between an class and a struct, or
in
> fact between a class and a basic type such as int.  I should be able to program them all the same way, with method calls and operators.  And if I want a copy I should be able to say "make a copy" and if I want a
reference
> I should be able to say "make a reference to x", of course with much
terser
> syntax, but one that is explicit.  But it should be obvious what it is
that
> I'm doing;  hiding references is a bad idea. I want the references to
stick
> out to the naked eye, like & and * do in C.  I'd rather do something like this though:
>
> int& g = 10; // reference to int
>
> void inc(int& i)  // we're reinventing ++ today  ;)
> {
>     i = i + 1; // dereferencing is automatic
> }
>
> {
>     int foo;  // init to zero, since we don't specify anything else
>     inc(&foo);  // require making explicit reference to foo
>     inc(foo);  // or don't, I'm not that picky, but the & helps to be
clear
> about what's going on.
>     print(foo); // please?  how hard should this be?  prints 2
>     int& dog = foo;
>     inc(dog);  // passing a reference in is no problem, no need for &,
which
> would be redundant, unnecessary,
>     print(dog); // prints 3
>     dog = g;  // store a 10 into foo thru dog reference
>     dog = &g;  // this is still only assigning a 10 into foo, because
> references are automatically dereferenced if necessary during implicit
> conversion.
>     // they could be automatically created if necessary too, but this may
> not be desirable.  I kinda like references being transparent though.
>     &dog = &g; // assign reference to g to reference named dog
>     inc(&dog);  // would form a reference to reference to int which
> automatically implicitly casts to reference to int
>     print(dog); // prints 11
>     print(foo); // prints 10
> }
>
> But I bet that D is no longer malleable enough to make such a large
change.
>
> The compiler is always of course free to optimize away any physical reference if it can tell it is not needed.  The semantics have to be honored, though.  It must give the correct results.
>
> How to deal with references to references to references (double/triple indirection in C with pointers)?  This would require some kind of way to explicitly dereference, so you can get to the desired level.  Or you could force the programmer to declare an intermediate reference of the right
level
> or require an explicit cast.  Extra references should still be
automatically
> dereferenced.
>
> i.e.
>
> int aa = 1, bb = 2;
> int& a = &aa, b = &bb;
> int&& selector = which ? &a : &b;
> int& result = selector;
> print(result);
>
> I doubt a few &'s would clutter up your OO code that much.  And we could
use
> the same &'s for dealing with arrays by reference, or, occasionally, ints. If you think that'll add too many &'s, invert the whole thing the other
way
> and do everything by reference *unless* the user explicitly requests a
copy.
> You could indicate a value type using #, and dereference a reference (promote to actual value, or "copy" it) by using the unary # operator.  We could have #= for by-value assignment (explicit copy) and #== for value comparison.
>
> One problem with using = for assignment and == for comparison is then how you do make reference assignment and reference comparison?  D has gone the way of === for reference comparison and no explicit reference assignment. That leaves reference in the data realm, not operator realm.  I'd prefer
to
> state intent at time of assignment or comparison, in an unambiguous way, using := for reference assignment and :== for reference comparison.
>
> Am I crazy?  Things don't have to be this complicated.
>
> Then maybe we can do fun things like build our own reference types and overload referencing/dereferencing.
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:b8uigr$2lb4$1@digitaldaemon.com...
> >
> > "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b8u7ht$29tg$1@digitaldaemon.com...
> > > Which is why slices and arrays should be different beasts.
> >
> > It's not just slices, two handles can refer to the same array.
>
>