FDIS
in [Fortran]
|
Prev: g95 and FFTW
Next: calling a c function
From: Dan Nagle on 22 Apr 2010 06:46 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
From: Tom Micevski on 23 Apr 2010 13:52 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). yep, it would be good if this "underscore problem" could be fixed - a possible solution could be to add this to the latex source file: \usepackage{lmodern} \usepackage[T1]{fontenc} \usepackage{textcomp} source: https://bugzilla.redhat.com/show_bug.cgi?id=153724
From: Uno on 23 Apr 2010 00:45 Dan Nagle 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. > I can't make the link work. Is this available to everyone who wants it? We've had crazy storms tonight in Albuquerque and many things are timing out. There were microbursts of snow and hail tonight leaving up to three inches of ice on roads, in localized pockets. In the house in which I was working, the whole thing was this huge hailstorm. A winter night in the rocky mountains. I'm going out to sing. -- Uno
From: Richard Maine on 23 Apr 2010 17:24 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > > >> I suppose it is related to its being obsolescent,... > >> Would it really have been hard > >> to allow ENTRY in internal subprograms? > > > Your supposition is correct. > > 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. A better example of what? I think you must have just snuck in another of those subject changes. I thought the subject of discussion was obsolecent features (as indicated by the small font), with the particular example in question being ENTRY. I'm not sure how the restriction against RECURSIVE in internal procedures is somehow a better example of anything along that line. Neither recursion nor internal procedures are obsolescent (or likely to become so). Furthermore, the restriction against recursive internal procedures was added for very specific reasons that have been discussed here before. One can (and people have) debated those reasons, but that seems like a question completely unrelated to anything in this thread so far. (Re)discuss that if you want. I don't think I'll participate in rehashing the same material. Mostly I'm puzzled as to what it is supposed to be a "better example" of that has anything to do with this thread. > > It would seem supremely silly to expand something at the same time as > > you are trying to remove it. If you want something else that I think actually *IS* related to the matter of simultaneously expanding something and making it obsolescent, look at statement functions. There are lots of what might look like arbitrary restrictions on statement functions. I can't imagine that anyone would add a new feature with such a peculiar set of restrictions. But then, that's not what happened. Instead, when statement functions were made obsolescent, the committee declined to simultaneously expand them to integrate with a lot of the "newfangled" f90 features. -- 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 19:46
Richard Maine <nospam(a)see.signature> wrote: (snip, I wrote) >> I suppose 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. > A better example of what? I think you must have just snuck in > another of those subject changes. I was using ENTRY as an example of what seems to be called non-orthogonality. According to one web page: "A programming language is orthogonal if its features can be used without thinking about how that usage will affect other features." The feature ENTRY and the feature internal subroutine are not orthogonal. Each can be used separately, but not together. > I thought the subject of discussion was obsolecent features (as > indicated by the small font), with the particular example in question > being ENTRY. I'm not sure how the restriction against RECURSIVE in > internal procedures is somehow a better example of anything along that > line. Neither recursion nor internal procedures are obsolescent (or > likely to become so). With, as I remember it, the example being ENTRY and internal subroutines. > Furthermore, the restriction against recursive internal procedures was > added for very specific reasons that have been discussed here before. > One can (and people have) debated those reasons, but that seems like a > question completely unrelated to anything in this thread so far. Good or not, it forces the programmer to choose between two useful features. > (Re)discuss that if you want. I don't think I'll participate in > rehashing the same material. Mostly I'm puzzled as to what it is > supposed to be a "better example" of that has anything to do with this > thread. >> > It would seem supremely silly to expand something at the >> > same time as you are trying to remove it. > If you want something else that I think actually *IS* related to the > matter of simultaneously expanding something and making it obsolescent, > look at statement functions. There are lots of what might look like > arbitrary restrictions on statement functions. I can't imagine that > anyone would add a new feature with such a peculiar set of restrictions. > But then, that's not what happened. Instead, when statement functions > were made obsolescent, the committee declined to simultaneously expand > them to integrate with a lot of the "newfangled" f90 features. Personally, I always liked statement functions, but mostly for very simple uses. For one example, converting between degrees and radians. (Well, the fix for that would be to add degree trig functions, but that isn't happening very fast.) That is, things too simple to be worth even in internal function, but that save some typing and make the program more readable. (Also, they are a little easier for compilers to inline than internal functions.) One feature that I might have thought could have been added to statement functions is array arguments, and the next might have been array return values. Many of the restrictions are on where statement functions and other declarations can be placed in the program. Mostly they make sense to me, but could also be considered as non-orthogonal. -- glen |