-
Notifications
You must be signed in to change notification settings - Fork 57
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
complete pipe chains #656
complete pipe chains #656
Conversation
Side note (and not something to solve in this PR per se) - it would be interesting to figure out why pipe completion doesn't work after let extractDeps = rawDeps =>
rawDeps
->String.split(" ")
->Array.map(s => (s->String.trim->Path.parse).name)
->Array.reduce([], (acc, curr) => {
if acc->Array.includes(curr) {
acc
} else {
let _ = acc->Array.push(curr)
acc
}
}) |
@@ -0,0 +1,1970 @@ | |||
Complete src/CompletionPipeChain.res 2:16 | |||
posCursor:[2:16] posNoWhite:[2:15] Found expr:[2:11->0:-1] | |||
Completable: Cpath Value[arr]-> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you change the test so the results are 1 or 2 entries? (e.g. define your own little module)
What's going on is drowned in a sea of results.
I think a concise description of what this does is:
so this is teaching completion the semantics of pipe. |
Correct. |
For the same reason that this does not work: let id = x=>x
let e = id([])-> but this does: let idArray = (x:array<_>)=> x
let e = idArray([])-> Namely, completion for application takes the result type. And without typing the not-yet-compiled code, one cannot deduce the return type of the function. And gets the declared type instead ( |
This is with compiling though. That should make a difference, right? |
You can't compile incomplete code. let e = id([]) it does not mean you know the type of So when you then do this: let e = id([])-> it really does not help to know that something called |
This adds completion for pipe chains, without requiring compilation, when the return type can be inferred for the current pipe chain.
Example:
It handles when the return type is known without having to infer type parameters. Next step would be to handle inferring via type parameters too, but that's a vastly larger thing.
This however should make a lot of workflows more convenient, even in its current state.