Reading the D documentation about Arrays and their properties, I wonder about
the
definition of dup, reverse and sort properties. As far as I can understand, the
behaviour
is of these properties is:

int[] a, b;
(1)  a  =  b;            a points to same array as b does
(2)  a  =  b.dup;      a points to a copy of b
(3)  a  =  b.reverse; a points to same array as b; b is reversed
(4)  a  =  b.sort;      a points to same array as b; b is sorted

While lines (1) and (2) are intuitively clear, I have a problem with the lines
(3) and (4).
I would expect the behaviour:

(3a) a  =  b.reverse;  a points to reversed copy of b; b is unchanged
(4a) a  =  b.sort;       a points to sorted copy of b; b is unchanged

When sorting an array in place, the properties are evolving to methods:

(5)  b.reverse;          b reversed in place
(6)  b.sort;               b sorted in place

To reverse/sort an array in place, the using of properties I would expect are:

(5a) b  =  b.reverse;  b reversed in place
(6a) b  =  b.sort;       b sorted in place

Am I missing something? Or are there strong reasons to define the first behaviour?

--  Ziemowit

    ziemek@tera.com.pl

Ziemowit Zglinski wrote:

> While lines (1) and (2) are intuitively clear, I have a problem with the lines
> (3) and (4).
> I would expect the behaviour:
>
> (3a) a  =  b.reverse;  a points to reversed copy of b; b is unchanged
> (4a) a  =  b.sort;       a points to sorted copy of b; b is unchanged
>
> When sorting an array in place, the properties are evolving to methods:
>
> (5)  b.reverse;          b reversed in place
> (6)  b.sort;               b sorted in place
>
> To reverse/sort an array in place, the using of properties I would expect are:
>
> (5a) b  =  b.reverse;  b reversed in place
> (6a) b  =  b.sort;       b sorted in place
>
> Am I missing something?
> Or are there strong reasons to define the first behaviour?

I agree that your interpretations are better, in theory.  I think that Walter chose the order he did because he was looking for reasonably fast speed while still having simple compilers.  The problem with your example (5a) is that there are two possible interpretations that the programmer might want:

    (5a) b = b.reverse;

In this definition, "b.reverse" creates a new array, which contains the (reversed) contents of the old "b" array.  Then you set "b" to point at that array.  So you're not really reversed in place, you're creating a new array that is reversed from the old one.  To reverse in place, you have to do this:

    (6a) b[] = b.reverse;

In theory, you are declaring that the program do these steps:
    1) Create a new array, T, on the heap
    2) Copy the elements of b into T, reversed
    3) Copy the elements of T into b
    4) Later (during GC) clean up T

A good optimizer might be smart enough to collapse that down to "reverse b in place."  But still, you don't have a language element that explicitly exists for reversing in place.

--
The Villagers are Online! http://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))) ]

Another idea to resolve the "reverse/sort in place problem" would it be
to define the METHODS reverse()/sort() to the array definition, as
opposite to PROPERTIES reverse/sort. It would mean the syntax:

(5b)  b.reverse();     b reversed in place (6b)  b.sort();        b sorted in place

This also syntactically highlites the in place operation. Also the hidden
function call (and side effect) inside the property is made clearly visible.
So the interpretation of lines (5a)/(6a) would be exactly as you indicated.

-- Ziemowit

ziemek@tera.com.pl

In article <3E74EF65.C0AF0CA7@deming-os.org>, Russ Lewis says...
>
>Ziemowit Zglinski wrote:
>
>> While lines (1) and (2) are intuitively clear, I have a problem with the lines
>> (3) and (4).
>> I would expect the behaviour:
>>
>> (3a) a  =  b.reverse;  a points to reversed copy of b; b is unchanged
>> (4a) a  =  b.sort;       a points to sorted copy of b; b is unchanged
>>
>> When sorting an array in place, the properties are evolving to methods:
>>
>> (5)  b.reverse;          b reversed in place
>> (6)  b.sort;               b sorted in place
>>
>> To reverse/sort an array in place, the using of properties I would expect are:
>>
>> (5a) b  =  b.reverse;  b reversed in place
>> (6a) b  =  b.sort;       b sorted in place
>>
>> Am I missing something?
>> Or are there strong reasons to define the first behaviour?
>
>I agree that your interpretations are better, in theory.  I think that Walter chose the order he did because he was looking for reasonably fast speed while still having simple compilers.  The problem with your example (5a) is that there are two possible interpretations that the programmer might want:
>
>    (5a) b = b.reverse;
>
>In this definition, "b.reverse" creates a new array, which contains the (reversed) contents of the old "b" array.  Then you set "b" to point at that array.  So you're not really reversed in place, you're creating a new array that is reversed from the old one.  To reverse in place, you have to do this:
>
>    (6a) b[] = b.reverse;
>
>In theory, you are declaring that the program do these steps:
>    1) Create a new array, T, on the heap
>    2) Copy the elements of b into T, reversed
>    3) Copy the elements of T into b
>    4) Later (during GC) clean up T
>
>A good optimizer might be smart enough to collapse that down to "reverse b in place."  But still, you don't have a language element that explicitly exists for reversing in place.
>
>--
>The Villagers are Online! http://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))) ]
>
>

