Prev: Software for plotting in Fortranxx?
Next: INTRINSIC STATEMENT for functions overloaded for user defined types
From: John on 16 Sep 2009 21:52
On Sep 15, 4:47 pm, Ron Shepard <ron-shep...(a)NOSPAM.comcast.net>
wrote:
> In article <h8oeud$g6...(a)news.eternal-september.org>,
>  Bil Kleb <Bil.K...(a)nasa.gov> wrote:
>
>
>
> > > [...] It has now been
> > > included in the Fortran 90 language. However, NAMELIST is a
> > > poorly designed feature and should be avoided whenever possible."
>
> > Interesting.  I find NAMELIST to be one of the few designs in the Fortran
> > language that actually adheres to the Open/Closed Principle.^1
>
> > My only complaint with NAMELISTs are the very poor error handling
> > diagnostics it seems to provide.  Then again, I haven't fully
> > investigated them yet.  My current ignorant complaint:  you don't
> > get detailed information about where a particular namelist read
> > went awry, e.g., a misspelled variable or bad syntax, just a
> > "namelist read failed" error code.
>
> I would have liked for fortran namelist to include some expression
> evaluation.  For example, something like
>
> &input
>    angle_1 = 12.34567
>    angle_2 = 2*angle_1
>    x       = cos(angle_1)
>    y       = sin(angle_1)
> /
>
> would simplify a lot of things.  The idea here is that the user would
> change only one line in the input file and the other dependent lines
> would change accordingly.  Even if the expression evaluation were
> limited to only simple arithmetic (+,-,*,/), it would still be useful.
>
> > > 2) I'm not sure, but i think using NAMELIST would make it harder
> > > for me to allow comments starting with # in my config file...
>
> > Yeah, you'd have to use Fortran's '!' for comments (and you'd have
> > to use the 14-year old F95 instead of the 19-year old F90 to portably
> > use them).
>
> I had forgotten that f95 changed some of the details of f90 namelist.
>
> However, for practical purposes, (almost) all compilers are (at least)
> f95+allocatableTR now, so it is safe to include comments.  As to whether
> ! or # is a better delimiter, I don't know, but if it comes down to an
> issue of which is easier for the user to determine and use, I think it
> is better to stick to a standard (fortran) than something entirely ad
> hoc (and specific to a particular program).  If the user wants to know
> how to format something, or how to comment something, it is easy to look
> it up if it is part of the fortran standard (e.g. using google).  If it
> is something cooked up for an individual program, the documentation
> might be difficult, or even impossible, to find, and once found, it
> could well be outdated, misleading, or wrong.
>
> When you combine this with my previous comments about how namelist makes
> things easier for the programmer, then it seems that namelist wins all
> round, both from the programmer's and the user's perspective.
>
> $.02 -Ron Shepard

Because I needed the feature you mention and because of the
nonstandard nature
of NAMELIST in times gone by I made a routine that allows NAMELIST-
like input
with expressions. Over the years it grew into what would now be called
an
embeddable scripting language including plotting and command line
history (it
even does regex expressions using something that started out as Ratfor
code from
something called the "toolbox", for those who remember) ; but
an eary version (in F77, no support of complex values, barely any for
arrays,
but very f77-standard-compliant except for VERY common extensions) is
at http://home.comcast.net/~urbanjost/CLONE/JUEXPR/juexpr.html if you
can't wait
for f2013 :>. On the one hand it is not that fast; and would be
written very
differently today (recursion, allocatable arrays, list-directed I/
O, ... all would
have made it easier to write) -- on the other hand it's been working
as-is in at
least 30 programming environments up to this day and was last changed
in 1988, I
think.
From: Bart Vandewoestyne on 17 Sep 2009 11:56
On 2009-09-15, Richard Maine <nospam(a)see.signature> wrote:
>
> You appear to have already found an answer on how to do this using
> internal read, which is the approach I use for this kind of thing. My
> only comment is...
>
>> read(unit=1, fmt=*, iostat=ios) variable_name, variable_value
>>
>> where variable_name is a character array
>
> No it isn't. If it were, then this would not work. Your variable name is
> a scalar character string - not an array. There are such things as
> character arrays, but this isn't one. Character strings and arrays have
> some similarities, but they are not the same thing. If you don't keep
> the concepts separate, you will later be back here asking for help with
> them - all but guaranteed.

