I hope not, but people may get an unedited test version
of this message. First real work on a Sunday ...
Aleksandar Donev ([log in to unmask]) wrote:
> James Giles wrote:
>> It's when working on this kind of thing that the
>> weaknesses of not having just NONKIND appears most vividly.
> Maybe, but there is a strong argument the other way. How about a type
> parameter which is itself a type (think genericity). Is this a KIND
> parameter, or a NONKIND? [...]
Depends. Can you resolve which specific routine to call when
calling a F95 style generic name based upon that type parameter?
If you can, then it's a KIND parameter. If you can't, then it isn't.
That's the extent of the distinction. (My "inferred" variable idea
for specifying generic interfaces gets rid of the necessity for even
that distinction, but only in true generics, not the F90 style ad-hoc
genericity. I still need to read Aleks' generic proposal. I suspect
I'll have to write my own counter-proposal.)
What information is carried by these keywords in the first place?
Obviously, they all indicate that the names being declared are
type parameters (a fact that can easily be seen by their appearance
in the type name's declaration, but perhaps it's useful to reinforce
that). In the F95 style generic resolution system, they distinguish
between which type parameters are used to resolve to specific
procedures and which type parameters are not, as I described
above. But, what other useful information is carried by any
additional names? I can't think of any.
All such type parameters themselves have a type, so there's no
reason to require a different keyword to carry the "type parameter"
concept when declaring one to be REAL, or CHARACTER, or
LOGICAL, or COMPLEX, or even a derived type. They are all
still either used to resolve generic calls into specific names or
they aren't. KIND or non-KIND still seems sufficient. Even a
type parameter of type TYPE still has that basic distinction and
no others.
Again, in Dan Nagle's proposal, in what way are SCALE parameters
different from LEN parameters? They are of type REAL, but that's
visible in the same declaration. Otherwise, they have the same
properties are LEN parameters. I think he should have just used the
LEN attribute. It would look strange, but it wouldn't lead users
to wonder if it implied any different rules than apply to LEN
parameters. Similarly, other than the fact that STRING parameters
are CHARACTER, what is their difference from LEN parameters?
I claim: none. Dan should have used LEN as the attribute there too.
And, suppose in the future that you *do* come up with a significant
distinction that actually requires a different attribute name. If you
have a bunch of different names already that *don't* express anything
significant, you will have set a trap for anwary, or just weary,
programmers who will believe that all these (except KIND) really
have the same properties. Programmers will have already adopted
the attitude that these various attribute names don't really mean
anything different.
Of course, the change from NONKIND to LEN was accomplished
as (supposedly) an edit. The document *can* still be edited. I think
the change should be reversed.
--
J. Giles
|