This is great preliminary work. The next steps are to write up the following papers, in the given order, and submit them to J3. They can be combined and/or multiple submitted for a given meeting. You can find the paper template and many examples on the J3 website.
Use Cases - what code would you like to be able to write that you can’t now
Requirements - what must the feature provide, be capable of
Semantics - how will the language behave to satisfy the requirements
Syntax - define any new syntax, and redefine any existing syntax as necessary for adding the feature
Edits - describe exactly the edits to be made to the standard to include the feature
Note, you should have any eye on step 5 as you write papers 3 and 4, in order to hopefully not miss any ways in which the language must be changed.
Like I said, I’m happy to submit and advocate for papers on others behalf, but I have my own projects to work on so I don’t really have time to be the one to write them.
I would hope that there is a little more informal discussion about this first here in this discourse group. Are there other semantics that should be considered? Can full allocate-on-assignment semantics be mimicked with i/o? Is there a way to allow multiple read statements to fill a single allocatable array? Should a keyword in the read statement be required, or can the processor detect when this should be invoked in all cases without a keyword? You mentioned coarrays before, should any consideration be allowed for coarrays?
Reading into allocatable character variables was considered for 202X but dropped due to compatibility issues. As noted above, if you restrict this to unallocated arrays/character, you don’t know where to stop. I was in favor of the feature in general.
We did, at least, extend internal write to reallocate the buffer if needed.
I would expect discussion here to continue throughout the process. Of course you’ve already identified some interesting questions that should be thought about.
Probably. I haven’t thought hard about it yet, so I’m not sure what they’d be.
You could maybe get close in some aspects?
I doubt it, but more exploration might reveal something.
I think you can answer this question later. My guess is you’ll want some extra syntax though.
Coarray allocation is a collective operation. I.e. every image must execute it. I can’t think of any situation where you’d want that behavior from a read statement. Probably best to just forbid it.
I can see where that might be a problem with allocatable character strings since the only stopping points might be the record length or an end of file. I would think the record length would still be very useful for the case where you want to read a whole record of unknown length into an allocatable string.
What is your opinion of the list-directed and namelist examples I gave above? It seems like the stopping points are well defined in those cases, and those aren’t just niche cases, those are what I think would be the bread and butter use cases.
This would require the keyword form of the read statement because there are backward compatibility problems otherwise.
What I have in mind here is the ability to process some input records but to defer the allocation temporarily, then do some computations, and then resume the processing of more input records. A programmer can do this now with his own linked-list processing of input items, so I was thinking of how that might be done with a read statement approach.
If this is not allowed, then the programmer could always read into a local array and then broadcast that to the coarray distributed structure.