Its an idea that would be very easy to implement as it changes little from the curent implemtation but provides two benefits, the length will be encapsulated with the array and slices can have copy on write. And not a ref count is sight :)

Dynamic arrays and slices are still a pointer/length pair. The diferance is that a Dynamic array has a length of -1. So the ptr points to the first element of the array, and a lenght of -1 indicates that the length is stored in the dword imediatly preceding the first element, at (ptr - 4).

A slice stays exactly as it is curently implemented but as you can now tell the diferance between a slice and dynamic array, any attemp to alter a slice would create a new dynamic array. Or you could have a propery of arrays 'array.isSlice' and people could copy on write if they want?

I think a big plus is this should be very easy to implement.

obviously the copy on write is a bit one sided because only slices are cow. But you cant get true copy on write without heavy ref counting which is alot of hassle i think, and probably not worth it just for cow.

chris

That is a great idea.  Most of the time the -1 could be optimized away by
the compiler.  Certainly it only needs to be checked once upon each exposure
to an array or slice from an unknown source.  Once classified an appropriate
code path can be chosen.
You wouldn't have to check for -1 every iteration of a loop over the
contents, for example.

The copy on write only if people want to might be the best solution.  Just let users be responsible and they'll copy when needed.  It would work, it's direct, and easy to implement in the compiler.

Sean

"chris jones" <flak@clara.co.uk> wrote in message news:ankj7t$vb5$1@digitaldaemon.com...
> Its an idea that would be very easy to implement as it changes little from the curent implemtation but provides two benefits, the length will be encapsulated with the array and slices can have copy on write. And not a
ref
> count is sight :)
>
> Dynamic arrays and slices are still a pointer/length pair. The diferance
is
> that a Dynamic array has a length of -1. So the ptr points to the first element of the array, and a lenght of -1 indicates that the length is
stored
> in the dword imediatly preceding the first element, at (ptr - 4).
>
> A slice stays exactly as it is curently implemented but as you can now
tell
> the diferance between a slice and dynamic array, any attemp to alter a
slice
> would create a new dynamic array. Or you could have a propery of arrays 'array.isSlice' and people could copy on write if they want?
>
> I think a big plus is this should be very easy to implement.
>
> obviously the copy on write is a bit one sided because only slices are
cow.
> But you cant get true copy on write without heavy ref counting which is
alot
> of hassle i think, and probably not worth it just for cow.
>
> chris

I was also thinking that where speed is of real improtance bounds checking will be turned off and so the length wont even need to be looked up on each element access.

chris


"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:anm435$2gn3$1@digitaldaemon.com...
> That is a great idea.  Most of the time the -1 could be optimized away by the compiler.  Certainly it only needs to be checked once upon each
exposure
> to an array or slice from an unknown source.  Once classified an
appropriate
> code path can be chosen.
> You wouldn't have to check for -1 every iteration of a loop over the
> contents, for example.
>
> The copy on write only if people want to might be the best solution.  Just let users be responsible and they'll copy when needed.  It would work,
it's
> direct, and easy to implement in the compiler.
>
> Sean
>
> "chris jones" <flak@clara.co.uk> wrote in message news:ankj7t$vb5$1@digitaldaemon.com...
> > Its an idea that would be very easy to implement as it changes little
from
> > the curent implemtation but provides two benefits, the length will be encapsulated with the array and slices can have copy on write. And not a
> ref
> > count is sight :)
> >
> > Dynamic arrays and slices are still a pointer/length pair. The diferance
> is
> > that a Dynamic array has a length of -1. So the ptr points to the first element of the array, and a lenght of -1 indicates that the length is
> stored
> > in the dword imediatly preceding the first element, at (ptr - 4).
> >
> > A slice stays exactly as it is curently implemented but as you can now
> tell
> > the diferance between a slice and dynamic array, any attemp to alter a
> slice
> > would create a new dynamic array. Or you could have a propery of arrays 'array.isSlice' and people could copy on write if they want?
> >
> > I think a big plus is this should be very easy to implement.
> >
> > obviously the copy on write is a bit one sided because only slices are
> cow.
> > But you cant get true copy on write without heavy ref counting which is
> alot
> > of hassle i think, and probably not worth it just for cow.
> >
> > chris
>
>

A worthy study might save us from reinventing array processing.  We could examine how other languages have implemented these features and borrow the best concepts.

That strategy would be more rational than ab initio design discussions.  We
would benefit from years of previous experience.  There are math packages
(Mathematica/MATLAB), math libraries (blitz++, MTL), script languages (Python,
Icon), and of course STL to borrow from.

Another thing that concerns me is the dimensionality issue.  I would like array features to work on arrays of more than one dimension in a consistent fashion.

Thoughts Walter?

Mark

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:anndsm$1k06$1@digitaldaemon.com...
> A worthy study might save us from reinventing array processing.  We could examine how other languages have implemented these features and borrow the
best
> concepts.

That would be a good idea. Although how do you decide what are the best concepts? As can be seen in the -index thread one mans water is another man wine. And this depends on what you want from the language, it is more personal need than it is an altruistic desire for the best language for all.

> That strategy would be more rational than ab initio design discussions.
We
> would benefit from years of previous experience.  There are math packages

It still needs to be discused at some point.

> (Mathematica/MATLAB), math libraries (blitz++, MTL), script languages
(Python,
> Icon), and of course STL to borrow from.

Actualy im not much use for such a discusion/study because i dont need mega features nor do i know anything about the above languages. Arrays already have more features than i need, the only problem i have with them is i would like them to be more self-contained like objects. I dont even want copy on write that was just a side effect of me thinking up a way for the lenght to be stored with the memory block :)

chris

>> A worthy study might save us from reinventing array processing.
>
>That would be a good idea. Although how do you decide what are the best concepts?

We vote and Walter decides.

>Actualy im not much use for such a discusion/study because i dont need mega features nor do i know anything about the above languages. Arrays already

All right, you have cast a vote then.

I don't need mega-features either but would like more than exist now.  The circular discussions taking place have me worried about D.  Other people have been down these rabbit holes before.

Mark