Proper fantasy-land support

[SimonMeskens]

The Fantasy-land spec asks for namespaced methods, like "fantasy-land/map" instead of "map". Ramda supports this, but npm-ramda does not. I'm currently adding fantasy-land support to certain libraries and I'd like to use them with Ramda. Should I PR in these extra interfaces?

Also of note, but your fantasy-land interfaces don't actually work, because you didn't specify them as proper HKTs. There are several ways to go about this, best example probably being https://github.com/gcanti/fp-ts (which unfortunately doesn't support the proper namespaced methods either, but I'm sure that could be fixed)

[KiaraGrouwstra]

Right, I tried these fantasy land types as a poc and later got corrected in the fantasy land typescript thread about the HKTs, but hadn't retried. Open to PRs.

For the dispatching there is no general way about it right? As in, I guess the return type depends on the implemention of whatever library exposes a method that way? So you may need to include types from those or something. I can't think of better alternatives so I'm open to the idea.

P.S. you'll find currying still sucks atm. Curried versions would need to get mixed in with the other typings with matching first param set or either option would get skipped over.

[SimonMeskens]

Yeah, the whole situation is still a bit of a mess. There are a few really important fixes coming in 2.5 that would allow us to type some parts of currying. HKTs are possible, but as you noted, the libraries that have HKTs would still need to tag them as such, etc.

I'm working on a few PRs for other repos first, after that I'll look into some possible PRs for this repo too.

[KiaraGrouwstra]

I'd be cool with bumping up the version here to 2.5 already, could relegate the old version to a separate branch if needed.

There are a few really important fixes coming in 2.5 that would allow us to type some parts of currying.

Which? The roadmap doesn't list much. I demonstrated a PoC for a proper (no overloads, no static return types) curry here, but that is quote "not actively being worked on".

[SimonMeskens]

This issue recently got marked as done for 2.5: https://github.com/Microsoft/TypeScript/issues/10727

Which seems like it might have spread type syntax for 2.5? (note that this is not nearly the same as variadic kinds)

And then there's https://github.com/gcanti/typelevel-ts/issues/8, where someone is working on a generic function type, which would add a few new tricks to our bag. That implementation relies on two bugs, one fixed already for 2.5, one marked for 2.5.

It seems like gcanti/fp-ts and gcanti/typelevel-ts are the playgrounds to watch for bleeding edge techniques. Note that you probably don't ever want to have a dependency on typelevel-ts (your users wouldn't enjoy that very much), but instead, you can usually figure out a solution using that library, then transform that general solution into a specific one for your use-case, which is what I've been doing for certain PRs.

[KiaraGrouwstra]

I see. For objects it seems sugar for Overwrite / Omit. To be fair his thread predates it, and one might not have been able to put that in a signature position on destructuring statements, I dunno. rest(T, x) clashing with function syntax seems unfortunate for https://github.com/Microsoft/TypeScript/issues/6606 I guess.

On tuple types type-level spreads would actually still have been significant for being the first way to manipulates array types, but I suppose that's relegated to that 'not actively worked on' 5453. Oh well. Fortunately as a workaround ArrayLikes can be manipulated.

If any of that helped curry, you'd be good now, so curious as to your idea. Ramda typings have been using ugly overloads for it, which don't use objects (or tuples), so I dunno if it'll help. The overloads made for terrible maintenance/legibility, so we've been trying to move to codegen for that, with an existing attempt and currently an imminent PR from #173.

My PoC in 5453 replaced those overloads with dynamically calculated result types, which largely relied on 5453 to carry the param types into a result type, then 6606 to apply that to get the actual result for those params. But yeah, hard to try out if it's nicer in practice since we ain't there yet.

It seems like gcanti/fp-ts and gcanti/typelevel-ts are the playgrounds to watch for bleeding edge techniques.

I hadn't seen typelevel-ts yet. But did you see his source links? ;) Guess I'll follow it for issues posted. I'd considered similarly publishing my gist as a repo as well (and have been converting it to one with separate files and tests, offline), but I've been kinda on the fence over it. Evidently there's a few features I'd really wanted from TS still, but on the other hand, I'd rather hope for (part of?) the types to become part of TS proper for the purpose of typing its standard library. Obviously not mutually exclusive, but I also haven't had much time to improve testing, not to mention as it stands Ramda wouldn't benefit too much yet.

