Re: Fortran Features
- From: "James Giles" <jamesgiles@xxxxxxxxxxxxxxxx>
- Date: Wed, 08 Feb 2006 04:01:01 GMT
Joe wrote:
A lot of people have ideas for Fortran features, judging by the
numerous vendor extensions, most of which never become part of the
standard. I assume that some reluctance to add features is to avoid
feature bloat. In any case, here are a few I would like.
Fortran has moved towards making user functions and subroutines have
more features of interinsic procedures. Along those lines, why not
make the CALL keyword optional for any subroutine that has been
prototyped with an INTERFACE?
I don't see what the one has to do with the other. Intrinsic
subroutines (there are a few) must be invoked with a CALL.
I like CALL better than just writing the procedure name.
How about supporting local-scope variables, like inside of DO/IF/etc.
blocks?
In languages that have these, few people use them and readers
find them confusing. On the assumption that no feature should
exist that doesn't make programs easier to read/verify/debug,
I'd say leave this out. (I have the feature in my own preprocessed
language and find it not nearly as useful as I expected. Now, if I
could block host association and import only those things I explicitly
want to use in the block, that might be useful.)
Text named line labels would be nice, even though modern code
minimizes the use of line labels.
I don't find text labels all that useful where we already have them.
Numeric labels (given a style rule requiring them to be in order)
help navagate the source code. Named labels require that you find
some useful mnemonic name for things. And these names don't tend
to be ordered (not that block labels could be ordered anyway - they
nest).
It would be nice to allow mixing of functions and subroutines in the
same generic type name. This is more useful with derived types, where
the unique areument type keeps things distinct.
Fortran can't resolve genericity based on the result type of a
function, but I see no reason that it couldn't resolve based on
the function/subroutine distinction.
Some user-defined type functions would be a lot easier to implement
with user-defined type coersion rules. For example, ISO_VARYING_STRING
implementations, would be much simpler for mixing CHAR and
VARYING_STRING procedures if you could define rules for converting
arguments among those types.
I don't get it. You mean like overloading CHAR so that it takes
an ISO_VARYING_STRING as an argument? You already can.
And, obviously you could write a function that takes a CHAR
and returns a VARYING_STRING.
Lastly, does it help to post such ideas to comp.lang.fortran, or does
one need to be on a Fortran committee to have any influence on the
language?
I don't think the committee is currently accepting feature
recommendations. I think all the ones they are presently
considering for F2008 were proposed by members. They
are neither interested in publicity about what they are working
on, nor in suggestions about what they should do instead.
--
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." -- C. A. R. Hoare
.
- Follow-Ups:
- Re: Fortran Features
- From: Ken Plotkin
- Re: Fortran Features
- From: Jan Vorbrüggen
- Re: Fortran Features
- References:
- Fortran Features
- From: Joe
- Fortran Features
- Prev by Date: Fortran Features
- Next by Date: Re: Code works with real but does not with double precision. Why??
- Previous by thread: Fortran Features
- Next by thread: Re: Fortran Features
- Index(es):
Relevant Pages
|
