Provide more instances

[garyb]

We can provide most or all of the same instance Maybe has. Will hold off until the 0.7 updates are through though.

[hdgarrood]

Given that Nullable (Nullable a) seems likely to cause weirdness, I'm not sure if this is a good idea. I think we might be better off keeping Nullable uncomfortable for anything other than just wrapping / unwrapping with FFI bindings. People can use toMaybe if they want Maybe instances. Eq and Ord (which we currently have) are probably ok, though.

Thinking more about the nested Nullable problem - maybe toNullable should even throw at runtime if it's given Just null? We can't prevent people from writing Nullable (Nullable a), as far as I can tell, but it might be worth preventing them from constructing values of that type.

[erisco]

The weird situation can be described by this question:

If x :: a is represented by null, then what are the consequences of full x :: Nullable a?

Lets give ourselves some definitions:

full :: forall a. a -> Nullable a
full = unsafeCoerce

exports['null'] = null;

foreign import null :: forall a. Nullable a

exports.fold = function (null_, full, nullable) {
  return nullable === null ? null_ : full(nullable);
}

foreign import fold_ :: forall a r. Fn3 r (a -> r) (Nullable a) r

fold :: forall a r. r -> (a -> r) -> Nullable a -> r
fold = runFn3 fold_

exports.isNull = function (a) {
  return a === null;
}

foreign import isNull :: forall a. a -> Boolean

isFull :: forall a. a -> Boolean
isFull = not <<< isNull

instance eqNullable :: Eq a => Eq (Nullable a) where
  eq a b = fold (fold true (const false) b) (\x -> fold false (\y -> x == y)) a

These are the consequences:

isNull null = true
isNull (full x) = true   (if isNull x = true)

fold n f x = n   (if isNull x = true)
fold n f x = f (unsafeCoerce x)   (if isNull x = false)

x == y = true   (if isNull x = true and isNull y = true, using Eq (Nullable a))
full x == y = true   (if isNull x = true and isNull y = true)
full x == full y = x == y   (if isNull x == false and isNull y == false)
otherwise false

A more concrete example of weirdness is full null == null. However, look at isNull carefully and see the type is forall a. a -> Boolean. Therefore, any type a gives full x == null if x :: a and isNull x = true.

Or, in other words, isNull and fold violate parametricity.

Changing the type of isNull does not help because its type is not prescriptive. Rather, it helps describe the reality of full not being a true constructor (it applies no tag to the value).

I see no evidence that these definitions are unsound. The problem, if you consider it one, is the loss of parametricity. The loss is isolated to fold, isNull and definitions derived therefrom. In practice, you will know what to expect by seeing the Nullable type.

You have to weigh a loss here with a gain in ease for interoperating with JavaScript. This is a type to use on a low level for foreign imports and should not be seen elsewhere (any more than you would expect Fn3 and friends to be seen elsewhere).

Investigating a Functor instance:

instance functorNullable :: Functor Nullable where
  map f = fold null (full <<< f)

Counter-example to Functor law map g <<< map f = map (g <<< f):

(map (const 1) <<< map (const null)) (full 0)
= map (const 1) (map (const null) (full 0))
= map (const 1) (full null)
= null

map (const 1 <<< const null) (full 0)
= full 1

null ≠ full 1

Given the current module, we still have:

toNullable :: forall a. Maybe a -> Nullable a
toNullable = maybe null notNull

toMaybe :: forall a. Nullable a -> Maybe a
toMaybe n = runFn3 nullable n Nothing Just

And therefore:

null :: forall a. Nullable a
null = toNullable Nothing

full :: forall a. a -> Nullable a
full = toNullable <<< Just

fold :: forall a r. r -> (a -> r) -> Nullable a -> r
fold n f = maybe n f <<< toMaybe

isNull :: forall a. a -> Boolean
isNull = fold true (const false) <<< full

And so with this module we already have all these problems. For example, again:

> full (null :: Nullable Int) == null
true

---

In my opinion, this module as well as Data.Undefined (which mimics this one) should be scrapped. Here are two solutions I would agree with:

Solution 1

module Unsafe.Nullable (unsafeNull) where

exports.unsafeNull = null;
foreign import unsafeNull :: forall a. a

This is the simplest idea where null inhabits everything and the programmer acknowledges it is unsafe.

Solution 2

module Data.Nullable (Nullable, null, full) where

newtype Nullable a = Full a

exports['null'] = null;
foreign import null :: forall a. Nullable a

full :: forall a. a -> Nullable a
full = Full

In this solution we retain the Nullable type constructor but no values can come out, nor does it inhabit any type classes. full null is still representationally equal to null but this is unobservable using this module.

Foreign imports must be careful about how they use the type. For example, you could implement isNull:

exports.isNull = function (x) {
  return x === null;
}
foreign import isNull :: forall a. Nullable a -> Boolean

However, this violates parametricity because isNull is not just discriminating null from Nullable a but also null from a.

For proper use, any concrete Nullable A should be fine, though the foreign import should take care not to discriminate A in ways not intended by the module which exports it.

[hdgarrood]

You're of course right that the parametricity issue is there regardless of whether we provide these instances, but I am still quite certain that the best course of action is not to provide them, because I think these issues would be significantly easier to run into accidentally if we provided these instances. I vote to close this, thoughts?

[hdgarrood]

I also think the current design of this library does make the most sense out of the possibilities I've seen. I'm not keen on scrapping it.

[eric-corumdigital]

As I demonstrated, Nullable violates Functor laws, so I hope on that basis no one would consider having a Functor instance for it. As far as other classes go, whether to have instances for them or not should depend entirely on whether Nullable satisfies the laws or not.

If the violation of parametricity is to be ignored, then I do not understand the fascination with the toMaybe/toNullable API. I demonstrated it is equivalent to an API which does not involve Maybe at all (null, full, and fold). Operationally, that avoids time and space managing Just and Nothing objects. Furthermore, it does not suggest an equivalence to Maybe (of which there is not).