Re: CLASS Terminology
- From: nospam@xxxxxxxxxxxxx (Richard Maine)
- Date: Sun, 30 Nov 2008 09:49:32 -0800
George <george@xxxxxxxxxxxxxxx> wrote:
in _Fortran 2003_:....
pg 119
5) A type declaration with the TYPE keyword must not specify a derived type
that is defined later in the same scoping unit.
An interesting short paragraph follows on the same page.
Item 5 above is a bit inconsistent in that it does not
apply to type declarations with the CLASS keyword and is
more stringent than similar restrictions on component
declarations.
I find it unusual for this text to describe its own enumerated rules as " a
bit inconsistent."
You appear to be confusing the Fortran 2003 standard with the Fortran
2003 Handbook. Although the authors of the later certainly hope there is
a strong relationship, they are by no means the same thing. Your
citation as "_Fortran 2003_" has the surface appearance of referring to
the Fortran 2003 standard - at least that's how I'd interpret such a
citation style, except that I know the cited material enough to know
better.
Now reread the material in the proper context of being in a book about
the Fortran standard rather than being the Fortran standard itself. Does
it now seem less unusual? Well, if that isn't enough hint, I guess it is
time for the answers (which aren't in the back of the book). The
enumerated rules are there because those are the rules of the standard.
This is the authors of the Handbook commenting on something that they
find a bit inconsistent in the standard. That's a bit different from the
book commenting that it is inconsistent itself.
It is perhaps more simillar to your own posting. Note that your own
posting includes the above words and then says you find it unusual. Does
that mean you find your own posting unusual since the words in question
are in your posting? Or is it different because your posting just quotes
the words from something else in order to comment on them? By the way,
those questions are intended to be only rhetorical, illustrating that
there is a difference between a text saying that it is inconsistent
itself versus saying that something it quotes is inconsistent.
I'll note that there was a bit of discussion among its authors about how
the Handbook should present such things. The Handbook is intended
primarily as a presentation of fact about what the standard says rather
than as a critique. A such, there is at least some argument for just
presenting the facts, without commenting at all about what the Handbook
authors might think are oddities. Let the reader draw his/her own
conclusions about what is odd. In this case, we judged, as I recall,
that pointing out the inconsistency helped explain the facts. Without
some such mention, I would have been concerned that a reader might be
unsure whether he/she was reading things correctly.
We did adopt the words quoted above as a fairly low-key middle ground
between saying nothing versus saying that this was an oversight that
should be fixed. I happen to believe the later, but we didn't have to
say it that way in the book. I think a fix for this is in f2008. Anyway,
I recall one as being proposed and I don't recall it as being horribly
controversial, so I suspect it went through.
My interest in the next standard will begin when I have a
compiler from *not the last one,* but the one before.
Which sounds very simillar to the point I made in my one formal comment
on the f2008 draft.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
.
- References:
- CLASS Terminology
- From: Gary Scott
- Re: CLASS Terminology
- From: Damian
- Re: CLASS Terminology
- From: George
- CLASS Terminology
- Prev by Date: Re: PROCEDURE with implicit interface as actual argument
- Next by Date: Re: Threads [was Re: Final Procedure]
- Previous by thread: Re: CLASS Terminology
- Next by thread: PROCEDURE with implicit interface as actual argument
- Index(es):
Relevant Pages
|
