Fantasy-land compatibility

[SimonMeskens]

Big fan of the current currying initiative, but it breaks even more compatibility with Fantasy-land I bet. Is there anything we can do? Maybe I should do a PR where I provide namespaced ("fantasy-land/map") properties for everything?

I think Ramda can handle those. They wouldn't be for normal consumption, but for compatibility with duck-typing fantasy-land libraries, like Ramda.

[raveclassic]

Well, I think currying does not cause compatibility regression because signature of a function is preserved, only the way of applying arguments changes.

Even more sanctuary, which is meant to be fully aligned with fl-spec, provides only curried functions.

And even more, afaik @gcanti stated that fp-ts won't be aligned with fantasy land.

Anyway I believe the PR you are mentioning would be awesome!

[SimonMeskens]

A curried function does not have the same signature as an uncurried one.

Sanctuary doesn't use any curried functions at all for their fantasy-land compliance, so I'm not sure what you're talking about there.

@gcanti stated that aligning with fantasy-land is something we can debate, so I opened this issue

[SimonMeskens]

I'd like to note that the namespaced functions were provided exactly for the issue we're running into and should neatly fix the issue.

[raveclassic]

Sorry, I mentioned sanctuary from memory and didn't mean to disinform :)

Anyway I'm all for aligning with the existing fl-spec, the question is what we can do to achieve this.

[SimonMeskens]

Adding namespaced functions to any consumable datatypes should work.

[gcanti]

@SimonMeskens @raveclassic AFAIK the ecosystem around FL is fragmented. Before any technical discussion, could you please explain the motivation and the practical benefits of such a compatibility?

[raveclassic]

@gcanti I don't have any rich experience with FL so my point is mostly because, well, it's a spec and that's all

[SimonMeskens]

I just want to be able to use Ramda and/or Sanctuary to consume the types in fp-ts. Maybe that's expecting a little too much out of TypeScript right now?

[SimonMeskens]

And again, I don't think it should compromise fp-ts in any way, so I'm totally on-board with the current refactor towards currying. If it's a choice between FL compatibility and certain fp-ts features, the fp-ts features win every time.

[gcanti]

I just want to be able to use Ramda and/or Sanctuary to consume the types in fp-ts

@SimonMeskens do you mean consumable by a JavaScript project? I ask because from a TypeScript and in particular from a fp-ts point of view both ramda and sanctuary, being JavaScript libs designed for JavaScript, seem not attractive so maybe I'm missing something

[SimonMeskens]

Well, Ramda and Sanctuary are functional equivalents of libraries such as lodash and Underscore. It stands to reason that someone will eventually make a TypeScript equivalent (and in fact, @tycho01's Ramda typings are the closest thing to such an effort right now). All of them (except Underscore) work in the same way by using FL to consume datatypes.

I'd say there's not a lot of fragmentation there. The issue right now, is that datatypes are just barely usable in TypeScript, as fp-ts shows, but the libraries that consume them are clearly still too complex to type.

[KiaraGrouwstra]

the libraries that consume them are clearly still too complex to type

Yeah, on the Ramda TS side there's still a barrier to this interop. To meaningfully calculate return values, Ramda would need to calculate them from the typings of the method implementations. In my ears that implies microsoft/TypeScript#6606.

I ask because from a TypeScript and in particular from a fp-ts point of view both ramda and sanctuary, being JavaScript libs designed for JavaScript, seem not attractive

I believe what you're saying is typings written as separate type definitions are not at par with the inference that full TS libs could. There is truth to that, with !, type guards and expression level constructs not exposed at the type level (function application, rest/spread etc.). I'm not confident that's the argument you're making, but I think the type level reaching feature parity is just a question of time -- and I for one would gladly help push it there.

[SimonMeskens]

@tycho01 Here's the interesting question: do you think we could write a functional library, such as Ramda, today, in TypeScript (aka, some functions may be written differently, to better support type inference, like fp-ts is doing)?

[KiaraGrouwstra]

I don't think it solves things like heterogeneous map. I'm trying to fix the TS compiler though. The number of TS issues I care about are actually somewhat limited:

• 6606-type-level-function-application
  • 12424 (comment) evaluation order issue
• 5453-variadic-kinds:
  • capture ... params as if they were regular (array) params
  • [...a]
  • fn(...args)
• 16072 generics erased
• 6229-known-length-tuples (WIP at Make tuples have known length microsoft/TypeScript#17765)
• 17086 type fails in function

[gcanti]

some functions may be written differently

Indeed. @tycho01 is doing an awesome job with npm-ramda and typical, however most of the problems simply vanish if you design the APIs for TypeScript in the first place. fp-ts is first of all a TypeScript library, written in TypeScript and for TypeScript users. Also it's mostly a porting of PureScript libraries and requires pretty standard type system features. The super hacky part is faking HKTs