FRESH

Hacker News

When if is just a function

69 points by soheilpro

by correct_horse

1 subcomments

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.

by padjo

0 subcomment

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

by veqq

2 subcomments

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

by tromp

1 subcomments

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"
```

by emoII

1 subcomments

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

by foofoo12

1 subcomments

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.

by the_gipsy

0 subcomment

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.

by hatthew

3 subcomments

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?)

by motorest

1 subcomments

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?

by solomonb

0 subcomment

Given an algebraic data type such as:
```
    data List a = Nil | Cons a (List a)
```
You can define its recursion principle by building a higher-order function that receives an element of your type and, for each constructor, receives a function that takes all the parameters of that constructor (with any recursive parameters replaced by `r`) and returns `r`.
For `List` this becomes:
```
   foldr :: (() -> r) -> (a -> r -> r) -> List a -> r
```
The eliminator for `Nil` can be simplified to `r` as `() -> r` is isomorphic to `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)
```
For `Bool`:
```
    data Bool = True | False
```
We get:
```
    bool :: a -> a -> Bool -> a
    bool p q True = q
    bool p q False = p
```
Which is precisely an If statement as a function!
:D

by ivanjermakov

1 subcomments

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.

by davidw

2 subcomments

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

by jrochkind1

2 subcomments

Smalltalk, anyone? I guess the OO version.

by analog31

2 subcomments

Interestingly, Excel provides "if" as a function:
=if(condition, value-if-true, value-if-false)

by icepat

3 subcomments

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

by spankalee

3 subcomments

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.

by ozy

1 subcomments

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

0 subcomment

by mappum

1 subcomments

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.

0 subcomment

by blahgeek

3 subcomments

Seems lispy

by lisbbb

0 subcomment

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.