Prev: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard
Next: handling large character arrays
From: FX on 22 Apr 2010 10:15
> Kudos to Malcolm Cohen of NAG who, as project editor,
> did a fine job of producing the document.

But you still can't search for strings containing an underscore (e.g.
COMPILER_VERSION) using standard software (Adobe products, Mac PDF
viewer, linux's xpdf).

--
FX
From: GaryScott on 22 Apr 2010 10:22
On Apr 22, 5:46 am, Dan Nagle <danna...(a)verizon.net> wrote:
> Hello,
>
> The FDIS (Final Draft International Standard)
> of Fortran 2008 is available from WG5's ftp server,
> maintained by NAG (thanks!) at
>
> ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1826.pdf
>
> It's about 8 MB.
>
> There are very small changes with the previous draft,
> repairs to typos and so on.
>
> Kudos to Malcolm Cohen of NAG who, as project editor,
> did a fine job of producing the document.
>
> If you wish to inform your country's vote on the FDIS,
> you should read the document.  It is identical
> with the standard to be published, except that ISO
> will change the document title to reflect the change
> in status when it is published.
>
> --
> Cheers!
>
> Dan Nagle

Perhaps it is intentional to set off changes. There are a number of
places where the font size changes to an extra small font (even mid
sentence). Examples at bottom of page 277.
From: Georg Bauhaus on 22 Apr 2010 10:44
On 22.04.10 16:15, FX wrote:
>> Kudos to Malcolm Cohen of NAG who, as project editor,
>> did a fine job of producing the document.
>
> But you still can't search for strings containing an underscore (e.g.
> COMPILER_VERSION) using standard software (Adobe products, Mac PDF
> viewer, linux's xpdf).

For Mac PDF viewer, typing "COMPILER VERSION" (with quotes and space)
is a workaround.

I noticed that in typewriter style screens, the underscore works,
i.e. search will find it, e.g. NAME_LENGTH.
(I guess it has to do with the TeX character category being
different there.)
From: Richard Maine on 22 Apr 2010 11:04
GaryScott <garylscott(a)sbcglobal.net> wrote:

> On Apr 22, 5:46 am, Dan Nagle <danna...(a)verizon.net> wrote:

> > The FDIS (Final Draft International Standard)
> > of Fortran 2008 is available from WG5's ftp server,

> Perhaps it is intentional to set off changes. There are a number of
> places where the font size changes to an extra small font (even mid
> sentence). Examples at bottom of page 277.

Not changes. In f95, that was to indicate obsolescemt features. I assume
the same convension is used.... Let's see... Yep. See 1.4.5, Text
conventions

"The descriptions of obsolescent features appear in a smaller type
size."

Yes, it sometimes applies to only part of a sentence. For example, the
ENTRY statement is obsolescent, so those things on pg 277 that refer to
ENTRY statements are in the small font. Sometimes that is only part of a
sentence, as in the list of differences between an internal subprogram
and an external one; one of those differences is that internal ones
camn't have ENTRY statements.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 23 Apr 2010 16:53
Richard Maine <nospam(a)see.signature> wrote:
> glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

>> I suppose it is related to its being obsolescent, but otherwise
>> it seems to propagate the Fortran tradition of being restrictive
>> even when it isn't necessary. Well, many restrictions were in
>> early compilers for size reasons. Would it really have been hard
>> to allow ENTRY in internal subprograms?

> I doubt it would have been hard. But that seems irrelevant. I frankly
> haven't even thought about whether it would be hard because it doesn't
> matter. Entry is a mess already. I'd be against anything that would
> encourage new code to be written with it.

> Your supposition is correct.

I haven't written any with ENTRY for a long time, but I have
worked on programs written by others using ENTRY. Most of the
time you don't need it, but there are a few times when it is
nice to have.

I suppsoe RECURSIVE would be a better example, also restricted
from internal subroutines. But note that the restriction also
stops one from using old code with ENTRY as an internal subroutine.

> It would seem supremely silly to expand something at the same time as
> you are trying to remove it. The obsolescent tag for a feature means
> that there is at least thought of removing it. (Whether that is likely
> to actually happen is a separate subject). The odds of your
> simultaneously convincing the committee that something should be listed
> as obsolescent and should also be expanded seem negligable. If you
> manage to make a sufficiently convincing argument for one of those
> positions, it would probably be an even stronger argument against the
> other.

The point of the comment was to be more general, but it depends
on what order things were done in. If it was:

1) Add internal subroutines.

2) Oops, remove the ability to use ENTRY in internal subroutines.

OK, a different example, REAL variables in DO loops.
If I remember right, added in F77, and removed, not just obsolescent,
in later standards. Now, there are some problems that can occur
when using REAL variables in loops, and as usual it is up to the
programmer to do it right, but otherwise it looks like an arbitrary
restriction. Other languages with looping statements that I have
used don't have such a restriction.

> "It wouldn't be hard to do" is nowhere near being an adequately
> convincing argument for adding a new language feature.

It would be interesting to have the whole list of features allowed
in external subroutines, but not internal subroutines.

I presume, though, that all the features of external subroutines
were not added one at a time to the allowed features of internal
subroutines.

-- glen
 |  Next  |  Last
Pages: 1 2
Prev: XLF V13.1 release for AIX -- fully compliant Fortran 2003 standard
Next: handling large character arrays