Suggestions or actions to use type synonyms

[expipiplus1]

It would perhaps be nice if HLS suggested using in scope type synonyms sometimes.

To make an example using the hnix package: if I use the excellent code action Define funArity :: Fix (Compose (Ann SrcSpan) NExprF) -> Int I end up with the unhuman given type sig, when funArity :: NExprLoc -> Int would be much nicer.

It's probably quite hard to come up with the perfect rule here, but how do people feel about a heuristic along the lines of:

• The sig is in scope
• The types are equal
• Using the synonym is much shorter

(Better but more difficult would be to calculate the preference in existing code (user and library) between the synonym and the expanded version)

[mpardalos]

Is there still interest in this feature? I would be interested in working on it.

[expipiplus1]

Yes, absolutely!

…

On Thu, Mar 4, 2021, 2:33 AM Michalis Pardalos ***@***.***> wrote: Is there still interest in this feature? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#506 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXGRGGJQ4JU2J7WTKQ3TBZ6GTANCNFSM4STFC7LA> .

[sullyj3]

This seems maybe like something that ought to be in hlint?

[ndmitchell]

This can't really be in HLint, since sometimes type synonyms have semantic information that HLint just can't know. For example, FilePath vs String is an important distinction. Having the ability to do type-level suggestions makes sense, and I think that might be a useful feature to add to HLint, but it can't just infer that a synonym should be used instead, the user would have to opt in with configuration.

[jneira]

It would be great to have code actions in both directions:

• use the type synonym when appropiate
• but convert a use of the type sysnonym in its original type signature, recursively. It could help to understand it better in the call site (and return to use it auto after that)