reconsider TypeScript support

[davidchambers]

Update (2017-10-03): I have updated chainCurriedFlipped to delay the introduction of B, as suggested by @gcanti. I have also updated the results to correct an unrelated error I made initially (providing arguments to chainCurriedFlipped in the wrong order).

---

@miangraham and I have been working on #431 for several weeks. We've made good progress despite the impedance mismatch between the two type systems.

I had trouble defining types for chain. To simplify the task I specialized the type signature:

chain :: (a -> Array b) -> Array a -> Array b

I couldn't get this to work. I asked for help in the TypeScript room on Gitter and @sluukkonen provided helpful responses (including a link to microsoft/TypeScript#17520). I learnt that certain combinations of removing currying, changing the argument order, and replacing id with x => x (!) would appease the compiler.

I defined four versions of “chain” to discover the magic combination:

const xss = [[1, 2], [3, 4], [5, 6]];

function id<A>(x: A): A { return x; }

function chain<A, B>(f: (x: A) => Array<B>, xs: Array<A>): Array<B> {
  return Z.chain(f, xs);
}
function chainFlipped<A, B>(xs: Array<A>, f: (x: A) => Array<B>): Array<B> {
  return Z.chain(f, xs);
}
function chainCurried<A, B>(f: (x: A) => Array<B>): (xs: Array<A>) => Array<B> {
  return xs => Z.chain(f, xs);
}
function chainCurriedFlipped<A>(xs: Array<A>): <B>(f: (x: A) => Array<B>) => Array<B> {
  return f => Z.chain(f, xs);
}

Results of applying functions to id and xss

Function	Result	Value/Explanation
chain	❌	Argument of type <A>(x: A) => A is not assignable to parameter of type (x: {}) => {}[].
chainFlipped	✅	[1, 2, 3, 4, 5, 6]
chainCurried	❌	Argument of type <A>(x: A) => A is not assignable to parameter of type (x: {}) => {}[].
chainCurriedFlipped	✅	[1, 2, 3, 4, 5, 6]

Results of applying functions to xs => xs and xss

Function	Result	Value/Explanation
chain	✅	[1, 2, 3, 4, 5, 6]
chainFlipped	✅	[1, 2, 3, 4, 5, 6]
chainCurried	❌	Argument of type (xs: {}) => {} is not assignable to parameter of type (x: {}) => {}[].
chainCurriedFlipped	✅	[1, 2, 3, 4, 5, 6]

My reactions to the tables above:

• 😱 id and xs => xs are not equivalent
• 😞 TypeScript does not like curried functions
• 😠 TypeScript's limitations affect API design

I'm concerned that even if we succeed in approximating type classes with interfaces, complications such as these will make Sanctuary and TypeScript an awkward couple. What do others think?

Sanctuary was designed as a JavaScript library. Had we set out to create a functional programming library for TypeScript it's likely we would have done things quite differently. I'm concerned that treating both JavaScript and TypeScript as first-class targets will lead to compromises. I'd like to continue to focus on making Sanctuary a principled, capable JavaScript library. Perhaps the TypeScript type definitions should live elsewhere so TypeScript's limitations won't influence the design of our API.

[gcanti]

chainCurriedFlipped works better if typed like this

declare function chainCurriedFlipped<A>(xs: Array<A>): <B>(f: (x: A) => Array<B>) => Array<B>

Results: 3 cases out of 8 require explicit type annotations

const id = <A>(a: A): A => a

declare function chain<A, B>(f: (x: A) => Array<B>, xs: Array<A>): Array<B>
declare function chainFlipped<A, B>(xs: Array<A>, f: (x: A) => Array<B>): Array<B>
declare function chainCurried<A, B>(f: (x: A) => Array<B>): (xs: Array<A>) => Array<B>
declare function chainCurriedFlipped<A>(xs: Array<A>): <B>(f: (x: A) => Array<B>) => Array<B>

const xss = [[1, 2], [3, 4], [5, 6]]