Looks like a main difference between mine and his is the use of the chain-based approach from https://github.com/Microsoft/TypeScript/issues/14833 for recursion rather than the increment-based approach I'd used for the purpose of tuple iteration though.

Actually curious as to @gcanti's considerations there. I needed numbers as they made for the tuple index, so I kinda had to. I considered the chains inelegant in their O(n) complexity as well. Could be they're not bound to a white-listed set of index numbers though, which is admittedly a downside on my approach. Worse, though it worked in types, it failed if those types were used in functions though (https://github.com/Microsoft/TypeScript/issues/17086), so if these somehow survive that transition, that'd be awesome.

you probably don't ever want to have a dependency on typelevel-ts (your users wouldn't enjoy that very much)

My plan had been to wait out for TS to get a full feature set (e.g. fix issues noted in https://github.com/Microsoft/TypeScript/issues/16392) then retype Ramda and TS's lib.d.ts with dependent types, which is essentially what you're saying here. So I'd wonder, what of it?

I realize that the more you calculate, the more performance could be used. Then again, the flip-side of that is that the overloads TS now force libs to use actually seems worse than O(n) for performance. So that might well be a win.

[SimonMeskens]

did you see his source links? ;)

Yeah, I'm aware of who you are :). I keep running into your posts all over the place. I'm just saying that the people that are doing high-complexity typing seem to all end up posting issues on gcanti's repos, so there are interesting new developments there from time to time.

Maybe we should start a small community somewhere. Right now, if you need a complex type, it's either do-it-yourself or a long google slog trying to find other people who had similar issues. Most of the information is spread over a bunch of GitHub issues everywhere. Maybe I'll start a repo with example code for complex mapped type solutions, HKTs, typelevel-programming, etc. We could use the issue section to figure out solutions to general issues.

[KiaraGrouwstra]

Yeah fair enough, thanks for the links -- guess I was so busy ranting at the TS github I hadn't looked outside it anymore much.

Maybe we should start a small community somewhere.

I don't mind weighing in if you guys have typing issues. Hopefully following that typelevel-ts will help me see more relevant threads. If there's some gitter/slack on this that's cool to me (though I'm not about to read all chat at the main TypeScript gitter). Or ping me on github directly I dunno.

In all likelihood I'd somehow figure ways most arbitrary issues would be fixed by 6606 and hope the TS team would feel convinced. Hasn't been working great so far. I might need to get some spare time and actually try making some PRs myself at one point instead of complaining. The funny part is I'm not even using TS atm, just got kinda deep into typing challenges after typing Ramda frustrated me enough to look for solutions. Too bad it's less useful professionally than for open-source! :P

complex mapped type solutions

My view has kinda been I wouldn't wanna require end-users to know the ins and outs of TS, as I'd rather just have type inference in the lower-level libraries (stdlib, ramda, whatever) take care of things. Hopefully if the larger patterns get into type libraries (like his), others would no longer need to come up with them anymore. But yeah, I guess that might take some docs and lib awareness too.

[SimonMeskens]

My view has kinda been I wouldn't wanna require end-users to know the ins and outs of TS

The problem is that I'm one of those people trying to write the lower-level stuff and I don't know what to do half of the time :). Creating just a slack or gitter doesn't sound very useful as that requires people to check in, but I might start a repo.

I'll be starting some integrations with Ramda soon, if I find any new tricks that might be useful, I'll send some PRs your way.

[KiaraGrouwstra]

Sure, just tell me which repo to follow!

[gcanti]

Maybe we should start a small community somewhere. Right now, if you need a complex type, it's either do-it-yourself or a long google slog trying to find other people who had similar issues.

@SimonMeskens That would be great. Feel free to open issues on typelevel-ts for discussions or, if you create a new repo, please let me know so I can follow

Actually curious as to @gcanti's considerations there

@tycho01 which types are you referring to? I'm trying to play with your gist, but I got many errors and Code Helper is hanging with 100% CPU (ts 2.4.2). Is it an issue with my setup?

[KiaraGrouwstra]

@gcanti:

