Generate TypeScript definitions from docs

[yosbelms]

Surfing the web I stumbled upon this Hindley-Milner parser written in JS. I immediately saw the possibility of to generate the TS definitions -and possibly Flow- from Ramda docs. What's your thoughts about it guys?

[CrossEye]

I think this would be a fantastic idea. I know little about TS or Flow definitions, but if they could be generated from our signatures, it would be a huge win, even if our signatures need some updating to make it work.

But it would take someone who understands TS/Flow pretty well to implement this, I think. Any volunteers?

[yosbelms]

Contributors of https://github.com/types/npm-ramda can be a great help on this. They know enough HM and TS 💪 I think.

[CrossEye]

@tycho01: What do you think? Would this be a good idea? Would you be interested in participating?

[KiaraGrouwstra]

This is a fun idea.

It begs the question why the types in npm-ramda no longer look like the signatures though, and that I know -- to improve type inference and safely handle currying/placeholders, at the cost of semi-legible source templates yet codegen results unsightly compared to their JS counterparts.

The Hindley-Milner type signatures definitely served as the obvious starting point, but TS typings had their own challenges, which the signatures don't evidently help address.

In Haskell we have data classes, and HM is fine, but with a structural typing system like TypeScript, preserving object key info is essential to safely distinguish say a { foo: string, bar: number, baz: string } from a { name: string, id: number }.

Now, if one were to navigate such an object using e.g. R.path, suddenly the result will depend on your keys as well (is this string a "foo" or a "bar"?), and quickly your challenges explode beyond what HM handles.

Things I consider remaining challenges in typing Ramda, blocked by present language features:

• pipe / compose losing generics of input functions. I think there was finally a PR at TypeScript for this, but I forgot where.
• better inference to negate the need for explicit type hints.
• better typing map for heterogeneous objects/tuples.
• better typing path / lenses.
• recursive type approaches to replace codegen, which kinda blows for currying / placeholders / path / lenses.
• handling HKTs, allowing one to define functions for a HKT in one repo (R.map), and functor implementations that can properly use it in another.

I haven't been doing much TypeScript anymore (now Scala/Python at work, Haskell at night), but there's nothing to say you should take a similar focus as others!

On typing Ramda, I'd be kinda interested to see/try a serious attempt using Flow -- I think its $Call functionality would solve much of the blockers experienced with TypeScript.
I've yet to see functional expressiveness + structural typing inference in any other language / repo / typing -- but Flow typings to Ramda seems like it could actually pull this off.