const r1 = chain(id, xss) // ERROR, chain<number[], number>(id, xss) works
const r2 = chainFlipped(xss, id) // ok
const r3 = chainCurried(id)(xss) // ERROR, chainCurried<number[], number>(id)(xss) works
const r4 = chainCurriedFlipped(xss)(id) // ok

const r5 = chain(x => x, xss) // ok
const r6 = chainFlipped(xss, x => x) // ok
const r7 = chainCurried(x => x)(xss) // ERROR, chainCurried((x: number[]): number[] => x)(xss) works
const r8 = chainCurriedFlipped(xss)(x => x) // ok

[davidchambers]

Thanks very much for the improvement, @gcanti.

Results: 3 cases out of 8 require explicit type annotations

Is this common in the TypeScript world? Have you spent enough time with TypeScript that you reason about when hints will be necessary, or do you assume that types will be inferred and find it frustrating when they are not? I've never worked on a TypeScript project so I'm keen to hear from you and others with relevant experience.

[gcanti]

I design the API specifically in order to maximize type inference, though some cases are still frustrating (the identity function above being an example)

[jasonkuhrt]

@davidchambers I know you used to be more enthusiastic about FlowType, where do you stand these days? The project picked up some steam in the last quarter or two.

[CameronFraser]

+1 for flow. The windows support is still trailing, but it is picking up a lot of steam. Both are great options though. With babel 7 you can use TS as a type checker like flow instead of a compiler.

[davidchambers]

@jasonkuhrt and @defdata, I'm pleased to hear that Flow is gaining momentum. :)

Can Flow describe functions such as S.chain? If so we should create a library definition for Sanctuary.

[cortopy]

@davidchambers looking at your typescript definitions looks like you did a lot of work even if you weren't entirely sure it could be done. Thank you!

I work in typescript projects and I wouldn't like this to go to waste even if you decide TS/Sanctuary are not a good match.

What about publishing the types in the official TS repo for now? This way it would be easier for the community to test types and even make contributions by just doing yarn add @types/sanctuary

[cortopy]

Just following on my last comment, I have published the types in DefinitelyTyped.

The first commit was just a port of what @davidchambers had started (thanks again for that!), except I made all the changes that tslint asked me for and some rather minimalist tests.

Beyond that, I've started to expand the declarations. Today I moved all methods into namespaces to be able to work with environments. The create method is now fully typed! (merge request now pending)

[davidchambers]

The create method is now fully typed!

That's fantastic, @cortopy. Well done!

I apologize for my lack of engagement in this thread. I've been busy with other Sanctuary tasks, and in recent weeks with other life tasks. I'm thrilled to see that the effort @miangraham and I spent working on TypeScript type definitions has not gone to waste. :)

[anurbol]

Hi there! I liked so much the philosophy and description of Sanctuary. As much as I liked it, I was disappointed by the current type-checking system. While you obviously have done great work making it, it seems it is a wrong way, unfortunately. Typescript is trending so much. Unfortunately I am not able to contribute to this great library yet, but I just wanted to give my opinion about type system: Typescript definitely should be first-class-supported, this way I think this repo could gain 10x more stars.

For now I personally can not even start to work with Sanctuary because of the lack (AFAICT) of TS support. But again, your vision, @davidchambers is oh so appealing... but type checking is disappointing..

Also, I personally think type-defs are wrong way in terms of both correctness and maintainability, it is much easier to khm.. rewrite the code to typescript.

BTW, Sanctuary has to deal with very complex types. If someone is interested I have a library for testing such complex types: https://github.com/qurhub/qur-typetest, helps me a lot.

[davidchambers]

For now I personally can not even start to work with Sanctuary because of the lack (AFAICT) of TS support.

Have you tried DefinitelyTyped, @anurbol?

Also, I personally think type-defs are wrong way in terms of both correctness and maintainability, it is much easier to khm.. rewrite the code to typescript.

Once TypeScript can express Functor f => (a -> b) -> f a -> f b, I'll certainly consider it! I'm not holding my breath, though. 😜

[gabejohnson]