Nope, I got that as well as it grew over time. It ends up sorta working, but slow. Sucks in playground, vscode and compiler atm, but I don't think all types are equally at fault, so I may need to further narrow that down.

I forgot if there were still types in there using 2.5 that could cause errors, though I was still using part of that. But 2.5 was a reason to start switching to using it outside of playground.

I converted the test types to actual compile time tests, but something was still making the compiler hang on the full thing. I'd still need to test that for a bit more I guess. Should probably split things up more too.

Errors, there were definitely more from that number indexing errors on generics for example as well. A few others too; it started as more of an experimental testing ground and some parts admittedly aren't working yet.

I mostly tried to file minimum repros for those and list them in my overview thread as a kind of checklist. I don't think I managed to quarantine all of the issues yet though. Heck, even with performance issues I still added some more ideas anyway. A few needed unimplemented features so couldn't compile yet anyway. But yeah, that's cheating, and workarounds usable today might at least get us somewhere.

So yeah, I wasn't exactly bringing much into production yet. For context though, for Ramda which I wanted to type much of it still seemed unusable. I guess there was overwrote/omit, but the fun stuff started at iteration, which still broke in functions.

Overloads from e.g. currying make the typings even more painful atm (like noted in https://github.com/gcanti/fp-ts/issues/153), but guess that still needs a bit more functionality. I guess I felt it was hard to apply much of my progress before getting more of the issues resolved.

I'm glad fp-ts has done a better job at getting production oriented momentum for advanced typings already. I guess I hadn't been paying attention enough, partly fearing there might only be limited overlap, as I hadn't really done much with HKTs. I suppose on monads iterating to calculate value-level result types might be less of a thing, while preventing info loss like that would be essential to type e.g. that partial-lenses.

which types are you referring to?

Mostly _3 vs just 3 for iteration.

On Jul 31, 2017 2:04 PM, "Giulio Canti" notifications@github.com wrote:

Maybe we should start a small community somewhere. Right now, if you need a complex type, it's either do-it-yourself or a long google slog trying to find other people who had similar issues.

@SimonMeskens https://github.com/simonmeskens That would be great. Feel free to open issues on typelevel-ts for discussions or, if you create a new repo, please let me know so I can follow

Actually curious as to @gcanti https://github.com/gcanti's considerations there

@tycho01 https://github.com/tycho01 which types are you referring to? I'm trying to play with your gist, but I got many errors and Code Helper is hanging with 100% CPU (ts 2.4.2). Is it an issue with my setup?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/types/npm-ramda/issues/186#issuecomment-318976215, or mute the thread https://github.com/notifications/unsubscribe-auth/AC6uxWtmdbRze6KFGCG_b_nv3FL4Nc_Sks5sTW5ngaJpZM4Onf5b .

[gcanti]

Nope, I got that as well as it grew over time. It ends up sorta working, but slow. Sucks in playground, vscode and compiler atm, but I don't think all types are equally at fault, so I may need to further narrow that down.

That's unfortunate, I love the work you are doing with these types, let me know if I can help somehow.

Mostly _3 vs just 3 for iteration

Yeah, using actual integers would be great, though I got some issues even with this basic type https://github.com/gcanti/typelevel-ts/pull/7

[KiaraGrouwstra]

That's unfortunate, I love the work you are doing with these types, let me know if I can help somehow.

Thanks, that's encouraging; I'll try and find time to get it usable again and put it on. I'm cool with merging the good bits into yours as they get ready/useful.

Lemme check 7 there.

[KiaraGrouwstra]

@gcanti: I tried to organize/test/clean what I have, and now put it online at https://github.com/tycho01/typical.

As the current goal is rather to use it to explore the boundaries of what we can do rather than for it to be used in its current state as a dependency like typelevel-ts, I've let failing bits as-is for now rather than commenting them out, so as to show current problems to allow looking for a way forward. As it's just a type-level library, tests are run just by running the compiler on spec files.

I think right now quite some of the issues are caused by that https://github.com/Microsoft/TypeScript/issues/17456 filed earlier that you guys figured out earlier. After that's resolved I'm curious as to what challenges might remain.

[gcanti]

@tycho01 Excellent, I'll put a link to your repo in the README of typelevel-ts

[KiaraGrouwstra]

@gcanti: Thanks! :)