Hacker News Reader

> You can map, filter, reduce, chain, compose functions that all work with optionals, and lift functions that work on numbers (or any other type) to be functions that work on Optional<number> but none of that is even mentioned in this piece (likely cause then its harder to justify picking nullable types instead)

Maybe I'm missing something, but I don't see how that's special to option types. Here's a set of extension methods in Dart that provide the operations you describe:

    extension NullableExtensions<T> on T? {
      R? map<R>(R Function(T) transform) => this == null ? null : transform(this);

      T? filter(bool Function(T) predicate) {
        if (this == null) return null;
        if (predicate(this)) return this;
        return null;
      }
    }

    extension FunctionExtensions<T, R> on R Function(T) {
      R? Function(T?) lift() => (T? param) => param == null ? null : this(param);
    }

    extension NullableIterableExtensions<T> on Iterable<T?> {
      Iterable<R?> map<R>(R Function(T) transform) =>
          this.map((e) => e == null ? null : transform(e));

      Iterable<T?> filter(bool Function(T) predicate) =>
          where((e) => e == null || predicate(e));
    }

Chaining has built-in syntax:

    int? maybeInt = ...
    print(maybeInt?.isEven.toString());

I'm not sure what you mean by "compose".

Of course, this is not entirely as expressive as option types because of the inability to nest, but the article is pretty clear that nesting is the major advantage of option types.

> I'm not sure what you mean by "compose".

The simplest illustration is the ability to have multiple levels of semantically meaningful optionality:

Option<Option<int>> is a meaningful type, and None, Some(None), and Some(Some(1)) are all meaningfully-distinct values. int? doesn't compose to int?? and has no good way to differentiate what Option<Option<int>> represents as None and Some(None).

Ironically the main advantage of Monads is that Option<Option<int>> has a natural transformation to Option<int>.

The reason Option<Option<int>> isn't a problem is because it's a monad, so people will naturally transform it into Option<int> while writing their programs.

There is no irony there. If it wasn't a monad, the GGP would be incorrect, and ad-hock solutions would be very valuable.

In a language with Haskell's guarantees, you can mechanically get from the standard "bind" function to prove that "m (m a)" can be converted to "m a" [1]. That function is called "join", and is a lesser-well known way to write monad implementations which is equivalent to the more famous bind function.

(IMHO, join is a better way to understand the typeclass intuitively. The standard bind is better to program with in general use, but much harder to grok.)

So, in Haskell, it's more than just "the APIs would tend to encourage not nesting the types"... having a valid monad implementation means they really are equivalent.

[1]: https://stackoverflow.com/questions/3382210/monad-join-funct...

They are not equivalent. Join can throw away information - and certainly does for (Maybe (Maybe a) -> Maybe a) and ([[a]] -> [a]).

They would be equivalent if there was an isomorphism, but of course there isn't.

By compose I quite literally mean the compose function.

    const add3 = val => val + 3;
    const multiplyBy10 = val => val * 10;
    const subtract5 = val => val - 5;

    const doABunchOfMath = compose(add3, subtract5, multiplyBy10);

    const ninetyEight = doABunchOfMath(10);

    const optionallyNinetyEight = Some(10).map(doABunchOfMath)

That Dart already provides these extensions feels like they are providing an optional type but through a more complicated mechanism than a simple class

Nowhere in any of the functions I wrote above do I as a user have to worry about handling the case where no number exists, that's handled by the option type and signified by the type (The value in the option may or may not exist) and I can write my functions without ever having to worry about handling that case

Compose can also be implemented easily:

    extension NullableExtensions<T> on T? {
      R? map<R>(R Function(T) transform) => this == null ? null : transform(this!);
    }
    
    V Function(V) compose<V>(Iterable<V Function(V)> functions) =>
        functions.reduce((composedFunction, function) {
          return (V value) => composedFunction(function(value));
        });
    
    num add3(num val) => val + 3;
    num multiplyBy10(num val) => val * 10;
    num subtract5(num val) => val - 5;
    
    final doABunchOfMath = compose([add3, subtract5, multiplyBy10]);
    final optionallyDoABunchOfMath = (num? value) => value.map(doABunchOfMath);

    doABunchOfMath(10); // 98
    optionallyDoABunchOfMath(10); // 98
    optionallyDoABunchOfMath(null); // null