@davidchambers have you discussed collaboration with @gcanti and @alexandru on a shared HKT lib?

I believe https://github.com/gcanti/fp-ts and https://github.com/funfix/funfix share a common approach.

For reference:
funfix/funfix.js#104
gcanti/fp-ts#252

[anurbol]

@davidchambers I am sure Typescript is capable of handling the most complex scenarios possible.

I apologize in advance, because I am not familiar well with haskell-like syntax except I've read "types" section of the Sanctuary docs, I am also just in the beginning of my FP journey (this is the reason why I want to choose the best FP library to start with), but if I understood correctly

Functor f => (a -> b) -> f a -> f b is the same as the following in TS

type Functor<T> = (arg: T) => any

/* The following is equivalent to (a -> b) -> f a -> f b */
<A, B>( arg: (a: A) => B ) => (arg: Functor<A>) => Functor<B>

BTW. Thanks to your challenge, I got familiar with Haskell syntax, and I must say it is much more concise and elegant... i.e. I found out that I don't really know what argument names like arg: in the above code are actually doing (they are unnecessary noise). However, I think, probably Typescript's type system is more powerful than Haskell's one. E.g. I doubt (googled briefly) haskell has conditionals like type Foo<T> = T extends string ? string : T extends number ? number : never and the reason is: TS was created to be capable of producing types for any case in such a dynamic language like JS.

[Bradcomp]

@anurbol I think you have a little too much faith in Typescript. I use TS professionally at my job, and it lacks a lot of features that would make functional programming feel natural. One of these is Higher Kinded Types, which TS does not support directly, although there are some work arounds (see below): microsoft/TypeScript#1213

Haskell's type system is strictly more power than TS. You can represent any TS construct in Haskell's type system, but the opposite is not true.

What you have above assumes that Functor is a type, whereas it is in fact a type class, more similar to an interface than a class or a type.

This means that if you have three generic types: A<T>, B<T>, and C<T> and you want them all to be functors, the map function (forgive my pseudo code here) needs to be generic over both T and [A|B|C] such that

map(T -> U)(A<T>) => A<U>
map(T -> U)(B<T>) => B<U>
map(T -> U)(C<T>) => C<U>

We need to be able to represent that (and even more complicated notions) in the type system, without defaulting to using any.

I would suggest playing around with implementing it yourself, and then taking a look here: https://github.com/gcanti/fp-ts to see one way it's been tackled.

I would also suggest taking a look at the types @davidchambers posted above. You can see that the developer simply punted on the issue of Higher Kinded types, leaving the actual type checking to Sanctuary.

In the past few months I have run into numerous issues in typescript trying to do things that would be trivial with Sanctuary. In addition, there are many errors that it won't help you catch at all. For instance, exceptions aren't represented in the type system, so it's not possible to know if a particular function can blow up your program.

In addition, the fact that Sanctuary checks types at runtime gives it even more power. I have tried to use decorators to modify the type of a method at runtime. It's impossible in Typescript because TS only has compile time information. Sanctuary doesn't have this limitation.

If you're truly interested in using functional programming in JS, I don't think Typescript is in any way ideal. I would suggest using regular JS along with libraries like Sanctuary or Ramda, or else go whole hog and check out a language like Elm or Purescript which have been built from the ground up to facilitate strongly typed functional programming that compiles to Javascript.

[masaeedu]

@anurbol A simple definition of Functor in pseudo-TypeScript would be:

type Functor<F> = { map: <A, B>(f: (a: A) => B) => (fa: F<A>) => F<B> }

In other words, a map function, that for some F, can convert any A -> B into an F<A> -> F<B>. Things like this are inexpressible in TypeScript, due to the lack of higher kinded types, partial type application, generic values, and numerous other features. There are various workarounds that work to various extents, but they add complexity and detract from the simple, beautiful shape of the abstractions we want to work with.

If you're interested in good TypeScript support for functional programming libraries (something I think many users are very interested in!) you should find the relevant issues in the TypeScript issue tracker and provide your feedback.