[J3] Elemental and optional arguments

[José Rui Faustino de Sousa]

Dear John,

First of all thank you very much for kindly taking the time to answer my 
questions.

On 27/06/21 10:17, John Reid wrote:
> The standard has no concept of  "graphically present".  15.5.2.12 
> defines the meaning of "present" and uses it.
> 

Maybe "textually present" would have been a better choice of words, but 
that AFAIK is not defined in the standard either.

Anyway what I meant to distinguish was "call foo()" and "call foo(a)" 
were "a" would be considered absent under 15.5.2.12.

 From what I understood of past J3 list discussions these two situations 
are to be considered distinct.

>> First of all I am assuming that all the issues raised by elemental 
>> procedures must be resolved at compile time, except for the extents 
>> which may only be known at runtime. Although I don't think this is 
>> explicitly stated in the standard it is a core characteristic of the 
>> language.
> 
> No, we can get runtime errors here.
 >

Yes, but only bounds mismatches. Did you have something else in mind?

>>
>> Second I am assuming that there are two perspectives to actual 
>> argument presence, in the sense of 15.5.2.12. The perspective from the 
>> procedure which has an optional argument, which cannot know why an 
>> argument is not present, and the perspective from the subprogram which 
>> makes the procedure reference, which knows if the argument is 
>> graphically present or not.
>>
>> (I understand 15.5.2.12.3 (6) to apply only in the first perspective.)
> 
> I do not recognize your idea of "perspective". Whether a dummy argument 
> is present is defined by 12.5.2.12. 15.5.2.12.3 (6) refers to an 
> optional argument of the procedure that is calling the elemental procedure.
 >

I am trying to distinguish two different situations.

First, a procedure passing an optional dummy argument, which is my 
understanding that the whole 15.5.2.12.3 applies to.

Second, a subprogram passing an allocatable or pointer variable, which 
may only be known if it is present or not, under 15.5.2.12, at runtime.

>>
>> A corollary of these two assumptions would be that shape conformance 
>> of graphically present actual arguments is mandatory, without regard 
>> to presence in the sense of 15.5.2.12, and reduces to rank matching.
> 
> No.
 >

Then I fail to see how something like "call foo(a, b)" were "a" and "b" 
are allocatable or pointer (not optional dummy) variables which have 
different ranks would be known to be legal, and how to scalarize it, at 
compile time.

Could you elaborate a little?

>>
>> Third, although AFAIK this is not stated anywhere, I am assuming that 
>> what the standard is trying to enforce is that, at compile time, it 
>> must be possible to know if a reference to an elemental procedure will 
>> be an elemental reference, which will need scalarization, or a 
>> "normal" scalar procedure reference.
> 
> Yes. If an array argument is absent, another array argument must be 
> present, see  15.5.2.12.3 (6).
>>

But if 15.5.2.12.3 (6) only applies to procedures passing a dummy 
optional argument it can not be invoked in general.

Or at least I do not understand how it can be invoked in the second 
situation above.

>> As an illustration I add a small program:
>>
>> program emess_p
>>
>>   implicit none
>>
>>   integer            :: i
>>   integer, parameter :: n = 11
>>   integer, parameter :: u(*) = [(i, i=1,n)]
>>
>>   integer, allocatable :: a(:)
>>   integer              :: b(n)
>>   integer              :: cnt
>>
>>   cnt = 0
>>   b = efun()
>>   if(any(b/=1)) stop 1
>>   if(cnt/=1) stop 2
>>   cnt = 0
>>   ! In principle it is only possible to know if a is present at runtime,
>>   ! so this is most likely illegal. Although I don't know why has I
>>   ! don't think 15.5.2.12.3 (6) applies here.
>>   b = efun(a)
> 
> You have a runtime error here because a is not allocated and therefore 
> regarded as absent.
> 

But then I fail to see how "b = efun(a)" should be any different from "b 
= efun()" and why an error should be issued at all.

Once again thank you very much.

Best regards,
José Rui