The nullable syntax (${Type}?) also makes it clear to readers that this is a type which may or may not contain a value. If you don't supply the trailing '?', Dart will enforce that the value must exist at compile-time and you can write your functions without worrying about nulls sneaking in where they're unwanted.

In effect, int? is almost nearly Option<int>, except you cannot represent Option<Option<int>> with Dart's nullable syntax.

Check out https://nullsafety.dartpad.dev/ to play around with the possibilities!

>By compose I quite literally mean the compose function.

Outside Lisp/Scheme has anybody used those for anything other than examples in FP tutorials?

Every case I ever seen is non-production tutorial thing like "add3".

Threading syntax is a giant compose. OK, but that's an operator.

In the TXR internals, I have a C function called chain, which composes N functions together (left to right, not right to left like typical compose functions). It is variadic: the end of the arguments is signaled by nao: a not-an-object constant:

  git grep '\<chain('
  eval.c:                       chain(car_f, eq_to_list_f, nao),
  eval.c:                        chain(cdr_f, consp_f, nao),
  eval.c:                        chain(cdr_f, cdr_f, null_f, nao),
  eval.c:                        chain(car_f, eq_to_quote_f, nao),
  eval.c:                                   chain(car_f, eq_to_list_f, nao),
  eval.c:                                   chain(cdr_f, consp_f, nao),
  eval.c:                                   chain(cdr_f, cdr_f, null_f, nao),
  eval.c:                                   chain(cdr_f, car_f, consp_f, nao),
  eval.c:                                   chain(cdr_f, car_f, car_f, eq_to_quote_f, nao),
  eval.c:                              chain(cdr_f, car_f, cdr_f,
  eval.c:  return chain(juxt_fun, apf_fun, nao);
  eval.c:  iter_from_binding_f = chain(cdr_f, iter_begin_f, nao);
  lib.c:  val pred_key = chain(default_arg(key, identity_f), pred, nao);
  lib.c:  val pred_key = chain(default_arg(key, identity_f), pred, null_f, nao);
  lib.c:val chain(val first_fun, ...)
  lib.c:                     chain(car_f, keyfun_in, nao));
  lib.h:val chain(val first_fun, ...);
  match.c:                                      chain(func_n1(cdr),
  match.c:                              chain(func_n1(cdr),
  match.c:                                        chain(func_n1(length_list),
  match.c:                                        chain(func_n1(rest),

The _f variables are pre-computed function objects, stored in globals, to avoid consing them repeatedly. That func_n1(cdr) seen in match.c could be replaced by cdr_f , not to mention by the func_f1(rest); it conses a new function object referencing the C function cdr each time it is called.

I do on a regular basis (front end dev). For an example of how, I found this article[1] to be a nice demonstration of how it can be useful at a basic level for ReactJS. Than you just begin applying the same concepts one level higher for your use case and keep going.

Even if you don't use compose directly, the mindset of working to build systems in a composable manner is invaluable.

Its a mental shift that leads you to thinking how a system can be represented as a series of inputs being piped from one function to the next between boundries of my code (server response data --> client side caller --> transformation functions --> local data store --> UI).

Achieving these pipelines requires expressing intent with functions and with a self imposed constraint of writing pure functions, you begin needing functors and applicatives and monads to help store stateful information.

If at any point you need a new capability or need to add a new code path, you just modify the relevant pipeline(s), write any new (pure) functions along with any adapters you might need to inject it in your pipeline, and you're good to go. If everything is a pure function, testing and debugging instantly become easier. All this from wanting to build composable functions.

Some languages also support piping (runs the functions in the reverse order that compose does) which can help visually since functions are invoked in left to right order which is how we read too.

[1] https://hackernoon.com/forms-of-composition-in-javascript-an...

You missed out the most interesting one, which is 'reduce':

    extension NullableIteratorExtensions<T> on Iterator<T?> {     
      T? reduce<T>(T? Function(T,T) f, T? x0)
         => this.moveNext()
            ? (this.reduce(f, (x0 == null || this.current == null) ? null : f(x0,current)))
            : x0;
    }

Not sure if this is the best notation but then I've never written Dart before.

Of course this is all a bit easier to read if we use some syntax specially built for Monads such as Haskell's do syntax:

    reduce f (head:tail) x0 = do { x <- x0 
                                 ; y <- head
                                 ; reduce f tail (f x y) }
    reduce f [] x0 = x0

which has the advantage that it works for all Monads.

Adding an `Option` type to an existing language doesnt really solve many problems unless you can also somehow remove it's existing support for `null.

Java added `Optional` and while it makes interacting with newer API's clearer, there is nothing preventing you from passing a null Optional.

I think if you are designing a language from scratch, you should avoid null, but nullable types are a good feature for existing languages.

Having written a fair bit of kotlin, I have found the ergonomics of it's nullable type system to be really nice.

Language culture matters. Scala has both `Option` and `null`, but there's a strong culture of "`null` is only for Java interop", so you very rarely see a `null` in the wild from libraries, or wonder whether it'd be valid to pass it in.

Interestingly, Scala 3 is adding union types as well as explicit `null`s:

https://dotty.epfl.ch/docs/reference/other-new-features/expl...

I think that the expectation is that idiomatic Scala code will mostly still use `Option`, while `null` will be used for interoperability with Java, JavaScript or Scala libraries that happen to use `null`.

In any case, I am very much looking forward to these additions.

Your username is so incredibly relevant here that I had to check if this was a novelty account.

I generally agree with you but the one point they make in this article that really matters for Dart is it does not have pattern matching. Dart’s nominative type system makes much of standard FP much harder than you’d imagine. I know Rust is nominal too but Rust has a lot of complexity to support these things.

It is very simple to add a Maybe and Either type to Dart (my code base has variants of these to deal with null issues) but imperative destructing is a pain. You can get most of the benefits of those techniques in user land without the language knowing about it, but I agree it still misses out on some stuff.

If Dart already had pattern matching or was willing to add it first then the ADT version could have been chosen, but without that prerequisite nullable types was the only ergonomic choice.

Dart is looking at adding pattern matching and "record" types: https://github.com/dart-lang/language/tree/master/working/05...

That's an interesting counter point, though another comment in a different post for this same article[1] pointed out that Dart is considering adding pattern matching too.

Though I have trouble understanding how a nominal type system affects this? Does dart not have generics? That's all you need to support these patterns? I'm having trouble understanding how the type of type system plays a role here.

Also, what's 'imperative destructing'? Haven't heard that term before, is that just pulling out a property from an object like this from JS?

    const { foo } = objectWithPropertyFoo;

[1]https://news.ycombinator.com/item?id=25334283

Yes Dart has generics which is how you would implement optional types yourself. The type of type system doesn't play a role here you are right. I was thinking of the really good pattern matching I have experienced usually being present with structural subtyping.

Dart is considering adding pattern matching (and real tuples!) and I think they will eventually get there. I just think that would have had to come first to make the case of optionals over nullable types more compelling.

I would call that example destructing in the normal sense and it is basically a form of pattern matching. To do that in an imperative language without pattern matching (i.e. what I am calling imperative destructuring), you end up with code like

  if (maybeFoo.isSome) {
    final foo = maybeFoo.asValue;
    ...
  }

when you really want

  if let Some(foo) = maybeFoo {...}

You may prefer

    for foo in maybeFoo { ... }

This (AIUI) isn't valid Dart code though, but this would be:

    maybeFoo.forEach((foo) { ... })

I don't buy the pattern matching argument. I've been using Vavr's Option type in Java a lot lately (having banned the use of null from my code), and I don't have any issues with it. I avoid Vavr's pattern matching because I find the syntax to be clunky (not a criticism of the Vavr developers; I think what they've done is impressive within Java's syntax limitations). I do miss pattern matching in general, but I don't find using Option to be any more difficult without it. And no, I never use Option.get(); I have an ArchUnit test set up that will fail the build if anyone tries.

On the flip side, I do find Option a pain to use in Rust sometimes, which does have pattern matching. I think that's a function of the borrow checker making some things harder to express. So perhaps it's not Dart's missing pattern matching that would make Option hard to use there, but some other feature (or missing feature) of the language or type system?

If you are starting from scratch and designing a brand new language then ADT's are a clearly better choice than allowing null. However Dart is not a brand new language. It's a preexisting language that already has null. Given that context nullable types are the only option that doesn't break compatibility with previous languages and allows code to be made null safe. If you already have to have null values because of prior decisions then ADT's don't add null safety. There may be other reasons to want them that aren't about handling null safety. But you'll still have the problem that values can be null and you won't have given developers a tool to handle those potentially null values safely.

This comment is answering post’s title more honestly than the author.

Less words too.

> I also found the Some(Some(3)) example just plain wrong. In those scenarios, typically you just use chain (aka flatMap) instead of map

I think you misunderstood. The point here was that you can represent different things using nested Options:

1. Some(Some(3)) = I checked it and the value is 3

2. Some(None) = I checked it and there is no value

3. None = I haven't checked it

It's very useful when building a cache, and also for things like JSON parsing (property was not present, property present but null, property present and has non-null value).

You just can't represent that using Dart's nullable types system, because "int?" and "int??" are the same, indistinguishable type.

Anyway...

One thing not mentioned in the article is that the way they've implemented it in dart is via "magic syntax", which I consider to be a big negative. Option<T> is something anyone could implement without language support (assuming the type system already supports it). Anyone could build their own Option type and use it. (Sure, it's best to have this sort of thing in the stdlib so the stdlib will use it itself.) Nullable types with the "?" syntax makes the language itself bigger, and is something a regular user of the language couldn't implement if they wanted to.

(Yes, I'm aware that the "?" suffix is just a shortcut for the more generalized union type syntax, but I think my argument holds.)

The use of these types in regular code also requires what I consider a sort of special unintuitive requirement on how you structure your code. I have to do explicit null checks and then the compiler/interpreter just "knows" that code in certain places is null-safe through flow analysis. That kind of magic really turns me off.

I also don't buy the argument that Option types are a pain to use if your language doesn't have pattern matching. I've been doing a bit of Java lately and have banned null from my code, instead using Option from the excellent Vavr library (I find java.util.Optional to be lacking, ditto for Java's built-in collections library). I tend not to use Vavr's pattern matching, as I find it clunky. But I also have no trouble using Vavr's Option.

I guess I just prefer to use languages that have strong type systems where I can express constraints and safety through the types themselves, and not have to rely on language/compiler features to implement those constraints. I think the latter also gives you less flexibility as well.

> I have to do explicit null checks and then the compiler/interpreter just "knows" that code in certain places is null-safe through flow analysis.

You need to do it anyway or you got a crash. Because remove null from a existing language completely is nearly impossible.

And now the compiler is able to know something went wrong in your code instead of happily see you use `null` as a object and crash the whole program.

Besides that, that also benefit the library users that the compiler/ide will tell them `you can't pass null here`

> I also found the Some(Some(3)) example just plain wrong.

I don't see any such example in the article, and searching for that string yields nothing. What part are you talking about?

It was the first bullet point in one of the bullet point sections. The text from the article was

    A Some(Some(string)) means the resource did exist on the server, and we have it in the cache now.

Sorry about that, mixed up the types in my head

> You can map, filter, reduce, chain, compose functions that all work with optionals

Maybe they didn't mention it because both approaches can do that, or maybe I'm misunderstanding?

The difference I see is, when you work with a nullable type, each function has to do the check

so

    const add3 = (val) => val ? val + 3 : null;

    const multiplyBy10 = (val) => val ? val * 10 : null

So the argument type goes from being val to val? where the calling code doesn't necessarily have type safety since this argument is now optional (it can be a number or null and either is acceptable) instead of the following (with no conditionals or ternaries)

    const add3 = val => val + 3;
    const multiplyBy10 = val => val * 10;

This is possible cause optional.map implicitly handles the case where the data is missing by default, its built into the data type and the code you write doesn't need to worry about it. Its the responsibility of the Optional object.

Ah, I gotcha, and I had already read another of your comments below. Yep, agree that is nicer in these cases. I still agree with the author that they made the right choice for Dart.

You could define operations on nullable types to allow this in Dart, like:

    extension NullableNumExtensions on num? {
      num? operator +(num? other) {
        if (this != null && other != null) return this + other;
        return null;
      }
    }

    main() {
      num? i, j;
      print(i + j);
    }

For method calls, we have a null-safe method call syntax that automatically lifts the operation to give you a nullable result:

    int? i;
    var b = i?.isEven; // b has type null?

We could have made all operations implicitly do this lifting, but our experience is that this isn't what users want. They want to know as early in their code when an operation on a potentially-absent value is attempted and reconcile right there what behavior they want.

That is where you use optional chaining + extension method. And that is basically identical to Optional.map or whatever method in those language with Optional type

in kotlin

  func add3 (val: Int?) = val ?.let { it + 3 }

The language gives you a way to say: `this value plus 3 if it exist or just return null`

Unfortunately, there is no such method in js currently, so it looks half baked.