Kotlin or FoxPro Style IIF (inline if)

[Larry Rix]

In the old days of Visual Foxpro, we had a thing called an IN-LINE IF or IIF.

A FoxPro wanna-be wrote the C as:

// VFP2Servoy Toolkit
// Function : IIF()
// Author   : Omar van Galen
/**
* Returns one of two values depending on the value of a logical expression
*
* @param {Boolean} lExpression
* @param {Object} eExpression1
* @param {Object} eExpression2
*/
function IIF(lExpression, eExpression1, eExpression2){
    if(lExpression){
        return eExpression1;
    }else{
        return eExpression2;
    }
}

Of course, this is VERY type unsafe, which is a huge trademark of FoxPro.

I bring it up because Kotlin has a very similar thing where and assignment can be made from whatever is passed back from a similar type of "if". See the attached graphics.

I decided to see if I could write a similar thing in Eiffel with Complete Void Safety. It turns out that I can write it very well and with flavors. One flavor as an attached Result, while another can more easily have a detached Result.

[Larry Rix]

New programmers are like children. They don't think in terms of consequences and "where-do-bugs-come-from" and notions like "does-my-favorite-thing-make-bugs"?

NOTE: I went 18 years in FoxPro thinking and convinced through programming-language religious zealotry that FoxPro was the best ever and no other language was as good. If you showed me your thing, I would show you why I was convinced that FoxPro was the true Gospel of Computer Programming and your thing was damned to programming-language hell.

Perhaps this is why I am certainly an Eiffel Evangelist in some ways. No, I don't have an emotional attachment to Eiffel, but a sound and reasoned preference that is based on observation and time to understand just where those bugs in my code are coming from!

What I do not want to do is toss the baby out with the bathwater. So, as I am reviewing Kotlin and considering it next to Eiffel, and I then come upon this Kotlin-ish-reinvention of the FoxPro IIF-wheel, I am immediately moved to ask, "Can I do that in Eiffel code?"

It's like the whole Java record class type in my other post. I actually think that there is some merit to it, but that it belongs to the compiler and not the language and libraries. I tried to make such a thing, but it got pretty ugly in comparison to the nice compiler-based "record" class and how it works in Java. I am not saying I think we need to rush off and keep up with the Java-Jones just this moment, but it did make me realize a useful concept and that some things belong to the compiler (still -- not saying "record" class in Eiffel is a good thing).

I dredge that back up here (out of the topic thread I created for it) because it dovetails with my looking at these other "hot" and "popular" languages. As I am looking at them, I am giving a bow to them to say, "That has some merit!" and then "can-I-do-that-in-Eiffel"? If I can, do such things need to find their way into a separate "junk" library project — like that kitchen-drawer library where you put all the things that you don't know where they belong otherwise, but you don't want to throw out (come on -- we all have junk drawers, right?).

[Eric Bezault]

What about using Eiffel's conditional expressions:

greeting_to_print := if attached greeting as l_attached_greeting then
l_attached_greeting else "Hi" end

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

[Larry Rix]

I like it!  I don't think I have every used an if-then-else-end like that! Thank you for pointing that out!

[Larry Rix]

So, I cranked it up in my example junk code and, viola, it works!

greeting_to_print := if attached greeting then greeting else "Hi" end

[Larry Rix]

Which in turn means this works:

print (if attached greeting then greeting else "Hi" end)

NICE!!!

[Larry Rix]

Lo and behold, it works with the inspect as well!!

x := inspect a

when 1 then b

when 2 then c

when 3 then d

else e

end

[Larry Rix]

Arrrrrggggghhh!!!!

How did I miss being taught this?

This is worthy of a new video on the Learn Eiffel channel on YouTube!

[john....@usm.edu]

This is much older than FoxPro. According to Wirth's Compiler Construction textbook, anyway, it dates from one of the Algols. Ada also has a version of it.

john perry

[Larry Rix]

Thank you, John!

I don't doubt that FoxPro is not the genesis. It's just where I first learned about and used such a function.

[Larry Rix]

And this video was born: https://youtu.be/4W5SN1d7pOc

[Richard]

Note: the inspect  multi-branch expression requires Eifel 20.05 as minimum.

May I express here my thanks to the Eiffel Gods for implementing this language feature after an innocent question and discussion last year!

(ref: https://groups.google.com/u/1/g/eiffel-users/c/_1iBRpOEXko/m/_E6PPcjuBAAJ)

[Ulrich Windl]

>>> Richard <eiffel-...@rth10260.info> schrieb am 05.11.2020 um 04:51 in
Nachricht <40734f20-c0f4-4c0f...@googlegroups.com>:

> Note: the inspect multi-branch expression requires Eifel 20.05 as minimum.

That may explain why that looked so new to me. Can all types of statements be used as expressions now? What is the criteria for allowing it? What about loops?

Regards,
Ulrich

> --
> You received this message because you are subscribed to the Google Groups
> "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to eiffel-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/eiffel-users/40734f20-c0f4-4c0f-9d5b-6dc822
> 9c8992n%40googlegroups.com.

[Thomas Beale]

Purely for academic interest, our Basic Meta-Model specification provides the meta-model for a fully generalised version of iif() called a 'decision table' that can have multiple branches. Like IIF(), each branch must be an expression, not a statement.

One possible syntax is the following (the horizontal lines are just comments):

    molecular_subtype: Terminology_term

        Result := [[

            =========================================================

            er_positive and

            her2_negative and

            not ki67.in_range ([high]):    [luminal_A],

            ---------------------------------------------------------

            er_positive and

            her2_negative and

            ki67.in_range ([high]):        [luminal_B_HER2_negative],

            ---------------------------------------------------------

            er_positive and

            her2_positive:                 [luminal_B_HER2_positive],

            ---------------------------------------------------------

            er_negative and

            pr_negative and

            her2_positive and

            ki67.in_range ([high]):        [HER2],

            ---------------------------------------------------------

            er_negative and

            pr_negative and

            her2_negative and

            ki67.in_range ([high]):        [triple_negative],

            ---------------------------------------------------------

            *:                             [none]

            =========================================================

        ]]

- thomas