Wishlist: AMD modules and Ramda.js

[semmel]

In the future will infernu analyse code written using Ramda.js (https://github.com/ramda/ramda) as functional library? Their functions are all documented with type signatures, e.g. @sig a -> (* -> a) for the always or constant function:

_curry1(function always(val) {
  return function() {
    return val;
  };
})

The other thing is AMD modules. It would be nice to have those of course, since all my code is contained in such a module, infernu bails out immediately with

Unbound variable: 'define'

Greetings Semmel

[sinelaw]

Short answer: hopefully and yes.

Generally there are several things libraries like Ramda use that Infernu currently doesn't support:

1. Optional arguments.
2. The magical arguments value.
3. More sane type signature printing.
4. (probably) User-supplied type annotations (aka "type ascriptions").

All of the above are in the works, I'm currently looking at a major rewrite of the type checker (for many different reasons).

If we put aside _curry1, specifically the 'always' part is typed by infernu as: forall a. a -> (() -> a (it will print it as b -> (() -> b), but it's the same). Note that it requires zero arguments for the resulting function. We could have infernu allow arbitrary "trailing" arguments to all functions, but that makes cringe (not as safe).

Another function I looked at is _slice. It switches over arguments.length, so I had to remove that part and only check the default case (all args supplied). What I got was:

/*       _slice : (( { get length: Number
                     , get =[]: Rfq.(Number -> c) | d}
                  ,Number
                  ,Number) -> [c]) */

Translation: given any object that has a .length number property, and a [] accessor that, given numeric indexes returns a value of type c, and given two numbers, it returns an array of type [c]. That's interesting because the type signature here proves that _slice must be copying data into an array! It doesn't return the same type of object that it received.

So although the type is correct, the user may want to hide those details and limit it to a less general type: [a] -> Number -> Number -> [a] (when curried). For that we need (4) from above, user-supplied type annotations.

---

As for modules, yes, they should be supported in the future, and it should relatively straightforward to support them. I've prioritized that lower until the dust has settled on the type system.