I've been thinking about this. I think you're probably right - .reverse and .sort should return copies.

"Ziemowit Zglinski" <Ziemowit_member@pathlink.com> wrote in message news:b52p24$les$1@digitaldaemon.com...
> Reading the D documentation about Arrays and their properties, I wonder
about
> the
> definition of dup, reverse and sort properties. As far as I can
understand, the
> behaviour
> is of these properties is:
>
> int[] a, b;
> (1)  a  =  b;            a points to same array as b does
> (2)  a  =  b.dup;      a points to a copy of b
> (3)  a  =  b.reverse; a points to same array as b; b is reversed
> (4)  a  =  b.sort;      a points to same array as b; b is sorted
>
> While lines (1) and (2) are intuitively clear, I have a problem with the
lines
> (3) and (4).
> I would expect the behaviour:
>
> (3a) a  =  b.reverse;  a points to reversed copy of b; b is unchanged
> (4a) a  =  b.sort;       a points to sorted copy of b; b is unchanged
>
> When sorting an array in place, the properties are evolving to methods:
>
> (5)  b.reverse;          b reversed in place
> (6)  b.sort;               b sorted in place
>
> To reverse/sort an array in place, the using of properties I would expect
are:
>
> (5a) b  =  b.reverse;  b reversed in place
> (6a) b  =  b.sort;       b sorted in place
>
> Am I missing something?
> Or are there strong reasons to define the first behaviour?
>
> --  Ziemowit
>
>     ziemek@tera.com.pl

Walter wrote:
> I've been thinking about this. I think you're probably right - .reverse and
> .sort should return copies.

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.

From a simple matter of incidence, of 15 uses of .sort in some of my code, only 2 use .dup.sort.  But even were that inverted, I can get the opposite behaviour when .sort is noncopying, but I'm impotent when .sort copies.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b64enj$2t8h$1@digitaldaemon.com...
> Walter wrote:
> > I've been thinking about this. I think you're probably right - .reverse
and
> > .sort should return copies.
>
> 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.
>
>  From a simple matter of incidence, of 15 uses of .sort in some of my
> code, only 2 use .dup.sort.  But even were that inverted, I can get the
> opposite behaviour when .sort is noncopying, but I'm impotent when .sort
> copies.

I was afraid of that :-(

> 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".

-- Dario

I dislike having to rely on compiler optimizations.  I'd rather the language have the expressiveness required to tell the compiler exactly what I want it to have the program do.  If it does anything above and beyond the call of duty, that's just gravy.

Sean

"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".
>
> -- Dario

Hi, Sean.

I also don't want sort and reverse to make copies.  I can easily do that manually before calling them.

As for the larger point of having to rely on compiler optimizations, I hate having to learn templates for code layout, and then use them in my programming.  For one thing, no two compilers will agree on the templates that generate efficient code, even if both conform to the standard.

However, I also would like the compiler to do more optimizations than is currently possible in C, because C gives up too much control.

One of my favorite examples is automatically generated unions.  I find that as much as 1/3 of all object fields in the EDA databases I've used in the past are never used at the same time.  For example, an instance can have both placement as an owning cell location, and an owning netlist partition, used during synthesis.  The compiler could in theory examine my program's flow, and determine that some fields don't have overlapping lifespans.  These could be put into unions.  If you do this manually, you not only confuse people, but you make the code fragile (Did I say synthesis and placement couldn't be done together?).

So, specifically what I'm saying is that memory layout of class objects should be abstract, and not determined by the user, other than to provide some guidance.  This is the case in D.   I'm looking forward to seeing some advanced optimizations that should further leave C in the dust.

Bill

Sean L. Palmer wrote:
> I dislike having to rely on compiler optimizations.  I'd rather the language
> have the expressiveness required to tell the compiler exactly what I want it
> to have the program do.  If it does anything above and beyond the call of
> duty, that's just gravy.
> 
> Sean
> 
> "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".
>>
>>-- Dario
> 
> 
> 

Dario wrote:

>>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 introduce an inconsistency:

   class Foo
   {
       int x;

       int cmp (Object other)
       {
          return a [0].x + x - other.x;
       }
   }

   Foo[] a;

   ...
   a[] = a.sort;

So it would have to be explicit semantics.