3 ms·

I don’t believe .NET’s `System.Nullable<T>` is a monad. For example, a type that can encapsulate any other type fulfils the definition of a monadic-value, but

I don’t believe .NET’s `System.Nullable<T>` is a monad. For example, a type that can encapsulate any other type fulfils the definition of a monadic-value, but `Nullable<T>` cannot be used with reference-types and delegates, only a strict subset of value-types (as `Nullable<T>` itself is a value-type, but you cannot use `Nullable<T2>` for T1 in `Nullable<T1>`). While .NET allows for composition with delegates, it’s not very smart, and results in unnecessary type information erasure; for example in Linq if you take a projection of a fixed-size list, then that length information is lost if you then add another step after the projection. (Linq internally has some ugly, but inconsistent implementation hacks; for example, IList<T> length information may be preserved but IReadOnlyCollection<T> length information will not.

nightski 5y ago
C# has nullable reference types now. But I agree it's not perfectly a monad in implementation due to engineering decisions. But the pattern generally follows that of the Option monad in Haskell, even if it falls short. If you know the Option monad you'll find it really easy to pick up .NET's nullable types. That's my point, you find these patterns all over in common programming languages and even though they are hard to learn it's worth it.
- recursive 5y ago
  It's going the other way that's the problem. I understand .net nullable, including some of the weird edge cases and trivia. None of that seems to provide any illumination into the working of more general monads.
  - nightski 5y ago
    Weird, when I was learning Haskell I felt like the Option type looked very familiar. Then when I learned about fmap and bind it was immediately obvious why these would be useful. You mean I can apply a function to a nullable type that has no knolwedge of nullable? Cool! Or I can compose general operations on nullables? That is neat. In fact I think this was the easiest way for me to learn monads - to learn them in the context of things I already understood.
  - DaiPlusPlus 5y ago
    That's because Nullable<T> and nullable-reference-types aren't monads - precisely because they aren't composable. I think this SO post covers it well: https://stackoverflow.com/questions/44965/what-is-a-monad https://stackoverflow.com/questions/44965/what-is-a-monad

nightski 5y ago

C# has nullable reference types now. But I agree it's not perfectly a monad in implementation due to engineering decisions. But the pattern generally follows that of the Option monad in Haskell, even if it falls short. If you know the Option monad you'll find it really easy to pick up .NET's nullable types. That's my point, you find these patterns all over in common programming languages and even though they are hard to learn it's worth it.

recursive 5y ago
It's going the other way that's the problem. I understand .net nullable, including some of the weird edge cases and trivia. None of that seems to provide any illumination into the working of more general monads.
- nightski 5y ago
  Weird, when I was learning Haskell I felt like the Option type looked very familiar. Then when I learned about fmap and bind it was immediately obvious why these would be useful. You mean I can apply a function to a nullable type that has no knolwedge of nullable? Cool! Or I can compose general operations on nullables? That is neat. In fact I think this was the easiest way for me to learn monads - to learn them in the context of things I already understood.
- DaiPlusPlus 5y ago
  That's because Nullable<T> and nullable-reference-types aren't monads - precisely because they aren't composable. I think this SO post covers it well: https://stackoverflow.com/questions/44965/what-is-a-monad https://stackoverflow.com/questions/44965/what-is-a-monad