Re: Language features worth proposing


David Flower wrote:
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

My apologies if this has already been proposed, as I am unfamiliar with
standards more modern than F90.

Could serious consideration be given to the handling of multiple
processes. Including, but not to the exclusion of anything else:

- Intrinsics to start and stop other processes

- Shared memory


Those items represent some of the truly needed functionality. I would
weigh these items far higher than any other type of syntax tweaking.
Dave Flower

.

Relevant Pages

  • Proposal: String::Format::General
    ... It provides format string parsing and output assembly, you provide the code that implements the individual conversion characters. ... Format syntax is kind of a cross between sprintf and strftime, but how close it is to each of these depends on the semantics implemented by the user. ... Note that the following is pre-alpha documentation; the interface to the output conversion code has changed since yesterday, ... conversion character, and contain a number of optional fields which may ...
    (comp.lang.perl.modules)
  • Re: what if (f)printf returns EINTR ?
    ... vsnprintf - formatted output conversion ... int fprintf; ... write to the character string str. ...
    (comp.unix.programmer)
  • Re: Language features worth proposing
    ... Some directive to disallow implicit external procedures. ... CHARACTER() intrinsic to convert strings. ... partly because string conversion is 'fuzzy'. ...
    (comp.lang.fortran)
  • Language features worth proposing
    ... 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 CHARfor 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. ... This is the best way to ensure accurate prototypes with external procedures. ...
    (comp.lang.fortran)