R.prop and R.path inconsistency

[lo1tuma]

As mentioned in gitter, I’ve found a scenario where the behavior of R.path differs from R.prop:

R.prop('foo', undefined); // throws 
R.path(['foo'], undefined); // -> undefined

IMHO if the path array of R.path contains only one element the function should be equivalent to R.prop.

[CrossEye]

I'd forgotten that this was mentioned on Gitter. I was going to respond there, but some other conversation intervened. I believe someone there suggested that both should throw. I'm going to disagree. Functions that throw do not compose. While I have no problem leaving unspecified behavior fairly inconsistent, I think we should not throw here, and have prop take its cue from path.

module.exports = _curry2(function prop(p, obj) {
  if (obj == null) {
    return;
  }
  return obj[p];
});

What do others think?

[gilligan]

👍 for having both functions return undefined in that scenario.

[lo1tuma]

Agreed, I would also prefer to return undefined in both cases.

[davidchambers]

Functions that throw do not compose.

In this case we're talking about a type mismatch – an error that would be caught at compile-time in a statically typed language. It's important not to conflate type mismatches with correctly typed operations which may fail. Types such as Maybe a and Either a b allow us to encode the possibility of failure. Type mismatches, though, should (in my view) crash the program. How can we continue if we receive a value of an unexpected type?

Looked at another way, how should R.compose(R.toUpper, R.negate)(42) behave? The types don't line up. If R.prop('foo', undefined) were to evaluate to undefined, should R.toUpper(-42) evaluate to undefined also? Is there some reason that R.prop should accept arguments of the wrong types but other functions (such as R.toUpper) should not?

[gilligan]

@davidchambers Hm, well I suppose your line of argumentation is sound. I was looking at it from a more pragmatic perspective where a function returning undefined is more convenient to handle.

An aside: You mention that we can encode failures in sum types. I would however assume that the majority of ramda users do not use it in combination with fantasyspec adhering Maybe/Either sum types.

[davidchambers]

You mention that we can encode failures in sum types. I would however assume that the majority of ramda users do not use it in combination with fantasyspec adhering Maybe/Either sum types.

You're no doubt correct. I worry, though, about null tolerance permeating the library due to the unavailability of suitable types. We could find ourselves in a position where all Ramda functions have a != null guard, which would make locating the source of a type error quite challenging.

[buzzdecafe]

We could find ourselves in a position where all Ramda functions have a != null guard

i'll be dead then