use maybes for unsafe operations

[davidchambers]

Certain Ramda functions are unsafe. Take this quartet, for example:

R.head :: [a] -> a | Undefined  -- unsafe
R.last :: [a] -> a | Undefined  -- unsafe
R.tail :: [a] -> [a]            -- safe, but misleading
R.init :: [a] -> [a]            -- safe, but misleading

I suggest the following types:

R.head :: [a] -> Maybe a
R.last :: [a] -> Maybe a
R.tail :: [a] -> Maybe [a]
R.init :: [a] -> Maybe [a]

We could also provide the unsafe versions:

R.unsafeHead :: [a] -> a | Undefined
R.unsafeLast :: [a] -> a | Undefined
R.unsafeTail :: [a] -> [a]
R.unsafeInit :: [a] -> [a]

We'd also provide the following function which takes a default value as its first argument:

R.fromMaybe :: a -> Maybe a -> a

Let's consider a simple example: taking the first element of a [String] of unknown length and converting it to upper-case.

// Naive solution (will throw if list is empty)
R.toUpper(R.head(list))

// Pre-emptive check
R.ifElse(R.isEmpty, R.always('<default>'), R.pipe(R.head, R.toUpperCase))(list)

// Maybe
R.fromMaybe('<default>', R.map(R.toUpperCase, R.head(list)))

It's cleaner and less error-prone to map over a maybe than to rely on checking for the empty list whenever one uses a member of this quartet.

These types are used by purescript-arrays. I'd like to Ramda do the same.

[buzzdecafe]

we just moved all the types 😝

[buzzdecafe]

ok, after mulling this over, i think i am 👎 on this. I'd rather compose with Maybe (or other Functors) than bake them in to primitive operations like head.

[davidchambers]

How would that work with tail, for example?

[buzzdecafe]

the contract of tail is already null-safe, `cuz it returns a functor, an array.

[davidchambers]

It's safe, yes, but also lossy:

R.tail([1])  //=> []
R.tail([])   //=> []

Whereas with maybes these cases are distinct:

R.tail([1])  //=> Just([])
R.tail([])   //=> Nothing()

[buzzdecafe]

i don't see why the proposal is an improvement over simply letting the user compose for themselves: R.compose(Maybe, R.head). tail is only trickier if you don't agree that the tail of an empty list is an empty list. That seems perfectly reasonable to me.

[davidchambers]

Having Maybe treat null/undefined specially seems problematic. It makes the following expressions equivalent:

Maybe(R.head([undefined]))
Maybe(R.head([]))

These are not equivalent in my mind: I expect Just(undefined) in one case and Nothing() in the other.

[buzzdecafe]

You can re-implement Maybe in terms of Just | Nothing (see #123) if you want, but I bet the case above will be difficult to resolve satisfactorily.

I expect Just(undefined) in one case and Nothing() in the other

That is because of weird-ass JS. Just(undefined) is pretty crazy.

[davidchambers]

I don't see this as a JavaScript-specific issue. Take the tuple (None, None, None) in Python, for example. What's the head of this tuple? None. But were a Python implementation of Ramda to return None as the head of the empty tuple we'd have no way to differentiate the two cases.

[buzzdecafe]

yes, that's the situation we are in: head([undefined, 1, 2, 3]) === head([]). This doesn't cry out to me for a solution.

Maybe(R.head([undefined])) == Maybe(R.head([])) (like Nothing, in the current impl): I also don't see this as much of a problem. If you are composing these things why would you want to pass undefined to the next function? That seems strange to me.

Aside: A quick look at https://github.com/folktale/data.maybe/blob/master/lib/maybe.js doesn't back me up here, allowing Just explicitly to wrap null or undefined values. On the other hand, @DrBoolean 's pointfree-fantasy (https://github.com/DrBoolean/pointfree-fantasy/blob/master/instances/maybe.js) interprets null and undefined as Nothing, much as our existing Maybe does. So this may be an open question.

And another thing: Why favor Maybe over other functors? What if I want an Either or a Validator or my own data type? That is another argument in favor of the compositional approach.

[CrossEye]

I have several thoughts here.

• Adding the algebraic types like Maybe when the user wants them sounds perfect for Ramda. I'm very glad that we have the extensions. I think they are still far from complete, but they're worthwhile. On the other hand, forcing them on all users of the library, whether they understand the notions or not seems very much against our practical mantra. Remember that although we might end up poorly implementing half of Haskell, doing so is not our driving goal.
• Working with undefined is interesting. To my mind, we should never explicitly deal with undefined any differently than we deal with 'does not exist'. That the language has a few back doors, as with the arguments object, does not mean that we should treat them as API guidelines. So to my mind, R.head([undefined]) should be treated precisely the same as R.head([]). This is different from how one would deal with null. I think that treating null as an intentional blank value and undefined as the lack of a value is as close as we can get to the spirit of the language.
• Now that work on Error checking #481 is back underway, we may end up with some sort of error-checking, but I would expect that to end up in a supplemental version, not in the main ramda.js. I'm simply wary of adding too much hand-holding to Ramda. I've thought of it all along as a library for those who know what they're doing. I'd like it to be beginner-friendly, but don't want to go far out of our way to blunt any sharp corners, especially at a cost of increased complexity.

[AutoSponge]

R.head([undefined]) should be treated precisely the same as R.head([])

I'm missing something... My understanding is that ES6 array methods will ignore "holes". If I pass undefined to a function, that should hardly be the same as passing no arguments.

[davidchambers]

I think that treating null as an intentional blank value and undefined as the lack of a value is as close as we can get to the spirit of the language.

I avoid differentiating these values in code I write. I like to pretend there's just one nil value (which I call "null", but which others sometimes call "undefined"). I have my linter configured to allow == null checks. Just a day or two ago we added R.isNil which encourages us to think of both values as nil.

[buzzdecafe]

If I pass undefined to a function, that should hardly be the same as passing no arguments.

i agree, but composing by passing down undefined feels pretty weird to me. that's where I'd be likely to interpose a functor.

[megawac]

Another option would be to return R.__ if the value is out of bounds. That way the user could override it if they're particularly keen on handling this case