ramda: Better error messaging and type-checking

Are there any plans to start this?

In ramda/ramda gitter, I have seen many problems people ask for help, are just caused by incorrect use of ramda apis, such as:

• passing string instead of array as R.path first argument;
• wrong ways of using pipe/compose:
  • compose the result of executed functions;
  • compose functions of wrong arity; ,etc.

If ramda have a better error messageing and type-checking, I believe it will be of great help to:

• improve developers’ development experience;
• give people more meaningful information of runtime errors in product environment;
• reduce the learning curve of ramda and the entry barrier;

In order to help people easy to learn, write and debug with ramda, I think this is an urgent and important thing to do now.

I would prefer to have the API for our prop / path related functions set before 1.0, but that is the only thing I can think of.

I think starting a 1.x branch is a good idea, but I would want to release 1.0 at the same time so that we can focus on 2.0 instead of pushing for 2 releases.

Once we have that branch we can use it for bug fixes and minor stuff while focusing on the ES6 codebase.

I’ve played with several partial implementations, but have nothing complete yet.

I would like to try this. But I think there is a major question about versions. I would really rather implement this in ES6+ code. So I’m feeling that if we do this, it would be after 1.0. How do you feel about that?

I don’t know what else we want to do before 1.0. I’m hoping it’s very little. But I think it might be time to create a 1.x branch for work we want in our ES3/ES5 code-base, and make master available for work like this on 2.0±versions. Does that make sense?

Just for comparison, I’ve been thinking about something more like this:

const validateArgs = (name, types, args) => {
  // A dummy for now.  A real implementation would compare `types` and `args`
  if (isNil (args [2])) {
    throw TypeError (`Improper type supplied to '${name}'.  Expecting ArrayLike at index 2.`)
  }
}

// This function might also replace `curry1`, `curry2`, etc.
// I have many dreams about what might go in here.
const def = (name, types, fn) => {
  const res = (...args) => {
    validateArgs (name, types, args) // stack-trace fix required?
    return fn (...args)
  }
  res.toString = () => fn .toString ()
  Object .defineProperty (res, 'name', {value: name, /* writable, etc.*/})
  return res
}

const foldl = def ('foldl', ['Function', 'Any', 'ArrayLike'], (fn, init, xs) => 
  xs .reduce ((a, x) => fn (a, x), init)
)

foldl ((a, n) => a + n, 0, [1, 2, 3]) //=> 6
foldl ((a, n) => a + n, 0, undefined)
//~> Improper type supplied to 'foldl'.  Expecting ArrayLike at index 2.

We might well be able to combine your try {happyPath} catch {validate} technique with this.

I haven’t really thought through our few remaining variadic functions like pipe. That might be more difficult to handle.

I don’t mean this to go as far as Sanctuary does with types – I can’t see testing for types like Array(NonZeroInteger) or any such. In fact I think we could just ignore the possible parameterization of types. Bur this might still be an improvement.

@adispring:

I don’t think Typescript can help with this problem. We’re writing a library to be used by JS code-bases. Even if every function had strong TS typings (which last I knew wasn’t even possible yet), this would offer nothing at all to the JS user, unless we tried to insist that all users write in TS and use its compiler to do their type-checking.

That would be a very different library.

Are you already working on an implementation for these things?

sanctuary-def does all the things being discussed. I suggest using that as a starting point and deleting code relating to features you do not wish to provide. I am happy to provide assistance. 😃

Maybe Typescript is another good choice for type checking.

The problem with checking types in runtime is that “typeof” is expensive. Only “isNil” has no overhead. Sancutary is an example of code that is beautiful, but medium useful in practice. This is the slowest functional library in JS. It would be nice to have type exceptions, but only in the case of developer code. There is a special NODE_ENV in React, which in developer mode adds additional hook validation, type validation, etc. Maybe it’s worth doing the same here?

Something like this:

const map = curry2 ((fn, list) => {
  if (process.env.NODE_ENV === 'development') {
    const typeError = checkParameters(...)
    // handleTypeError
  }
  // body of map
})

An additional advantage of this approach is cutting this piece of code through Webpack.

@ku8ar:

The discussion here is about adding more type-checking, not removing it.

To me, path is mostly about gracefully handling the nil values in a chain of props.

In order to have something to talk about, here’s pipe:

function pipeImplementation() {
  //Creates the function that composes the input functions
}

function validateArguments(err) {
  const args = Array.from(arguments).slice(1);
  var idx = 0;
  while (idx < args.length) {
    if (!_isFunction(args[idx])) {
      //To Discuss - I think we should have our own errors for composability purposes. 
      //To Discuss - This doesn't handle fixing the stack trace, which I think we should do and most likely can do. 
      throw new TypeError(
        'TypeError: ' + toString(args[idx]) + ' is not a function\n All arguments ... argument ' + idx + ' blah';
      );
    }
    idx += 1;
  }
  throw err;  // If our validation doesn't come up with a valid reason for the failure, just pass it up.
}

function pipe() {
  var pipedFns = pipeImplementation(...arguments);
  return function() {
    try {
      return pipedFns(...arguments);
    } catch (err) {
      return validateArguments(err, ...arguments);
    }
  }
}

There are a lot of open issues here, and the code is just typed in the textbox so forgive me…

Also pipe is a bit trickier because it returns a function. I think the basic design is there though.

Our validateArguments could handle determining if a reasonable default should be returned instead of throwing an error.

I think we can look at a reusable way to create these validators and ‘compile’ the pieces together. That could lead to additional benefits when it comes to our discussions around dispatching, currying, transducers, and other project wide initiatives.

The happy path is mainly unaffected by the checking of the arguments - it’s only in the case that the inner function throws that we take the validation hit.

@Bradcomp:

Magic bugs are way harder to find than exceptions. Exceptions are obvious. If we start making assumptions based on invalid data I think we are making our own lives and our users lives harder than they need to be.

This is of course the biggest concern with all of this. And I still haven’t wrapped my head around it. I could well see us simply choosing to throw on any unexpected input. I worry about that because I’m often writing for browser-based user interfaces, where code that might bring down the whole system is much worse than code that might have occasional incorrect data. I really don’t like exceptions. But I can easily see us making that choice.