"Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D7CE643.4080108@deming-os.org...
> I've pondered what the semantics of a "copy on write" array would be. COW is a virtual memory device where two virtual pages can point to the same physical page as long as neither is modified.  This is very common after fork()ing a process...both processes have identical page tables until one or the other writes.  The write fails (page fault) and the memory manager makes a second copy of the page in question, which is writable, and then re-enables the process.
>
> It would be cool to have an array type such that you would be referencing the original array until you tried to modify it, either by resizing it or changing one of the elements.  I don't know what the syntax or usage would look like, though.

Copy-on-write for arrays would be really cool, but I think it would need hardware support.

"Walter" <walter@digitalmars.com> wrote in news:alb8qn$1pea$1@digitaldaemon.com:

> Everyone has pointed out that the current implementation of array resizing is too slow to be useful - the always copy semantics just aren't good enough. Various remedies were proposed, most of which added bloat or slowed down loops. The reason for the copy semantics to begin with were to deal with the cases of resizing a slize out of a larger array.
> 
> So, perhaps this can be fixed by just a specification change - don't resize slices.

So let me see if I have this right. If slice size should not be changed then it leaves open the possibility that slice length can be a loop invariant. If the length is invariant then techniques like a bit flag can be used to efficiently to distinguish between arrays and slices.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9284B5AAB7F25patcodemooncom@63.105.9.61...
> So let me see if I have this right. If slice size should not be changed then it leaves open the possibility that slice length can be a loop invariant. If the length is invariant then techniques like a bit flag can be used to efficiently to distinguish between arrays and slices.

The compiler doesn't know if any random dynamic array is a slice or an original.

"Walter" <walter@digitalmars.com> wrote in news:alb8qn$1pea$1@digitaldaemon.com:

> Everyone has pointed out that the current implementation of array resizing is too slow to be useful - the always copy semantics just aren't good enough.

Ok the problem stated is:

1. Current implementation of array resizing is too slow to be useful

> Various remedies were proposed, most of which
> added bloat or slowed down loops. The reason for the copy semantics to
> begin with were to deal with the cases of resizing a slize out of a
> larger array.

Understood

> 
> So, perhaps this can be fixed by just a specification change - don't resize slices.

How does this solve the problem?

On Mon, 9 Sep 2002 12:57:05 -0700, "Walter" <walter@digitalmars.com> wrote:
> 
> "Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D7CE643.4080108@deming-os.org...
> > I've pondered what the semantics of a "copy on write" array would be. COW is a virtual memory device where two virtual pages can point to the same physical page as long as neither is modified.  This is very common after fork()ing a process...both processes have identical page tables until one or the other writes.  The write fails (page fault) and the memory manager makes a second copy of the page in question, which is writable, and then re-enables the process.
> >
> > It would be cool to have an array type such that you would be referencing the original array until you tried to modify it, either by resizing it or changing one of the elements.  I don't know what the syntax or usage would look like, though.
> 
> Copy-on-write for arrays would be really cool, but I think it would need hardware support.
> 
> 

The RDS implementation of the Euphoria language does this implictly. An array is copied as a reference until it is modified, at which time a physical clone is made. It makes for very speedy array passing in parameters and for temporary intermediate arrays.

---------
Cheers,
Derek Parnell

Walter wrote:

> Copy-on-write for arrays would be really cool, but I think it would need
> hardware support.

Strings in Delphi use copy-on-write without any special hardware. =)
And strings are just arrays of characters...

"Derek Parnell" <ddparnell@bigpond.com> wrote in message news:1103_1031628855@news.digitalmars.com...
> The RDS implementation of the Euphoria language does this implictly. An
array is copied as a
> reference until it is modified, at which time a physical clone is made. It
makes for very speedy
> array passing in parameters and for temporary intermediate arrays.

Javascript also does copy-on-write. But the performance is terrible compared with typical C. Hardware support would make it much more practical.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:aljvp8$1drj$1@digitaldaemon.com...
> Walter wrote:
>
> > Copy-on-write for arrays would be really cool, but I think it would need hardware support.
>
> Strings in Delphi use copy-on-write without any special hardware. =) And strings are just arrays of characters...

What's the performance like on:

    for (i = 0; i < 1000; i++)
        a[i] = 'c';

Would that copy the array 1000 times?

Maybe it should.  Which reference has the power to resize an array?  The auto reference.  The others are all slices and can't resize the array thru a slice.

There are so many ways to get into trouble with slices as they exist now.. resize an array out from under some slices to it, resize a slice of a larger array.  I'd rather have the language guard against this.

It would almost have to enter the type system to guarantee enforcement. There should be some class difference between a slice and a real array. Slices are definitely reduced functionality ... maybe dynamic array is really a special class of slice that can be resized or modified.  Writable fixed array is a slice with a write operation.  Dynamic array is a writable slice that can change size as well.  Slicing an array should really obtain some kind of lock against resizing of the original array, and the slice's destructor releases that lock.

Isn't a lock kinda like the opposite of a reference count?  Interesting viewpoint though... a lock will prevent the auto-destroy from deleting an object it would otherwise collect.  If everything just incremented on obtaining a reference, test-and-decremented when releasing it at scope exit or before assignment, and if zero destroying it... seems simple enough at least.  Just disallow circular references.  Impossible to emulate this kind of thing in D without overloading the assignment operator or copy constructor type of stuff C++ lets you do.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:aljctp$8rt$1@digitaldaemon.com...
>
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9284B5AAB7F25patcodemooncom@63.105.9.61...
> > So let me see if I have this right. If slice size should not be changed then it leaves open the possibility that slice length can be a loop invariant. If the length is invariant then techniques like a bit flag can be used to efficiently to distinguish between arrays and slices.
>
> The compiler doesn't know if any random dynamic array is a slice or an original.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9284D2EE6549Dpatcodemooncom@63.105.9.61...
> How does this solve the problem?

It can be resized in place, rather than by copying.