namelist io of arrays and derived types - status and questions

[THOMAS Paul Richard <prthomas at drfccad dot cea dot fr>]

I have made a fair amount of progress in expanding the implementation of
arrays and derived types in namelist io. I thought to record what I have
done so far; partly because I am going to be away for a couple of weeks and
partly because I have some questions about the the exercise. Please excuse
me for the length of the following message.

Overall, the status is that arrays, whose shape is known at compile time,
are transferred, as are derived types that are not arrays. Character arrays
cause an ICE, which I have not attempted to isolate yet, and derived type
arrays cause some kind of unpleasantness in the tree structure:

test_read.f90:9: internal compiler error: tree check: expected record_type
or 
union_type or qual_union_type, have array_type in find_compatible_field, at
tree.c:6004

I think that I know what this last is about but have have not yet tried to
deal with it. I have put in code that throws on attempts to do either of
these. At the back-end, namelist writes are more or less there and produce
"neat" output, like the following test case:

&thynml
m= 2.000000 ,
n= 3* 99.00000 ,
x%ii= 2, 98, 97, 96,
x%rr= 4* 42.00000 ,
x%zz= 2*( 2.000000 , 3.000000 ),
x%chr=hello ,
x%mytype_type%qe= 1.5999999E-19,
z= 10* 0.000000 ,
ch=hello ,/

( Yes, &thynml as opposed to mynml....!)

Should I put quotes about strings, as a matter of course?

I have not touched list_read.c but have sketched out the code that will be
able to read the above and read elements of arrays by indices. I am aiming
at compatibility with the Digital/Compaq/HP, Portland and Intel compilers so
that most working codes will run with gfortran.

fortran:

I have chosen to implement arrays by expanding the namelist_info type to
include the rank, together with upper and lower index bounds:

typedef struct namelist_type
{
bt type;
struct namelist_type * next;
char * var_name;
void * mem_pos;
int value_acquired;
int len;
int string_length;
int var_rank;
int * lower;
int * upper;
}
namelist_info;

I toyed with a number of variations, such as including array_specs or
dimension descriptors, and concluded that the above is both sufficient and
the most economical in storage and code. The inclusion of the rank
necessitated feeding a pointer to the array_spec to the
transfer_namelist_element function. In order to expand the derived type
names, I also added an argument carrying the variable name in the form of a
string. This latter seemed to be better than back-converting the tree string
that carries the name. 

I have left the set_nml_val_xxx functions as they are, except for the
addition of an argument carrying the rank. I can see how to eliminate the
separate functions for each type but do not think that this is necessary or,
indeed, necessarily desirable. The alternative, of building up and
transferring the entire structure, is beyond my present knowledge. However,
this could be implemented in the future, without modifying the back-end.

As a result of my lack of expertise, I chose to transfer the bounds, using
rank*calls to a new function st_set_nml_bounds ( int n , int lbound , int
ubound ). I could not see how to transfer an integer parameter array, other
than by a char* cast, which looked so messy that I did not do it. If
somebody can point out to me how to do this by transferring the integer
array directly, I will give this a try. However, the present compromise does
not look too bad and is completely bomb-proof.

As with the commercial compilers, I have chosen to expand the components of
derived types as intrinsic types with the fully expanded component symbol
derived_name%component_name. As far as I can see, the standard is a bit
vague about this but compatibility is retained. Does anybody have any strong
feelings about this?

libgfortran:

The namelist write is more or less there. I have yet to try to get my head
around character arrays because of the front-end problem. Repetitions of
integer, real and complex types are handled correctly. As a matter of taste,
I like to put each variable, indented, on a new line, so I have implemented
this. I have not and will not attempt to align the comma separators unless
really pressed so to do! As mentioned above and illustrated in the sample
output, derived types are output in the same way as with the commercial
compilers.

The namelist read is still on the drawing board. I have designed the input
of entire or partial arrays, elements and could, in principle, include
ranges. Does anybody have any strong desire that the input be list directed?
It is not needed for the standard or for compatibility or even for
functionality, as far as I know, but could quite easily be done. I have
already done some tidying up, in respect of blank lines, comments and
strings, as per the recent, poorly put message to the list. 

I have written some test programmes that exercise both input and output. I
will check them with the commercial compilers. More importantly, I have
several "working" codes that are only awaiting these modifications before
they will compile and run with gfortran. Once they work, I will really feel
that I have made it!

How should I submit this lot? It is more than a patch, extends over a number
of source files but has some flaws that could and should, I suspect, easily
be tidied up by folk more expert than me. At the present rate of progress, I
can see my way to having the namelist read up and running, the test cases
sorted and the "working" codes going by mid-January.

Paul Thomas