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.
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++.
> A lot has changed in languages and their implementation since then, and
> it would be easy to dismiss as a problem that just needed a slightly
> better solution.
While I could be somebody who might be in the dismissive camp, there was
something about it being back-the-front. That sounds fundamental but it
beyond my expertise.
>>> 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 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.
>>
>>> 2) Should any-dimensional rectangular arrays be written in binary in a
>>> form that encodes the size of each dimension? (In other words, write
>>> the domain first). Such a feature would make something like (1)
>>> possible for multi-dimensional arrays but might not match what people
>>> expect for binary array formats. (I don't think we've documented
>>> what you actually get when writing an array in binary yet...)
>>
>> Remind me what the argument is against demanding that prior to reading
>> the
>> array contents, the domain be read and then used to allocate the array?
>
> Three reasons:
> 1) Similarity with Chapel's array literal syntax
But the array literal syntax is known at compile time. What you are
proposing is done at run-time.
> 2) Some file formats do not include the length (e.g. JSON)
Yes. Cannot this be handled by a two pass exercise as you note later.
> 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.
> For example, if I have
>
> record MyRecord {
> var myArray: [1..0] int; // (start with empty array)
> }
>
> I might want to read something in this JSON format:
> {"myArray":[1,2,3]}
> {"myArray":[4,5]}
>
> I'd like to be able to do that with repeated calls to readf
> that indicate to use JSON format like this:
>
> var r:MyRecord;
>
> readf("%jt", r);
>
> where the format string has j for JSON format and t means
> "read or write anything" (vs e.g. a number or string).
Does 'read' really need to know about JSON? Cannot it be a module?
I worry that all of this is going to make Chapel's I/O as complex as C++
streams? Do not really want to go there?
> If I had to read the array's size separately I would have
> several problems in expressing this:
> 1) I now have to write a readThis for MyRecord when I didn't
> before (the readThis would resize the array). I still have
> to resize the array, I just have to do it in user code
Or in the module? Or have I missed something?
> 2) Since when doing the I/O, I don't actually know the size
> of the array, I have to either:
> a) write my own array element reading code that resizes the
> array as it goes, or
Too much overhead.
> b) read the array twice, once to count the number of elements
> and again to actually read them.
That's what I was implying. But quite low down, not really in user code.
> I think all this comes at a serious productivity cost (and a cost
> that I don't think is worthwhile if all we are hoping for is
> consistency between array types - which has a nebulous benefit
> on productivity especially if we can provide a reasonable error
> message when the implementation behaves differently than someone
> expects).
I need to think about that more.
I still prefer complexity in the I/O rather than in the language.
>>> 3) Any suggestions for a Chapel array literal format for
>>> multi-dimensional arrays?How would you write such arrays in JSON (and
>>> would anyone want to)? At one point there was a proposal to put the
>>> domain in array literals, like this:
>>
>>> var A = [ over {1..10} ];
>>>
>>> but that doesn't really answer how to write multidimensional array
>>> literals. One approach would be to store the array elements in a flat
>>> way and just reshape them while reading; e.g.
>>>
>>> var A = [ over {1..2, 1..3}
>>> 11, 12, 13,
>>> 21, 22, 23 ];
>>>
>>> where the spacing would not be significant.
I like that. However, I would like to be careful about the keyword 'over'
because I have an idea which wants to use 'over' for something else. Will
chat about that separately.
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
