Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proper fantasy-land support #186

Open
SimonMeskens opened this issue Jul 30, 2017 · 16 comments
Open

Proper fantasy-land support #186

SimonMeskens opened this issue Jul 30, 2017 · 16 comments
Assignees

Comments

@SimonMeskens
Copy link

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
Copy link
Member

KiaraGrouwstra commented Jul 30, 2017 via email

@SimonMeskens
Copy link
Author

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
Copy link
Member

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
Copy link
Author

This issue recently got marked as done for 2.5: microsoft/TypeScript#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 gcanti/typelevel-ts#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
Copy link
Member

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 microsoft/TypeScript#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 microsoft/TypeScript#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 (microsoft/TypeScript#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 microsoft/TypeScript#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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

Sure, just tell me which repo to follow!

@gcanti
Copy link

gcanti commented Jul 31, 2017

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
Copy link
Member

KiaraGrouwstra commented Jul 31, 2017 via email

@gcanti
Copy link

gcanti commented Jul 31, 2017

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 gcanti/typelevel-ts#7

@KiaraGrouwstra
Copy link
Member

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
Copy link
Member

@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 microsoft/TypeScript#17456 filed earlier that you guys figured out earlier. After that's resolved I'm curious as to what challenges might remain.

@gcanti
Copy link

gcanti commented Aug 2, 2017

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

@KiaraGrouwstra
Copy link
Member

@gcanti: Thanks! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants