Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Provide type information to rules #41

Closed
jfmengels opened this issue Sep 26, 2020 · 1 comment
Closed

Provide type information to rules #41

jfmengels opened this issue Sep 26, 2020 · 1 comment
Labels
design-discussion enhancement New feature or request

Comments

@jfmengels
Copy link
Owner

jfmengels commented Sep 26, 2020

It would be really nice if we could provide type information to rules, so that they provide more useful analysises.

Just like elm-review-scope and the module name lookup table, we could start by having some visitors we could add, and when we're happy with the result, we could make turn this into a native functionality using something like a .

What I'm looking for

Use-cases where this would be useful

If we don't find enough interesting use-cases, it's probably not worth implementing.

  • Knowing what the type of a function is would allow NoMissingTypeAnnotation and NoMissingTypeAnnotationInLetIn to provide an automatic fix. That said, it will probably not provide the exact type annotation you'd want (when dealing with records mostly) as I have experienced with IDE features that do this, but it will definitely be a helpful boost.

Advice on how to implement it

I know nothing of how type inference is done, and how it can be made efficient. I imagine that we can somehow take shortcuts, as we are not trying to validate types, since we already let the compiler handle that for us.

I know Evan said that the type inference algorithm used by Elm cannot be done in a performant manner without mutation, but I have no clue whether that applies to figuring out types and/or for validating them.

A note on compiler integration

I mentioned in #40 that it would be possible to fork the compiler and use the type inference information (and even AST) it provides and pass it directly to the rules. While that sounds attractive, it does bring a lot of lock-in which would have a lot of impact on how tests would be written and where elm-review could be used.

My current thoughts are: Get this working natively well, and later on we could potentially fork the compiler and re-use its information but only for performance concerns. That would allow elm-review to still be able to write the tests like it does and to be run wherever Elm can be run.

@jfmengels
Copy link
Owner Author

jfmengels commented Oct 12, 2020

I started adding type inference logic to one of the NoMissingTypeAnnotation rules where I can polish it more and more until I'm happy with the results it gives. I am still unsure how useful this information could be for other rules, but I imagine I will make it work natively once I consider it to work well. Please comment if you see a use-case for type inference, and if you want me to make it accessible to you in a non-native way (just like elm-review-scope was before it became native).

@jfmengels jfmengels transferred this issue from jfmengels/elm-review-design-discussions Mar 14, 2021
@jfmengels jfmengels added design-discussion enhancement New feature or request labels Mar 14, 2021
Repository owner locked and limited conversation to collaborators Mar 14, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
design-discussion enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant