Hi Damian - I'll try to answer your questions below.
On 8/3/15, 7:43 PM, "Damian McGuckin" <[email protected]> wrote: > >Michael, > >I am replying to your email now to keep things ticking over. Please >realise that some answers are incomplete. Also, I think you are talking >from the perspective of having more Chapel documentation than I have > >I looked at the 'heap' example recently posted by Mark Clemens and then >commented up by Brad. I realized that this syntax > > var D : domain(1) = { 0 .. -1 }; > >in a domain exists now. Where is this documented please? So is domain >resizing already handled in Chapel formally? I looked for resize in the >Chapel 0.97 document and it is not really addressed. Section 19.8.1 says you can use assignment to resize a domain. For example, D = { 1..10 } In addition, we recently implemented operations similar to C++ vectors for 1-D arrays with non-shared domains. Examples of that are here: {test/release/}examples/primers/arrayVectorOps.chpl > >On Mon, 3 Aug 2015, Michael Ferguson wrote: > >> What would be most useful about this bit of history is if we knew >> *why* flexible array bounds were regarded as a no-no by many >> people. > >I was simply reminding people to look. I have never used the concept in >Algol68 although I use it ever so occassionally in C/C++. I had a look at "A History of ALGOL 68" by Lindsey, which only reports that appending to a flexible array was commonly desired but not implemented in the standard library. It didn't say that flexible arrays were "considered harmful" or anything like that. Flexible arrays in Algol are marked as such - so a Chapel analogue would be if we had something like var A:[flex 1..10] int; which would mean that A could be resized. But all Chapel arrays can already be resized - it's just that for a long time we had the rule that you had to separately declare the domain in order to do the resizing, like this: var D:domain(1) = {1..10}; var A:[D] int; D = {1..100}; // resizes A That changed with the push_back idea (see the arrayVectorOps example above). Now the array can be resized through an operation on the array if the domain is not shared with other arrays (otherwise, such operations generate an error). E.g.: var A:[1..2] int; A.push_back(1); ( results in [0,0,1] ). > >>>> mychannel.read(A); >>>> >>>> could read into A any number of elements and adjust its domain >>>> accordingly. > >Adjusting the domain in > >a) size has been in use in C/C++ so I think it is a quite sound concept > as long as it does not conflict with memory allocation algorithms > >b) dimensions might have issues with program proofs. I have never used the > idea of change in dimensions so I am of little use. I'm only talking about (a). I don't think that changing the dimension in these cases makes any sense. Changing the dimension would change the type of the domain... but changing the size only changes the contents of the domain. > >> I think it's worth the improvement in productivity, and I don't think >>we >> can convince people who have used Python and the like that they can't >> have e.g. >> >> myArray.push_back(1); >> >> because it resize the array. > >I would prefer that Chapel be more aligned with something like C/C++ >rather than Python. Just a personal preferance. I love Python and will >continue to use it. Chapel I see as more of a C++ replacement. The example, push_back, came from C++. We try to be aware of what languages Chapel users will already be familiar with. > >> 3) You can't do a whole-array read from JSON or a Chapel array >> literal-like format without this functionality. So, it makes >> the I/O code more complicated. > >I would prefer complexity in the I/O rather than in the language. We're really talking about complexity in the standard library vs complexity in common user code. Cheers, -michael ------------------------------------------------------------------------------ _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
