Generate both TS & HM type signatures

[samhh]

via fp-ts#1218

Where TS is:

<A, B>(f: (a: A) => IO<B>) => (ma: IO<A>) => IO<B>

HM would be:

(a -> IO b) -> IO a -> IO b

I think it'd be great if this generated type signatures in both styles with a client-side toggle to globally switch between them, defaulting to TS.

[samhh]

I wanted to learn how to write a parser in Haskell so I've written this over the last two weeks. I'm still working on it, but it already covers probably 95% of type signatures, and the CLI returns an appropriate exit code so it should be possible to use it conditionally, not outputting an alternative style type signature where the TypeScript declaration syntax is currently unsupported.

tshm, example usage:

$ tshm "export declare const f: <A>(a: A) => <E>(b: Either<E, Option<A>>) => A"
f :: forall a e. a -> Either e (Option a) -> a

$ tshm "export type Option<A> = None | Some<A>"
type Option a = None | Some a

I'm going to see if I can integrate it into fp-ts-std shortly.

Edit: It's now implemented in the develop branch. At the moment I'm just - in a very hacky way - parsing the markdown produced by docs-ts and appending the tshm signatures wherever it recognises any.

Edit 2: Now used across fp-ts-std documentation.

[thought2]

I totally agree that the HS style type signatures are nicer to read. But I think that this is highly subjective.
I think even if it could be mapped 100% percent it's hard to justify why adding a second notation to the existing on of the language we use. 95% mapping also really depends, I'd say there's a much larger portion of signatures that cannot be mapped.

Think of "mapped types" {[key in keyof ..]: ...}, indexed types Foo["bar"], conditional types foo extends bar ? baz : boo and many more.

One of the biggest annoyance for me was that parameter's have to be named in signatures. However, they have a semantic meaning, as they can be referenced inside the type signature. E.G. this is a valid type: type T = <T,A>(y : A, x: T & A) => typeof x
The benefit of it may be questioned, but still it's something that would have to be mapped.

Regarding your example, in PureScript I think it's ok in this case to combine a and e in one forall in the beginning. In TS that would be not valid, as the E would be inferred as unknown after the application of the first argument. What if for some reasons I explicitly want const f: <A, E>(a: A) => <E>(b: ....? That would be hard to distinguish in the suggested mapping.

In my view, this raises many many questions. But as I said, I can totally understand the intend. Once I thought that Fn<A,B> = (x: A) => B and then having Fn2, Fn3 etc. would make signatures easier to read but in the end I also dropped that and accepted the existing signatures :)