At 09:35 on 26 February, Aleksandar Donev wrote:
> 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.
That's fair enough, but the basic parsing code is in the module which
I am happy to provide if you want it. (It's less than 1,000 lines,
including lots of comment.) The CASE structure is very simple to write
and very flexible, and may in fact be easier than the NAMELIST
manipulations that your code seems to need. But of course this is your
decision -- I'm not trying to force anything on you, just offering an
alternative that you (and anyone else) can take or leave as you wish.
> >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.
Well, it may be able to check that the types are correct, so that you
get an error unless you provide an integer where the program expects
one, and so on. I don't see how NAMELIST can check that the value is
sensible, though, so you still have to provide code to do that, and
since you don't know which of the variables in the list were given in
the input, you have to check them all even if only one may have been
changed.
> 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...
A further point: most of my programs are used by other people as well
as myself. For a user who is not familiar with the innards of the
code, NAMELIST input can be extremely obscure for the user. (I have
had to use such programs, which has much to do with my dislike of the
technique.) Keyword-based input organisation is easier to document,
easier to remember and easier to use.
--
Anthony Stone http://www-stone.ch.cam.ac.uk/
University Chemical Laboratory, Email: [log in to unmask]
Lensfield Road, Phone: +44 1223 336375
Cambridge CB2 1EW Fax: +44 1223 336362
|