Way to pass commandline options to hlint using new API?

[lierdakil]

I'm currently working on updating ghc-mod to work with newer Hlint API.

Ghc-mod uses a command line flag -l to pass command line options directly to Hlint. While this worked fine with previous API, new API has some pretty interesting way of specifying options (can't say I wrapped my head around that yet), and apparently, command line parser is hidden (and reimplementing it is just not a good option)

Do you have any suggestions? Is there a doc that describes new settings? I gather I could pass a settings file, but there seems to be no docs on its format...

[ndmitchell]

If you are using the command line, is there any scope for you just spawning out the hlint binary? What kind of options do you expect to pass there? Are you looking to get the ideas out as proper ASTs?

[lierdakil]

Thanks for quick response.

Main incentive to use new Hlint API (besides the fact that old is getting deprecated) is being able to pass file/module source from ghc-mod, without relying on temporary files. This is very useful when dealing with unsaved buffer in editor frontend (for which ghc-mod would be backend). I could shell out to hlint, of course, but ideally I'd prefer not to, since that would require to create a temporary file, and then replace its name in hlint output. Not pretty. Getting Ideas is not necessary though, I could certainly live with String representations.

As for command line options that could be useful for this use-case, I can immediately think of following:

• --ignore= (for obvious reasons)
• --language= (for passing cabal language options to hlint)
• --cpp-{define,include,file}=

[ndmitchell]

I wouldn't too much worry about running from the old stuff - I'll certainly keep it around long enough for you to make a sensible migration, and if there's anything it doesn't do, there will be time for me to extend it, you to check it, iterate a few times etc. I'm in no hurry. From what you've said, using the API in process does seem like the best approach.

The options you list can all be represented as:

• --ignore can is Classify.
• --language can be set via ParseFlags the hseFlags field.
• --cpp can be set via ParseFlags the cppFlags field.

So are you taking arbitrary parameters from the user? Or are you making up the parameters you want inside ghc-mod? If it's arbitrary user parameters, then I suspect it makes sense for them to be a subset of the HLint parameters (all those that reasonably make sense), and it also makes sense for HLint to be parsing them for you. You could imagine a variant of autoSettings that took some command line flags.

[lierdakil]

Current implementation just takes arbitrary command line arguments from user and passes those verbatim to Language.Haskell.HLint.hlint together with a filename, that's taken/generated from within ghc-mod, and a --quiet option.

If it would be possible to keep current semantics, that would be ideal. autoSettings version that would accept a list of String (or just String) command line arguments sounds like a good solution for that.

[lierdakil]

By "current semantics" I mean taking arbitrary arguments from user.

[ndmitchell]

OK, that seems the best approach. I won't be able to take a look for a week or so, but I'll see if I can give it a shot.

[lierdakil]

I might be able to take a stab at this before that (no promises yet though). I think I'll create a PR if I manage to get something together. Would that be agreeable?

[ndmitchell]

Sure, that would be great! I think the best API is probably to add autoSettingsWith which is like autoSettings but takes a [String] and returns Either String ... to indicate failure. You'll probably want to call CmdLine.getCmd with unsafePerformIO under the hood. Then it's just a case of marshalling the Cmd flags you can into settings. If you do start making progress, please comment on this ticket, so we don't end up both doing the same things.

[lierdakil]

Sure. Thanks for the pointers.

[ndmitchell]

I've added argsSettings which takes some command line arguments and then does mostly what autoSettings does. @lierdakil and @alanz, can you give it a go and see if it makes senes to you? If so, I'll make a release including it.

[alanz]

Looks good, will give it a try tomorrow.

[lierdakil]

Thanks. I might not be able to take a closer look 'till weekend though.

[ndmitchell]

Absolutely no rush - I may not be able to get to my releasing computer until early in the new year - don't know yet.