James Giles wrote:
> [log in to unmask] wrote:
> ...
> > OTOH, we could extend the syntax of the kind thing-o in a literal to
> > allow initialization expressions instead of names. One could then write
> > something such as 0.1_real_kinds(1) to get default real and
> > 0.1_real_kinds(2) to get double precision.
>
> I really dislike that one. This thread began with the observation
> that literals with KIND specifiers are illegible and error-prone
> and now has lead to an extension of that very feature which is less
> legible and more error-prone. Tragic irony?
The key word is ALLOW. Notice it doesn't say REQUIRE.
Maybe the middle part of the discussion got lost. Follow the chain of
logic and say where it went off the rails: If a provision is made to
specify the kind of literal constants that aren't decorated with a kind
specifier, how do you then get default kind? In 04-121 Dan proposed
arrays of kind parameters in ISO_FORTRAN_ENV for logical and character
kinds. This is trivial and clearly useful. An obvious generalization is
to provide such arrays for all kinds. An obvious provision is that the
(1) element in each array is the default kind. To get the default kind
for a literal, as opposed to what-you-get-if-you-don't-say-anything, there
are at least three solutions that start with Dan's reasonable and useful
proposal:
1. The standard also specifies scalar named constants for the four default
kinds (and for double precision real) in ISO_FORTRAN_ENV,
2. The standard allows initialization expressions for kind specifiers in
literals (actually, <primary> would be better), or
3. Expect the user to invent scalar names and give them values in named-
constant declarations.
I don't like #1 because I don't like duplication. I prefer generalization.
Between #2 and #3, I prefer #2. Consider:
use ISO_FORTRAN_ENV, only: REAL_KINDS
x = 0.1_real_kinds(1)
or
use ISO_FORTRAN_ENV, only: REAL_KINDS
integer, parameter :: DRK = real_kinds(1)
x = 0.1_drk
If I were to have several constants that need to be of kind real_kinds(1),
as opposed to what-you-get-if-you-don't-say-anything, I would do the latter.
With only one, I would find it convenient to be allowed to do the former.
If the kind specifier were extended to allow primaries instead of just
digit strings and names, nobody would thereby be REQUIRED to use complicated
designators. Digit strings and names would remain special cases of primaries.
Not liking a syntax that you wouldn't use anyway, i.e. you'd use the
alternative, doesn't strike me as a good reason to deprive everybody
else of the opportunity to use it. It is a good argument against a
proposal that leaves no alternative but the one that is considered to be
ugly or misleading. But I didn't propose to require using more general
kind specifiers in literals -- only to allow them.
I can't speak for vendors, but if there's no syntax ambiguity (and I
don't think there would be), it may well be easier to allow primaries
than to restrict kind specifiers to digit strings and names. The
constant-with-kind-specifier may now be a lexical entity, but would
almost certainly become a parser entity -- a subtree in the way I do
things. I would reference the "primary" production (if LR) or the
"primary" procedure (if recursive descent). My tree walker would use
"primary" or "primary in an initialization expression" to get the value
from the symbol table. I don't think there's another place in the
language where only a digit string or a name is allowed; if so, I
wouldn't have procedures for that in the lexer, parser or type checker/
generator.
--
Van Snyder | What fraction of Americans believe
[log in to unmask] | Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or disapproved
by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.
|