Hacker News Reader

Comment by Gunax | Hacker News Reader

It seems like the issue then is that int can be nullable. The solution is to make int an int. You cannot assign None to int.

I'm not an expert on programming languages, but asaik this is how typescript operates

View on HN

That's not quite what the parent is trying to say. Assume that int is not None. Create a type called T that is int|None - a term of type T can be an int, or it can be None.

Now have a function whose argument is T|None. Substitute in the definition of T and you get (int|None)|None. If the function's argument is None, what does that mean? Was it given a T that happened to be None, or was it not given a T? Nobody knows.

> Was it given a T that happened to be None, or was it not given a T?

Hmm. It _feels_ like a function shouldn't ever need to differentiate between "what the caller thinks it has" (that is - being passed a "T-which-is-None" should have the same significance as being passed a "None"), but I'm not confident claiming that would ever be the case.

Consider an expensive computation that may have no answer, and so it returns (after some heavy processing) "int|None".

Also consider a cache lookup function that takes some key and returns a generic T|None for T the type of cache entries, with None signifying the key was not found.

Both are, on their own, pretty reasonable things to have.

If you are using union types and you put the results of your expensive computation into your cache, you will not be able to tell when you've done an expensive computation for some key and got a None result, or when you haven't got a result in the cache for that key.

You can have both union types and sum types (imo ideally), or in this case can easily choose to represent the result of the expensive computation in a more reasonable/descriptive way.

Perhaps the more reasonable/descriptive way to represent the potentially no-value result of the computation is with a sum type, not a union type?

> If you are using union types and you put the results of your expensive computation into your cache, you will not be able to tell when you've done an expensive computation for some key and got a None result, or when you haven't got a result in the cache for that key

This is certainly an issue, but that's an issue for the _overall system_ of a cache which stores T. My claim wasn't that "Union types that Union with None can never cause issues", but rather that, for a function whose argument is `(int|None)|None`, there shouldn't ever be any different behaviour _of that function_ between "passed a T (int|None), which was None", and "passed a None (not a T)". The function itself should still behave the same way.

You're right, of course, that _returning_ an (int|None), where "None" might mean "the answer is definitively known to be None" or might mean "the answer is unknown, and that is represented as None" can lead to unnecessary recomputation - but that's an issue of return types, not of parameter types.

One function's return value is another function's parameter. If the overall system has a bug, that's a problem, and I don't see any value in trying to quibble about whether it's a bug in the caller or the callee.

> I don't see any value in trying to quibble about whether it's a bug in the caller or the callee.

Right, neither do I - like I said, "that's an issue for the _overall system_ of a cache which stores T.". The bug is that a given type (None) has different meanings to different components of the system, and this bug only arises _because_ "One function's return value is [being passed, directly, without any interpretation, as ] another function's parameter". If the type signatures were changed so that interpretation was required - so that "the answer is None" could be distinguished from "I don't have an answer" - then the bug in the overall system goes away.

> this bug only arises _because_ "One function's return value is [being passed, directly, without any interpretation, as ] another function's parameter".

Which is the normal way of programming. If you can't safely compose functions without adding an extra layer of interpretation between them, programming becomes much harder.

> If the type signatures were changed so that interpretation was required - so that "the answer is None" could be distinguished from "I don't have an answer" - then the bug in the overall system goes away.

Which is something that using sum types rather than union types achieves by default. Wherever you want to localise the problem, union types add a big, easy class of ways to shoot yourself in the foot that just aren't there if you use sum types.

It is useful to differentiate this, though. Consider a datatype of map with values of type T. The function to return value for a key returns None when the key is not in the map, but what if the key is in the map, but the actual value is None? IIRC Lisp has a workaround but it requires special code to handle maps that can have None as values.

As the other posters have said, it (automatically flattening the Maybe monad) is non-composable and should be considered a bad language design, like it was a bad idea to automatically flatten lists in Perl.

That's why in python that raises a KeyError, or if you use explicitly .get() you can specify anything as your default value.

It's probably subjective, but I don't see the need to wrap your code in a try/except block as an improvement over an optional sum type, and I really don't see the use of a magic value to indicate no value as an improvement over anything.

If it's not a try it's an if... you still need to handle the case where the key wasn't present and figure something out.

Which is why you end up with the painful

    sentinel = object()
    value = dictionary.get(key, sentinel)
    if(value == sentinel) ...

Which, sure, it works, but it's working around a problem that didn't need to exist in the first place. Why not just have Option work the way you expect, and be able to contain None the same way as it can contain any other value?

Well no, just handle KeyError :D

If you do that you still have the same problem, although the conditions for triggering it are narrower - you can't tell the difference between "your" KeyError and a KeyError from the callback you were passed.

Arguably, composing/depending on the composability of optional values is also a code smell. A Some(Some(None)) may be occasionally okay, but it is almost always better represented by an explicit type. Also, clojure can better express these in-between states, as demonstrated by the very good talk (I swear Hickey always sells me on Clojure.. I really should write something more serious in it)

Let's try this in python…

    >>> T = int|None
    >>> T|None
    int | None

Yep, quite simply this is solved flattening the unions and removing duplicates :)

Yes, that is the problem, imagine you might write a cache and use None to represent the value not being present in the cache - but then your cache silently fails to cache if the thing you were caching returns None

As I already wrote in a different comment, KeyError and None aren't the same.

That’s not “solved”, that’s highlighting what the problem is.

I don't think you should write code where it makes a difference if the None came from a T that happened to be None or from a None.

Why would you ever use T | None otherwise? As far as I can see the only reason to ever use T | None is because you want to write code that does one thing if it's a None and another thing if it's a T. Having it do the other thing if that T happens to be None makes no more sense than having it do the other thing if that T happens to be 5; at best it might work by accident, more likely it will be a subtle bug.

Reply on news.ycombinator.com