(j3.2006) (SC22WG5.4364) [ukfortran] Fwd: WG5 informal ballot reInterop. TR
Thu Dec 2 04:42:07 EST 2010
Aleksandar Donev wrote:
>On 11/30/2010 10:11 PM, Malcolm Cohen wrote:
>>> E) Re UTI 1: I do not like "unlimited polymorphic", and in fact
>>> strongly prefer that it me made very clear assumed type has nothing to
>>> do with unlimited polymorphic. But the standardese may need some more
>>> work than I have time for.
>> But it *is* unlimited polymorphic.
>Well, sure, since you have defined it.
No, I am using the normal meaning of the words.
> Polymorphic should mean an object that can have different dynamic types.
Precisely the case here.
>Assumed-type objects should be classified as having no type.
Absolutely not. If it has no dynamic type, well then it can't be associated
with an integer. Or a real. Or any other data object for that matter. The
whole point of ***ASSUMED-TYPE*** is that it ASSUMES THE TYPE.
>it requires more work to invent this new kind of untyped objected, but I
>think it is important,
I prefer not to introduce semantic nonsense into the standard.
Not liking the word "polymorphic" is not a technical reason, let alone a good
TYPE(*) is just like CLASS(*), only the compiler doesn't pass the type
information around so that job is left up to the programmer to take care of.
Without compiler-supported type info it can't be type-enquired (but then,
CLASS(*) cannot always be type-enquired successfully either, e.g. when it is
associated with a SEQUENCE type object) or have its value copied, etc.. But it
has the full association capabilities of CLASS(*), indeed that is its defining
Bill Long wrote:
>That opens a can of worms because the standard is littered with
>statements like "If MOLD is unlimited polymorphic ...". In all of these
>cases, we mean something declared CLASS(*), and not something declared
And in many of those cases either TYPE(*) is fine, or TYPE(*) is already
prohibited by other wording.
> In other words, the current standard uses "unlimited
>polymorphic" as a synonym for "declared CLASS(*)".
Well, in F2008 only CLASS(*) is unlimited polymorphic. Adding another category
of unlimited polymorphism, with somewhat different capabilities, is going to be
tricky to incorporate however we do it.
>The consequences are
>that (1) readers assume they are the same,
I have approximately zero sympathy for this case - we are adding a second
unlimited polymorphic thingo, whether we choose to call it that or use some
different more weaselly words. Using more weaselly words generally just makes
technical problems harder to spot, it doesn't remove any Technical Problems (as
opposed to Wording Problems, see next).
> and (2) going back and
>changing all of these statements to exclude TYPE(*) seems like more work
>that just avoiding the association of TYPE(*) with the term 'unlimited
>polymorphic' in the first place.
I have a lot more sympathy for this. In any case, adding TYPE(*) is a big deal
as far as the standard goes and careful scrutiny of the wording and technical
interactions will be required. Whether we choose to reuse the "unlimited
polymorphic" term or not, nearly every occurrence of unlimited polymorphic will
bear examination to see whether TYPE(*) is relevant, or indeed whether it should
Furthermore, there are also a whole bunch of places where we currently say
unlimited polymorphic and we do want that to apply to TYPE(*), so if we call it
something different then we need to edit all of *those* places! (This is why I
suggested using the term in the first place.)
At the end of the day, what we have is
CLASS(*): no declared type, any dynamic type, few restrictions on use, not
TYPE(*) no declared type, any dynamic type, many restrictions on use,
IMO there is no better description for the declared/dynamic type parts of that
than "unlimited polymorphic". Unless the wording problems using the term would
introduce are greater than the wording simplicity it allows elsewhere, we should
................................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3