Hacker News Reader

Comment by nine_k | Hacker News Reader

The key idea: Optional[T] is more ergonomic through pattern matching, because inside the matched case, we definitely know whether it's carrying a value or not. The whole problem of nullability gets an elegant solution.

The fun premise from the beginning is that booleans do not need their special type, they are effectively Optional[Void], or for FP-heads here, Optional[Unit]. That is, it just does not need to carry a value. But when an Optional does carry a value, a lot of if-then-else logic for handling that value just gets eliminated, replaced by a pattern match that combines both the boolean aspect and the value-handling aspect.

View on HN

Option types require do-notation / computation expressions to be practical in my view. Otherwise you get the pyramid of doom!

    match x with
    | Some y -> 
      match y.Foo with
      | Some z -> 
        match z.Bar with
        | Some w -> printfn $"{w.Qux}"
        | None -> ()
      | None -> ()
    | None -> ()

Compared to...

    option {
      let! y = x
      let! z = y.Foo
      let! w = z.Bar

      printfn $"{w.Qux}"
    }

Funny quirk in Java, the compiler checks that calls to `opt.get()` occur inside an `opt.isPresent()` branch!

    if (opt.isPresent()) {
      println(opt.get());
    }

The pyramid of doom means that you're explicit about error handling at each step though, which doesn't look easy with the do notation.

You must understand the semantics of the monad you are operating in, but both cases are still handled in the do-notation version.

> The fun premise from the beginning is that booleans do not need their special type, they are effectively Optional[Void], or for FP-heads here, Optional[Unit]. That is, it just does not need to carry a value. But when an Optional does carry a value, a lot of if-then-else logic for handling that value just gets eliminated, replaced by a pattern match that combines both the boolean aspect and the value-handling aspect.

We could take it step further.

Option[T] is just Result[T, Unit]

Then a boolean is Result[Unit, Unit]

> booleans do not need their special type, they are effectively Optional[Void]

The fact that two types are structurally isomorphic doesn’t mean that it’s necessarily a good idea to make them the same type.

I think the actual observation of the article is that many booleans are guards for the presence (or validity) of a value, and that modelling those as Optionals binds the result of the guard and the applicable value in a way which can prevent later mistakes.

It's not arguing at all booleans should be treated this way.

That makes more sense, although I can’t say that "many booleans are guards for the presence (or validity) of a value" matches my experience.

Many of those booleans aren't necessarily named.

Any "is(n't) null" check on a nullable includes a boolean expression. That's quite a few booleans right there.

Using an optional (and accessing it with either fmap or a match expression) removes the value from the scope of the "wasn't present" branch, eliminating a possible source of mistakes.

Using an optional with an isPresent test does not. And you see that boolean pop up again in the return of that method. I think that's what they're getting at.

Reply on news.ycombinator.com