Le 05/10/2022 à 23:40, Harald Anlauf a écrit :
There is one last thing that I'm dissatisfied with.
The handling of unknown types should be moved to reduce_binary, because
the dispatching in reduce_binary doesn't handle EXPR_OP, so even if
either or both operands are scalar, they are handled by the (array vs
array) reduce_binary_aa function. That's confusing.
Thinking about it again, I'm not sure my suggestion is right here.
Do you have an example?
No. Actually, I think it works, but a weird way.
For example, for this case:
[real :: 2] * [real :: +(.true.)]
First there is a "root" invocation of reduce binary with arguments [real
:: 2] and [real :: +(.true.)]
The root invocation of reduce_binary will call reduce_binary_aa. This is
normal.
Then reduce_binary_aa calls reduce_binary again with arguments 2 and
+(.true.). And reduce_binary calls again reduce_binary_aa with those
arguments. This is weird, reduce_binary_aa is supposed to have arrays
for both arguments.
The same goes for the array vs constant case, reduce_binary_ca (or
reduce_binary_ac) is invoked with two scalars, while if you look at
reduce_binary, you would expect that we only get to reduce_binary_ca
with a scalar constant and an array as arguments.
I think the checks in the three reduce_binary_* functions should be
moved into their respective loops, so that we detect the invalid type
just before these weird recursive calls instead of just after entering
into them.
OK with that change.
