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

 count is sight :)

 Dynamic arrays and slices are still a pointer/length pair. The diferance

 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

 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

 the diferance between a slice and dynamic array, any attemp to alter a

 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

 But you cant get true copy on write without heavy ref counting which is

 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

 to an array or slice from an unknown source.  Once classified an

 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,

 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


 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

 count is sight :)

 Dynamic arrays and slices are still a pointer/length pair. The diferance

 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

 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

 the diferance between a slice and dynamic array, any attemp to alter a

 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

 But you cant get true copy on write without heavy ref counting which is

 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

 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.

 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

 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