Proper fantasy-land support #186
Comments
|
Right, I tried these fantasy land types as a poc and later got corrected in
the fantasy land [typescript thread](fantasyland/fantasy-land#140) 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](https://github.com/types/npm-ramda/blob/master/index.d.ts#L979-L985) in with the other typings with matching first param set or either
option would get skipped over.
|
|
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. |
|
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.
Which? The roadmap doesn't list much. I demonstrated a PoC for a proper (no overloads, no static return types) |
|
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. |
|
I see. For objects it seems sugar for 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 If any of that helped 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.
I hadn't seen 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
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 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 |
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. |
|
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.
I don't mind weighing in if you guys have typing issues. Hopefully following that 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
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. |
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. |
|
Sure, just tell me which repo to follow! |
@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
@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? |
|
@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 gcanti/fp-ts#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
<#186 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AC6uxWtmdbRze6KFGCG_b_nv3FL4Nc_Sks5sTW5ngaJpZM4Onf5b>
.
|
That's unfortunate, I love the work you are doing with these types, let me know if I can help somehow.
Yeah, using actual integers would be great, though I got some issues even with this basic type gcanti/typelevel-ts#7 |
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. |
|
@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 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. |
|
@tycho01 Excellent, I'll put a link to your repo in the README of typelevel-ts |
|
@gcanti: Thanks! :) |
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)
The text was updated successfully, but these errors were encountered: