(j3.2006) (SC22WG5.4364) [ukfortran] Fwd: WG5 informal ballot reInterop. TR

[Malcolm Cohen]

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 
one.

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 
characteristic.

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
>TYPE(*).

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 
be relevant.

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 
very interoperable
  TYPE(*) no declared type, any dynamic type, many restrictions on use, 
interoperable

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 
use it.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.