Re: Fortran Features

David Flower <DavJFlower@xxxxxxx> wrote:

What I would like to see added is some protection for existing
extensions, so that they will not present problems with future versions
of FORTRAN.

I recall this exact same discussion before. That can't be done, even in
principle, without a specific list of extensions. You can do it for a
specific list, but there is no way to do it in general. Literally no
way. So you really need to debate the exact list of specific extensions
you want this for - not a generality like that.

Furthermore, note that what you are asking for is to standardize the
extensions in question. Just because they would be optional, that
doesn't mean they arent standardized. The current standard has features
that are optional to the compiler vendor (including some that I think
*EVERY* compiler vendor is going to implement, so I forget why they were
optional, but I digress).

In order to make the features optional like this, their full definition
will need to be included in the standard. You won't be able to get by
with "everybody knows what that syntax means, so just do it." You really
are talking about adding the features in question to the standard.
Whether you realize it or not, that is what you are asking for.

Which in turn, means that you get into a substantial debate on each
item. That doesn't mean you might not win some of them. But you will go
into the debate severely handicapped if you don't realize what you are
asking for, which is to add the features in quetsion to the standard,
possibly as optional features.

The sort of thing I mean is:

If you see the type INTEGER*4,

Ok. There's a specific feature. You can debate that specific feature,
but you need to debate it as the specific feature instead of as a "sort
of thing." Well, you can debate it any way that you want, but I offer
the advice that your chances are a lot better if you push for actual
specific features.

I don't think I'll take a strong position on this particular one either
way. I'm slightly against it, but not hugely so.

Most - darn close to all - current compilers do acccept this one anyway,
so I'm a little uncertain exactly what adding it would achieve. If you
are worried about future versions of the standard conflicting with this,
that just isn't going to happen; don't worry. There is no formal bar,
but there is just no way that something conflicting this would get a
majority vote. A motion to do something conflicting probably wouldn't
get a second... or even a first. That would upset a lot of people - more
so than having conflicts between versions of the standard on matters of
smaller import. Likewise, I can't imagine any compiler interpreting
integer*4 "incorrectly" unless there is darn good reason of the kind
that customers would also consider to be good enough reason to violate
the standard (perhaps reasons like "the machine doesn't support integers
that small, but I want my codes to try to run as is anyway").

So what concrete result would be achieved? Perhaps nothing other than a
formal form of countenance of the practice? That doesn't seem worth a
lot to me. I also don't see any big damage from doing it. So in the end,
this one wanders around in my category of "I wouldn't do it, but I don't
care a lot either way."

PS I am not au fait with the most recent standards, but can a start be
made towards producing standard IOSTAT values ?

There are 2 (I think just the 2) IOSTAT values that the f2003 standard
does something along this line for. Those are the two non-error ones -
end-of-file and end-of record. The numeric values are not standardized,
but there are standard paramater names for them (IOSTAT_END and
IOSTAT_EOR in the ISO_FORTRAN_ENV intrinsic module), which provides the
sorely needed functionality of portably being able to tell which one you
got.

The error ones have been debated, but the subject is very
controversial... so much so that it tends to be one of those subjects
that gets a reaction of "oh no, not that one again!" when it is raised.
I won't say that it couldn't happen - just be warned that this is one
that would take some significant pushing, partly because of a slippery
slope problem. People are reluctant to step even slightly on to the
slope. The problem is one of defining what the errors are. There is
substantial debate about what should and should not count as an error.
(I used to think this was "obvious"... until I found compilers that
disagreed with me.) And by most "reasonable" criteria, there turn out to
be a lot of them, which means a lot of work. One could specify only the
"important" ones, but it is easy to see a lot of time spent debating the
cutoff for that.

So I don't know what to say. I would personally find some cases of that
useful, but darned if I have good advice on how to proceed with selling
it... and to avoid turning it into a big enough mess that I wouldn't
support it either.

There is one feature of f2003 that can help hugely in some cases where
one might have wanted the iostat codes, and not at all in others. If you
want the iostat codes so as to have the program respond differently to
different kinds of errors, well... then this won't help any. But if you
want the iostat codes so that the program can give an error message that
is more helpful than "iostat value was 42; go look it up somewhere" then
the iomsg feature added in f2003 should help a lot. That feature gives
you a text error message. The details of the text are not specified in
the standard, but it is supposed to describe the problem. I have in the
past been known to disable my error handling just so that I can rerun a
program and have it print out the system error message (specifying
iostat at all keeps the sytem from printing its message); I found that
quite annoying.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.

Relevant Pages

  • Re: idea: on the issue of C and language extensions
    ... features; this route would be based mostly on something like a mailing ... implementations, yet far lighter weight and informal than forcing ... extensions they have done already... ... When parts of the Standard released by such a major organisation like ...
    (comp.std.c)
  • Re: Fortran Features
    ... In order to make the features optional like this, ... will need to be included in the standard. ... means that you get into a substantial debate on each ... one might have wanted the iostat codes, and not at all in others. ...
    (comp.lang.fortran)
  • Re: J3s workings
    ... If those features are adopted by several compilers, ... But how can we test out new features before standardizing them? ... I've no big problem with extensions for this purpose. ... be a big problem if the standard is different. ...
    (comp.lang.fortran)
  • Re: idea: on the issue of C and language extensions
    ... features; this route would be based mostly on something like a mailing ... The key problem would be in reaching an agreement on these extensions. ... When parts of the Standard released by such a major organisation like ... useful domain-specific and experimental implementations). ...
    (comp.std.c)
  • Re: WANTED: Volunteer to Scan Old Programs
    ... BASIC to the American National Standard for Minimal BASIC, ... Implementation-defined features ... Error and exception reporting ... of interpretation, and Section 5 for information peculiar to ...
    (comp.os.cpm)