[J3] Conditional expressions using intrinsic function

[Robert Corbett]

 Thank you.

The ? approach is very similar to my CONDproposal, except that ? is used instead ofthe name COND.  I could support such ascheme.  I do not care for using thepreviously unused character ?, but I canlive with it.
One barrier to approval of the ? scheme isthat it does not fit the approved specs andsemantics.  That means we would have torevise an already approved paper.  It isnot an insurmountable barrier, but it willbe more work.

My COND proposal might have been furtherdeveloped than what you have now.  Inparticular, COND was to be an elementalintrinsic function.  The arguments ofCOND were all scalar arguments.  Thefunction could be applied elementally,which gives it greater functionalitythan might be immediately obvious.
For example, suppose A and B areconformant arrays.  Then the assignment
      A = COND(B >= 0.0, SQRT(B), -0.0)
could be used to get the effect of
      WHERE (B => 0.0)        A = SQRT(B)      ELSEWHERE        A = -0.0      END WHERE
I find the one line version easier tounderstand.  The same could hold if thename COND were replaced with thecharacter ?.
My proposal to use -> and : as if-thenand else operators was designed with theintent to support an extension that isnot allowed under the current specs andsemantics.  The extension was consideredand rejected when the specs paper waswritten.  I thought that rejection wasa design error that would make it harderto maintain codes, but I thought itcould be fixed in a later revision ofthe standard.
The rejected feature was a then-ifcapability.  My syntactic form caneasily be extended to allow a then-ifcapability.  The extended syntacticform of cond-expr is
      <cond-expr> is  ( <predicate> ->                         [ <predicate -> ] ... 
                          <expr> : <alternative> )
I call the extension predicate chaining.
Under predicate chaining, each predicate isevaluated in sequence until either all thepredicates are found to be true, in which casethe value of the contained expr is the valueof the cond-expr, or an expression is found tobe false, in which case the value of thealternative is the value of the cond-expr.
For example, without predicate chaining, thestatement
      IF ( p1 .AND. p2 .AND. p3 ) THEN
might translate to
      IF ( (p1 -> (p2 -> p3 : .FALSE.) : .FALSE.) ) THEN
with predicate chaining, the translation couldbe
      IF ( (p1 -> p2 -> p3 : .FALSE.) ) THEN
Note that in the form without predicate chaining,adding or deleting a predicate requires adjustingthe nesting and the number of instances of .FALSE..

The example
      IF ( p1 .OR. p2. .OR. p3 ) THEN
is not improved by predicate chaining.  Thenatural translation, whether predicate chainingis available or not is
      IF ( (p1 -> .TRUE. : p2 -> .TRUE. : p3) ) THEN
The repeated use of .TRUE. can be avoided bypredicate chaining, but the resulting translationis ugly.
I did not raise the issue of predicate chainingearlier because it was not included in the specspaper.  Any of the forms proposed in 21-157 and21-159 could be extended to support predicatechaining.  I like to think the -> form indicatesthe sequencing more clearly than the other forms.
Robert Corbett

    On Sunday, June 27, 2021, 9:48:44 AM PDT, Ondřej Čertík via J3 <j3 at mailman.j3-fortran.org> wrote:  
 
 Hi Robert,

On Sun, Jun 27, 2021, at 1:33 AM, Robert Corbett via J3 wrote:
> The intrinsic function MERGE
> almost works as a conditional
> expression.  If the MASK
> argument is scalar, most
> implementations evaluate
> only one of TSOURCE and
> FSOURCE.
> 
> I proposed adding a function
> COND that acted as a
> conditional expression.  COND
> had the form
> 
> COND(predicate, tsource, fsource)
> 
> My proposal did not get much
> support.

One idea is to use `?` instead of `ifthen`, then it is new syntax and not a new "function". The examples from the paper would look like:

      res = ?(x >= 0.0, sqrt(x), -0.0)

      res = ?(present(x), a, ?(present(b), b, 0))

      res = ?(present(x), x, ?(present(y), y, ?(present(z), z, 0)))

> 
> I would like to see how
> short-circuit evaluation would
> be implemented using your
> scheme.  How would the
> statements
> 
> IF ( p1 .AND. p2 .AND. p3 ) THEN
> 
> and
> 
> IF ( p1 .OR. p2 .OR. p3 ) THEN
> 
> where .AND. and .OR. are
> short-circuit operators be
> translated into your
> scheme.

I think it would look like this for AND:

IF ( p1 .AND. p2 ) THEN
IF ( ifthen(p1, p2, .false.) ) THEN
IF ( ?(p1, p2, .false.) ) THEN

IF ( p1 .AND. p2 .AND. p3 ) THEN
IF ( ifthen(p1, ifthen(p2, p3, .false.), .false.) ) THEN
IF ( ?(p1, ?(p2, p3, .false.), .false.) ) THEN

and this for OR:

IF ( p1 .OR. p2 ) THEN
IF ( ifthen(p1, .true., p2) ) THEN
IF ( ?(p1, .true., p2) ) THEN

IF ( p1 .OR. p2 .OR. p3) THEN
IF ( ifthen(p1, .true., ifthen(p2, .true., p3) ) THEN
IF ( ?(p1, .true., ?(p2, .true., p3) ) THEN

Hopefully I didn't make a mistake.

> 
> Which of the three forms
> in papers 21-157 and 21-159
> was the most popular?

73 people voted so far, it was a multiple choice vote, the keyword form and Other (do not add this feature, or, pursue alternative forms) is about equal at 43-45%. The -> form got 24% and the ? form got 6%.

Ondrej
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210627/791f8ee1/attachment-0001.htm>