[J3] [EXTERNAL] UTI 13 and 14

[Malcolm Cohen]

And there is of course normative text, the NOTE is only there to make sure people understood the normative text. Doesn’t work if people do not even read the normative text though!

 

TYPEOF and CLASSOF specify the same type and type parameter values as the declared type and type para

meter values of data-ref , except that they specify that a type parameter is deferred if it is deferred in data-ref .

 

Note carefully: they do *NOT* specify the same type parameters, they specify the same type parameter *VALUES*. That is anything that evaluates to 123 specifies the type parameter *value* 123, it does not specify the *expression* (or “*”) that got evaluated.

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Clune, Thomas L. (GSFC-6101) via J3
Sent: Saturday, October 10, 2020 4:38 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov>
Subject: Re: [J3] [EXTERNAL] UTI 13 and 14

 

Hi Wililam, 

 

Certainly notes are only informative, though you can safely assume that the committee’s intent was that such notes are implied from the constrants and rules.    The UTI’s are indicative of the fact that some corner cases were not properly addressed, and now is the time to do so.

 

UTI-013 points out that assumed KIND and LEN parameters are fundamentally unknowable for OPTIONAL arguments.    UTI-014 is a bit more esoteric and is concerned with inconsistent statements about what it would mean if we allowed CLASSOF() with unlimited entities.   As such, I think only UTI-013 is relevant to your concerns.

 

As new features, we have some latitude in defining just what should happen in corner cases.    Consider the following examples:

 

SUBROUTINE SUB1(S1, S2)

   CHARACTER(LEN=*), OPTIONAL, INTENT(OUT) :: S2

   TYPEOF(S1), INTENT(IN) :: S1

   …

 

END SUBROUTINE SUB1

 

SUBROUTINE SUB2(S1)

   CHARACTER(LEN=*), INTENT(IN) :: S1

 

   TYPEOF(S1), INTENT(IN) :: LOCAL

   …

 

END SUBROUTINE SUB2

 

If I have understood correctly, you would want TYPEOF in SUB1 to be equivalent to “CHARACTER(LEN=*)”.      But how would you want to interpret it is the SUB2 example.    We would either need to disallow data-ref’s that have assumed type parameters when declaring local variables,  or the semantics would need to be different for non-dummy declarations.    I believe the proposers' intent, and certainly mine, was that we would allow the SUB2 use case, and that it would work because the type parameters are not assumed for LOCAL but rathre established by the rules for S1.    But I did also not fully consider OPTIONAL at the time.

 

I think the wording C710 is intended to imply that the type parameters are not assumed.   I’m hardly the standardese expert,  but presumably the phrase “estabilshed by the implicit typing rules” is meant as opposed to being assumed.    Possibly that wording can/should be improved as part of dealing with this UTI.    (I defer to Malcolm on what the words need to be in order to tie this down.)

 

Give the choice of (a) allowing SUB1 but not SUB2,  (b) allowing SUB2 but not SUB1, or (c) a more complex wording that would allow both, which would be your preference?   I’m not strongly wed to any, but generally prefer option (b).

 

Cheers,

 

- Tom

 

 

 





On Oct 9, 2020, at 2:39 PM, William Clodius via J3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> > wrote:

 

As near as I can tell UTI-13 and 14 appear b because of the constraint mentioned in Note 2, "if the data-ref has an assumed type parameter, the entities declared have the same values for that type parameter as data-ref, they are not assumed (even if they are dummy arguments).” Now the explicit constraints on TYPEOF and CLASSOF are C709-712. My interpretation of those constraints is that they would allow the entities to have assumed parameters that need not be the same as data-ref. I find no other text outside the note and constraints affecting the interpretation of TYPEOF and CLASSOF. If I am right Note 2 is not just informative, but also has technical impact, which I thought was not allowed. Am I not interpreting C709-C712 correctly? Have I missed some additional text? Is a note allowed to have technical impact? Should there be an additional text outside the Note giving the interpretation currently specified by Note 2?

 

 

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our Privacy Notice <https://www.nag.co.uk/content/privacy-notice>  for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20201010/f5cc6ebe/attachment.htm>