Oops... seems I have some studying to do :-) Although I often
*try* to use the correct terminology here in this newsgroup, i
often see myself struggling with it ;-)

Anyway, thanks for the comments!
Bart

--
"Share what you know. Learn what you don't."
From: Dave Allured on 25 Sep 2009 14:46
Richard Maine wrote on 2009-sep-15:
>
> Dave Allured <nospom(a)indra.com> wrote:
>
> > I have run into at least one compiler that did not do what you expect
> > with this (standards notwithstanding):
> >
> > read(unit=1, fmt=*, iostat=ios) variable_name, variable_value
>
> I have not, and I've used this kind of thing on more compilers than can
> easily be counted, even since it was introduced in f77. It would be
> helpful if you would specify exactly what *DID* happen instead of just
> that it "did not do what you expect". My guess is that your expectations
> ran contrary to the standard, but there is no way I can verify that from
> the information given. I cannot agree to recommendations based on a
> single vague and unverified claim.
>
> For example, if the value has any special characters (a / as often found
> in pathnames is one example), the result might surprise you, but that
> would be in accordance with the standard.
>
> There are lots of other possibilities that might surprise you, but are
> still in accordance with the standard. I don't think I'll try to list
> them all.
>
> > If you are interested in portability, then do the original read with
> > formatted input rather than list-directed input:
>
> I'll give my knee-jerk reaction to this common error. List-directed
> input is a form of formatted input. In fact, the long-winded term is
> "list-directed formatting", although you mostly won't see people being
> quite that verbose outside of the standard. What you are referring to is
> explicit formatting as opposed to list-directed formating. Yes,
> programming errors do result from this terminology error, so it is more
> than just a pointless nitpick.

Here is the case from several years back, that made me distrustful. It
is something that Richard predicted, special character handling. I had
a config file like this:

item1 /data/dallured/precip
item2 99

Naively, I did this:

character name*80, value*80
read (10, *) name, value

The result was garbage in "value", i.e. uninitialized memory. Indeed I
find later that this is standard conformant! The standard says that a
"/" in the input stream terminates the current read operation, and
leaves the remainder of the input list unchanged. It is sensible for
certain applications, but a surprise as you say for me. Slash is only
one of several characters that come with a "gotcha".

So on the one hand Richard is correct that it is unfair to malign list
directed input generally, because of special cases. This is a case
where I had made assumptions about list directed input, and not bothered
to study the documentation.

On the other hand, the method has several surprises for the unwary. It
should always come with caveats and a referral to study the
documentation carefully before using it for reading strings.

When using "config files", sooner or later one is tempted to add string
values of increasing complexity for titles, paths, and so on. IMO it is
more robust to get in the practice of reading full lines of text with
'(a)' format and doing your own column division or parsing. I still use
list-directed input for well behaved files such as cleanly formatted
tables of numbers. But for config files that my user group will hack
on, full line input seems best.

--Dave
From: Richard Maine on 25 Sep 2009 15:02
Dave Allured <nospom(a)nospom.com> wrote:

> IMO it is
> more robust to get in the practice of reading full lines of text with
> '(a)' format and doing your own column division or parsing.

I agree, with both this practice and with the other material that I
elided from your post. This is what I usually do also. I just thought
the former critique of list-directed (including the implication that you
couldn't count on compilers to follow the standard) was a bit too broad.
I do agree about doing your own parsing being more robust; you can
certainly get better error handling that way.

> But for config files that my user group will hack
> on, full line input seems best.

Yep.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: Software for plotting in Fortranxx?
Next: INTRINSIC STATEMENT for functions overloaded for user defined types