(j3.2006) Defined operation questions

[Dick Hendrickson]

On Wed, May 9, 2012 at 12:26 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
>> 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.
>
In a way, it's worse than impossible.  Think about
          present(a)  .andthen.  (x+y)
there's a good chance that (x+y) will be evaluated before andthen(a,
x+y) is invoked.  To be useful, there'd have to be a set of rules or
conventions for using your andthen operator and they'd eventually
surprise someone.

Dick Hendrickson
>
>> 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.
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3