properly handle currying

[KiaraGrouwstra]

Earlier mentioned here.

We've been using CurriedFunction interfaces, and the current approach had kind of been to, e.g. for an arity-4 function, do the type definition at least 4 times:

• (a,b,c,d) => Res
• (a,b,c): (d) => Res
• (a,b): CurriedFunction2<c,d,Res>
• (a): CurriedFunction3<b,c,d,Res>
  ... simplifying for brevity.
  In case there would be two distinct definitions for a function (e.g. string and array versions), this would further multiply.

This is a bit of a pain point currently, and I hope we could just do one definition in a single CurriedFunction4 definition for cases like that, although currently it appeared parameterized functions (-> using generics) failed to parse for me that way.

Moreover, TypeScript also does not seem to like the idea of having regular 'function' versions side-by-side as well (needed if definitions using generics have to go the traditional route), while I suppose this curried route would currently also lose parameter names (hopefully improved on in the WIP variadic kinds?).

[KiaraGrouwstra]

See #78 (comment)