Re: Language features worth proposing
- From: "David Flower" <DavJFlower@xxxxxxx>
- Date: 20 Jul 2006 02:27:36 -0700
Joe Krahn wrote:
Now that I've finally seen the first F2008 draft, I can make more
informed feature proposals. Maybe an interested committee member can
discuss it at the next meeting.
1) Control of host association through an expanded IMPORT statement (or
similar). This seems likely to have enough obscure issues not to make it
into F2008 even if it is viewed positively.
2) Some directive to disallow implicit external procedures. As discussed
before, the word EXTERNAL has been misused, so defining the statement's
name is not so easy. The intent here is not to prohibit implicit
interfaces, but to require that any called procedure must be declared in
some way. The worst scenario is an external procedure with F90 data
types, where the procedure definition was not included, and the
arguments get passed wrong. This seems useful and probably not so many
'issues'. But, one could argue that a compiler flag to do this is
sufficient.
3) CHARACTER() intrinsic to convert strings. This has been avoided
partly because string conversion is 'fuzzy'. But, for this reason, an
intrinsic procedure has a decent chance of utilizing platform-specific
definitions for this fuzzy conversion. It is not enough to use CHAR()
for character-wise conversions, because some strings might have
mutli-byte sequences, and there are many cases where a double-character
can replace a single special character. Even a simple string might have
UTF-8 sequences when using ISO_C_BINDING. The definition is easy if the
conversion is processor-dependent for all non-standard kinds, and a
simple character-wise conversion for the standard kinds.
4) More uniformity of executable block constructs and their associated
statement form. Making them more uniform should actually reduce syntax
complexity in some ways, while getting a few features. Some things may
be straightforward, some may have some non-obvious caveats. Perhaps all
to complicated to discuss at this stage.
a) Why not have a statement form for all of them? For example:
associate(i=>...long reference...) i=i+1
b) Why not support EXIT to leave the current block for all block
constructs? The benefits are equally valid as in a DO block.
Caveat: 'EXIT IF' could conflict with a DO loop named 'IF'.
c) Why do all the new constructs not support a label form, while DO
has some fairly messed up rules for label forms. Arithmetic-IF and
computed-GOTO have been phased out, but DO shows no signs of
improvement. Can't we at least phase out the inner/outer stuff
from do loops with both a label and an end-do?
5) A self-describing INTERFACE should be valid, if it matches the
procedure's actual interface. This is the best way to ensure accurate
prototypes with external procedures. At least one compiler supports this
now as an extension.
6) Support allocate-on-write for internal writes to an unallocated
character string. Fairly simple and a big help in a few cases.
Enough for now...
Joe Krahn
I suspect that most contributions to this thread will be suggestions
for some pet feature to be added.
Now, the main reason for a standard is to facilitate dealing with
different compilers
and/or computers. Whilst additional features added by various compiler
writers are often useful, and frequently necessary, they are often a
headache when it comes to transferring a program to a different
environment.
My suggestion is that this problem be partially addressed in any new
standard, by looking at commonly implemented extensions, and stating
approximately:
- If they appear in any program, they must implemented as such, or not
at all
- If not implemented, the compiler must respond with a helpful
message.
In the case that several compilers implement the same extension with
different syntax, a standard syntax could be specified. An example
would be a format for an instruction to the compiler to implement
bounds checking.
Dave Flower
.
- References:
- Language features worth proposing
- From: Joe Krahn
- Language features worth proposing
- Prev by Date: Re: Segmentation Fault without write?
- Next by Date: Re: Segmentation Fault without write?
- Previous by thread: Re: Language features worth proposing
- Next by thread: Re: recl on g95 and gfortran
- Index(es):
Relevant Pages
|
