Comments (8)
Once we're able to implement curry the above way, hopefully it could be adjusted to account for placeholders as well (CC @ikatyang).
The way I'm imagining this is a three-param function F
getting called would start with a type-level parameter index stack of [0, 1, 2]
. Given F("foo", R.__)
, it'd go over the passed params one by one.
It'd note "foo"
is a real (non-placeholder) param, making for known params { 0: "foo" }
, popping 0
off the argument indices, leaving unfilled arguments [1, 2]
.
At this point it'd note the second param passed is a placeholder, and move its index to the end, yielding a function with upcoming parameter order [2, 1]
.
Implementation todo.
from npm-ramda.
Thanks @tycho01 for the tip. It breaks on some of the types though. I am not sure I understand how it works exactly.
And codegen is a good way to approach. Like you said, most of the work is done 👍 .
So I can also say thanks a lot to the maturing of TypeScript, it was impossible back then without the latest features.
from npm-ramda.
Thank you for bringing this up. By now, your function will in fact compile, which I hope addresses the original scope of this issue.
However, I think you've helped uncover a related issue, as your function, while it compiles, does not get typed correctly as the original (uncurried) version might have.
I've tried this as follows:
let updateBy = R.curry(<T>(pred: R.Pred<T>, val: T, array: T[]): T[] => {
let i = R.findIndex(pred, array);
if (i >= 0) {
return R.update(i, val, array);
} else {
return array;
}
});
let res: number[] = updateBy((n: number) => n > 1, 0, [1,2,3]);
TypeScript currently feels the result should be {}[]
rather than number[]
. Inspecting the lambda function and its curried wrapper reveals what appears to be the issue: the original had its generic, while the curried version does not.
from npm-ramda.
PoC at microsoft/TypeScript#5453 (comment).
from npm-ramda.
I just added support for R.__
and curry. It was built thanks to recursive types. I released an article on Medium about this, if you want to learn how to create your own. The PR was merged into DefinitelyTyped just now and is available at "@types/ramda": "^0.26.1"
.
In fact, we don't need to wait for variadic kinds. Even with variadic kinds, we would still need recursive types to build analysis types. But it would make the development much easier though.
https://github.com/pirix-gh/medium/blob/master/types-curry-ramda/src/index.ts
from npm-ramda.
@pirix-gh: Thanks! I enjoyed the Medium post (link for others).
As you may have noticed, some time has passed since I tried type stuff, meaning a lot of my methods will now seem outdated -- we lacked conditional types / infer
/ Concat
, hence I used stuff like the numerical objects ({ 0: blah }
). I agree variadic kinds no longer matter since Concat
.
I agree the recursive types issue is pretty important, and I hope they'll acknowledge its importance -- losing recursion would essentially kill any advanced types.
Regressions like that were a massive issue for my type repo, particularly as a way to unit test against type non-termination did not exist, meaning things would randomly break on TS upgrades, and it was very hard for me to pin-point which parts broke when and why.
I think you've done a great job by getting your types into DT already, as they will do regression tests against this on PRs. A next step up could be to even get some recursive types into the actual TS unit tests, as this could help raise red flags as soon as a TS dev would try something impacting recursion behavior. Then again, just DT may suffice already.
Is there any particular meaning to analysis types though? I may have been out of the loop for too long.
On another note, I think ahejlsberg's recent PR and @pirix-gh's curry implementation pretty much address the original scope of this particular issue! Let's mark it as fixed. :)
from npm-ramda.
@tycho01 Thank you! I kind of enjoyed myself writing this :)
What I mean by "analysis" types is just types that are "smarter". I like to treat types as if they were functions. As a result, they can be combined together to do input transformation/analysis to output (like we would do in any programming language).
And yes, I'm also happy that the types were accepted. It doesn't seem that they use recursive types there at TS, but now there's no regression possible 🗡️. While I was building these recursive types, TS introduced a new error, so I could feel the urge to publish them. These issues arise because TS tries to compute types that receive parameters that haven't been received yet. Like for example:
type Concat<T1 extends any[], T2 extends any[]> =
Reverse<Cast<Reverse<T1>, any[]>, T2>
Complains that "Type instantiation is excessively deep and possibly infinite". But in fact it just assumed that it's infinite (because of any[]
). It should rather wait to receive T1
and T2
before screaming at us... Bit irritating. It could wait for the parameters to be provided and only then compute Concat
:
Test00<[any, number], []> // no error
Test00<[...any[]], []> // error, infinite
I described a valid workaround for this at the top of the repository... for now. But we won't want this workaround if recursive types become more mainstream, it's kind of ugly and unnecessary.
So I started formulating a request here microsoft/TypeScript#30188
After a long talk with Nathan about this, I will propose the team to stop computing types that are waiting for parameters (on this same issue soon).
from npm-ramda.
@pirix-gh:
Sounds good, if they take it we're good!
On the eager depth check, is the workaround that Tail
or HasTail
, and what's the issue with the workaround for end-users (who presumably won't have to see the internals to use curry
)?
(If necessary, other workarounds might be possible like going through ReadonlyArray
types like { 0: foo, length: 1 }
.)
On another note, once Ramda types can be expressed as such analysis types, especially wrapped in a Curry<>
like yours, I imagine the demand for a codegen-based approach as currently used by the present repo (based on the awesome work by @ikatyang!) will likely diminish. That was kind of my goal, though things hadn't really progressed enough for it to be within reach at the time.
from npm-ramda.
Related Issues (20)
- npm-ramda motivation HOT 4
- R.Path - Typescript error for an array of objects
- `prop` does not work with optional keys HOT 1
- curry type
- `pipeWith` is missing
- Using groupBy with path always fails typecheck
- mergeDeepRight returns incompatible if objects contain array props HOT 1
- Add dissoc(prop: number)
- `transduce` and `into` are declared with `any` and for narrow use cases in general
- R.evolve is not deriving type from curried evolver
- Generics lost on currying for higher-order functions HOT 1
- type into in typescript
- How should we type lift?
- How to type pathOr?
- Expected 0 arguments, but got 1 HOT 3
- Evolve typings
- Typescript 4: Solve a lot of our problems
- Ramda 0.27 HOT 1
- Arity limitation for R.compose's rightmost function?
- Adding support for type guards to `partition` function.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from npm-ramda.