www.digitalmars.com         C & C++   DMDScript  

D - idea - array length/slicing/cow

reply "chris jones" <flak clara.co.uk> writes:
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
Oct 04 2002
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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
Oct 05 2002
next sibling parent "chris jones" <flak clara.co.uk> writes:
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
Oct 05 2002
prev sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
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
Oct 05 2002
parent reply "chris jones" <flak clara.co.uk> writes:
"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
Oct 05 2002
parent Mark Evans <Mark_member pathlink.com> writes:
 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
Oct 05 2002