Anthony Stone wrote:
>I regard it as a clumsy tool for the
>lazy programmer.
>
Lazy indeed. The whole point is that I do not have time or will to write
10,000 lines of parsing code and hook them to my computational routines
just so I can parse input.
>I use a routine that
>reads a keyword from the input, and then uses a CASE structure to
>decide what to do next.
>
But assume I have to read 10 sets of input, one for each part of the
algorithm. These need to be kept separate, as in any structured
programming approach. I then have to recode the same CASE nests of tree
parsers or whatever for each ``namelist". The convenience of Fortran 95
NAMELISTs is that the correct values, types, etc. are a regular part of
the program, the compiler just infers them, checks them, reads them and
puts them in the correct place.
The things I dislike about Fortran namelists: One cannot specify derived
types and/or components of objects of derived type, and most of all, no
variable-length arrays...
If one is to write a general purpose replacement for NAMELIST in Fortran
95, I think something based on pointers is good. For each field that
needs to be read, there is a pointer which points to where the data
should be read to. There should be of course corresponding types for
integer, real, string fields, arrays of these, etc. Other information
should be the name of the field, some relations to other fields if
possible, etc. OOP techniques available in F2x might simplify some of
these (if we decide finally to allow CLASS(*) pointers to point to
intrinsic types also)...CASE just won't do...
I am certainly no big fan of namelists, but they are most useful for
someone who does not wish to code his own parser...
Best,
Aleksandar
|