I'm in the middle of writing some comments for the 2008
public review, and I'd like some discussion on this one before
I submit it.

I don't see the value in having IMPURE ELEMENTAL procedures.
There are no examples in the draft standard and the only
example in the document describing new features can be
rewritten without the procedure being ELEMENTAL at all.
To be sure, other ways of calling the procedure are possible
but they are likely to be more confusing to the reader than
non-ELEMENTAL alternatives.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."

James Giles worldnet.att.net> wrote:

Well, basically whenever you want to do something elementally that
violates the rules for purity. It seems like every time you do almost
anything of consequence, you run into some reason why it isn't pure.
That has sure kept me from doing much with pure procedures. But some of
those things are handy to do elementally.

Now perhaps there might be arguments that some of the things in question
should be allowed in pure procedures, but that's a different matter.

1. I/O. At least for diagnostics. That's one I've heard some people say
should be allowed in pure procedures... but it isn't.

2. Saved variables. All kinds of reasons one sometimes wants those. If
it's a pure procedure, you can't have one.

Those are two "biggies" that come up a lot in practice. I'm sure there
are others, but those are the first two that I personally recall
hitting.

On Jul 1, 2:39 pm, "James Giles" worldnet.att.net> wrote:

Thank you for taking time to comment on the
Fortran 2008 draft. I hope more people will do
the same.

Bob Corbett

robert.corbett@sun.com wrote:

The time alloted expires Sunday as I recall the announcement.
I haven't decided whether to actually send in the comment
of this thread. I probably will since no one has yet given a
convincing example of a good IMPURE ELEMENTAL. But,
I'll give another day or two.

I may post some of my other public review comments here
as well. I would kind of like to see something that the committee
seldom does in the public review: what my high school English
teacher used to call "compare and contrast".

Hello,

On 2008-07-01 22:13:44 -0400, "James Giles" worldnet.att.net> said:

The time limits were set by ANSI, and had to be
exactly 30 days. J3 had no choice.

The SUN rep on J3, who volunteered to collect
and forward the comments, will certainly take
a comment on Monday. (Friday through Sunday
is a public holiday weekend here in the USA.)

On Jul 2, 2:47 am, Dan Nagle verizon.net> wrote:

Thirty days is a short time to review a draft the size of
the Fortran 2008 CD. Nonetheless, in my case having more
time would not make a difference. I have already spent
more time on the review than my masters like.

Bob Corbett

Hello,

On 2008-07-02 07:19:20 -0400, robert.corbett@sun.com said:

I have been posting in this newsgroup
and in other public forums how to get a copy of the CD,
and suggesting that interested parties start reading it,
ever since the Editor made it available in March.
So you had something more like 90 days to read it,
before the comment period even started.

Others have posted public notices also.

The 30-day period is the duration J3 is allowed
to accept comments, not the time available for study.
That is the only part set by ANSI (to be fair).

This schedule was determined at J3's February meeting,
to allow the most time for study of the CD before comments
were received.

In article <1ijen7s.nzkpiyv3cgm8N%%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes:

In this case, I think a compiler option might make more sense, with some
sort of comment-prefix (!$DIAG or whatever) which would be ignored with
the standard settings, as a comment allows the code to be completely
standard and when the diagnostics are needed this line is executed even
if /STANDARD=(STRICT,FULL) or whatever is activated.