Combinatory programing offers functional control flow. (Here is a straight forward explanation: https://blog.zdsmith.com/series/combinatory-programming.html ) I was inspired to write `better-cond` in Janet:

    (defn better-cond
    [& pairs]
    (fn [& arg]
        (label result
            (defn argy [f] (if (> (length arg) 0) (f ;arg) (f arg))) # naming is hard
            (each [pred body] (partition 2 pairs)
                (when (argy pred)
                (return result (if (function? body)
                                    (argy body) # calls body on args
                                    body)))))))
    Most Lisps have `cond` like this:

    (def x 5)
    (cond
    ((odd? x) "odd") ; note wrapping around each test-result pair
    ((even? x) "even"))

    Clojure (and children Fennel and Janet) don't require wrapping the pairs:

    (def x 5)
    (cond
    (odd? x) "odd"
    (even? x) "even")

    My combinatoresque `better-cond` doesn't require a variable at all and is simply a function call which you can `map` over etc.:

    ((better-cond
    (fn [x] (> 3 x)) "not a number" # just showing that it can accept other structures
    odd?   "odd"
    even?  "even") 5)

    Of course, it can work over multiple variables too and have cool function output:

    (defn recombine # 3 train in APL or ϕ combinator
    [f g h]
    (fn (& x) (f (g ;x) (h ;x))))

    (((better-cond
    |(function? (constant ;$&))
    |($ array + -)) recombine) 1 2) # |( ) is Janet's short function syntax with $ as vars

For lambda calculus, the motto is "when everything is a function". The boolean true is the function λx.λy.x, while false is λx.λy.y. If b then x else y then simply becomes b x y. In a functional language like Haskell that is basically a typed lambda calculus with lots of syntactic sugar, we can replicate this with:

    type MyBool a = a -> a -> a

    myTrue :: MyBool a
    myTrue = \x y -> x
    myFalse :: MyBool a
    myFalse = \x y -> y

    myIf :: MyBool a -> a -> a -> a
    myIf b myThen myElse = b myThen myElse

    main = print $ myIf myTrue "true" "false"

This is interesting, but I'm not convinced it's better than the python it's being compared to. Memorizing and understanding the behavior of functions that perform control flow seems no easier than memorizing and understanding hardcoded syntax/keywords. The additional flexibility of making everything a first-class citizen allows people to write code that is too clever for its own good. I could be wrong but I think there is a broad consensus that reflection is a Bad Idea.

Open to being convinced otherwise

(tangent but related, aren't the "Loops" and "Iteration" examples given for python literally the exact same syntax, with the exception of changing how the iterable is generated?)

Interesting that this article makes no mention of eager vs lazy evaluation - isn’t a big reason that if, for etc has to be special forms in an eagerly evaluated language that their arguments need to be lazily evaluated, which of course, deviates from the rule? Also, lazy evaluation is achieved in an eagerly evaluated language as simply wrapping a block of code in a function, which makes lazy evaluation isomorphic with the contents of the article

The drawback is that this approach elevates code blocks to first class. It means that there is a semantical difference between a value that is a block and a value that is a result of a block. This reduces code clarity, because now block def/result is discriminated by context instead of syntax.

- closures get tricky, i.e. having outer scoped variables within a block

- inter-block operators still need special care, e.g. return should return from a function or a nearest block, same for break/continue/etc.

The Trade-offs section doesn't list the biggest one.

Secretly, all code wants to be spaghetti. You and your team have to put a conscious effort into prevent that from happening. Degrading the core of the language like this is like inoculating your homebrew with sewage and expecting it not to go wrong.

There's more to this that I'd absolutely love to see in a language, and I can't tell if rye supports. If you want an ergonomic `if` you need its scope aspects too.

Consider this example

    <beginning of the function>
    x = ...
    if foo:
       y = ...
    else:
       x = ...
       y = ...
    <rest of the function>

a) in each branch, we have everything in scope that comes from <beginning of the function>

b) in <rest of the function>, we have everything in scope that was assigned or reassigned in the executed branch

I'd love a language that supports programmable stuff like if, since I'm tired of python autodiff not handling `if` and `for`. But it would really need programmable scope stuff to still allow the ergonomic "scope effects" that make `if` and `for` blocks ergonomic.

Using closures or code blocks when they're unnecessary gets in the way of static analysis and (sometimes) readability. It's often better to avoid using language constructs that are more powerful than needed for the job. You can still use them when doing something more advanced.

The apply* ?thing is kinda hard to parse, would turn me off seeing lots of that in a codebase.

When everything is an expression, like rust (I think), that's enough. Most of the control flow are used as statements, but if needed, they can be used directly as expression, and you get basically all the advantages. After seeing how effective this is, using a language that doesn't have this feature can be really annoying.

On the other hand, I would like to explore "when arithmetics is just a function". I think Elm does this well: operators are just functions with two arguments that can be written as "1 + 2", the familiar way, or "(+) 1 2". Then you can compose it like "map ((+) 2)" (currying) so you get a function that adds 2 to every item of a list, and so on.

Given an algebraic data type such as:

    data List a = Nil | Cons a (List a)

For `List` this becomes:

   foldr :: (() -> r) -> (a -> r -> r) -> List a -> r

   foldr :: r -> (a -> r -> r) -> List a -> r
   foldr z f Nil = z
   foldr z f (List a xs) = f a (foldr f z xs)

    data Bool = True | False

    bool :: a -> a -> Bool -> a
    bool p q True = q
    bool p q False = p

:D

I'm definitely missing some key insight because after reading the article I felt it was a strawman argument.

Python already has conditional expressions, which already allow 'x if (predicate) else y'. Therefore in Python if is already equivalent to a function, and is composable.

Once you realize this, and also understand that Python has logical operators that can short-circuit, all Python examples feel convoluted and required the blogger to go way out of it's way to write nonidiomatic Python. If the goal was to make a point with Python, why not write Python?

Seems a bit like Tcl, which lets you create your own control structures like that.

Is this just a quirk in my display, or are all the code blocks in this formatted like a CIA black highlighter

Smalltalk, anyone? I guess the OO version.

In R:

    > `if` = function(a, b) { print(a); print(b) }
    > if (2 < 5) { 6 }
    [1] TRUE
    [1] 6

I wish they showed the `else` syntax, because the traditional ALGOL-style if-then-else statement doesn't look native when shoved into most function call notations, unless you have something pretty interesting around named parameters and expressions delimiters.

Interestingly, Excel provides "if" as a function:

=if(condition, value-if-true, value-if-false)

Useless unless the logical operators receive their rhs unevaluated. And that is generalized as a language feature.

Seems lispy

This discussion makes me so happy because people still care about programming languages and not just on stupid Java or whatever is making gobs of money. LISP should have a much larger following than it does, though I fully admit it has its own warts.

I own the 'if' package on npm, which I wrote to be functions that can replace the if keyword, making no use of the if keyword in its definition.

Just here to point out that the actor’s name is Bob Odenkirk not Odendirk. In a statically typed language this would be an error at compile time not hacker news comment time.