(j3.2006) Defined operation questions

[Malcolm Cohen]

>Does anybody remember why "nonoptional" is required for dummy arguments of 
>functions that define operations (12.4.3.4.2p1)?

I think it is just to avoid confusion.  Operations are meant to be algebra-like, 
not procedure-like.  Downgrading operations into "funny syntax for procedure 
references" makes it harder to read programs - as it was there was resistance to 
the idea of defined operations with all their requirements ("people won't know 
what + means").

>I tried to write an .ANDTHEN. operator

You are attempting the impossible.  Fortran doesn't have "special forms" unless 
you consider the PRESENT intrinsic to be a special form, and then only for that. 
Wanting to have a special form for conditional con/disjunction is a separate 
issue from operator syntax and generic resolution.  And failed to muster 
sufficient support last time around.

>so that I could do something like "if ( present(A) .ANDTHEN. A )...", in which 
>the function that defines .ANDTHEN. returns false without referencing the 
>second argument if the first argument is false.

In this case why not just write the PRESENT_AND_TRUE function that takes an 
optional logical and returns true iff it is present and true?  Or the BOTH_TRUE 
function?  Operator syntax is very attractive for algebraic functionality, but I 
don't see what is so attractive about it otherwise: you can't have numbers or 
underscores in the names, and due to the priority they often need parenthesising 
thus making them longer than plain procedure references, viz ((op1).NAME.(op2)) 
vs. NAME(op1,op2).

>In light of the first distinguishing characteristic in 12.4.3.4.5p3, is there 
>still a reason for "data object" in (12.4.3.4.2p1)?

I don't think generic resolution has anything to do with it.

>I can't offhand think of an application for a defined operation in which one 
>operand is a procedure, but there appears not to be a problem with generic 
>resolution.

We should be providing facilities that there is a genuine need (and desire) for, 
not just facilities that we think we don't have any problem with one aspect 
thereof.  All new features should start with -100 points.

In this case, creating a data type with a procedure pointer component and 
providing operations for that type is possible, and is already supported since 
F2003.  That seems to satisfy the functionality without adding the potential 
confusion of bare procedure designators in operator syntax.

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