ghc-mod icon indicating copy to clipboard operation
ghc-mod copied to clipboard

Better library interface?

Open lierdakil opened this issue 8 years ago • 8 comments

So... I've been thinking about improving interactive interface, and I've got a question.

Are there any plans to make library interface more typeful? As it is, it mostly returns Strings and [String]s. While this is ok for raw terminal output, re-parsing e.g. error messages back into severity, point and message seems more than a bit weird, does it not? Besides, things like (Int, Int, Int, Int) just don't make sense to me.

Am I missing something? Or is it just a legacy thing?

lierdakil avatar Dec 07 '15 19:12 lierdakil

I would like to start seeing these kind of types coming back: https://github.com/haskell/haskell-ide-engine/blob/master/hie-plugin-api/Haskell/Ide/Engine/SemanticTypes.hs#L23

See also https://ghc.haskell.org/trac/ghc/ticket/8809, which will hopefully result in properly typed errors in time.

Also https://phabricator.haskell.org/D1240#46788

alanz avatar Dec 07 '15 20:12 alanz

@alanz, in all honesty I would prefer SourcePoint { spLine :: Int, spCol :: Int } to (Int, Int). There are pros and cons to both approaches though.

lierdakil avatar Dec 07 '15 20:12 lierdakil

I am fine with TypeResult being updated to that, main point is that we are already starting to impose structure on results from ghc-mod, makes more sense for that to happen inside ghc-mod. For types that make sense, as you want.

alanz avatar Dec 07 '15 20:12 alanz

@lierdakil you have to think about where all these Strings are coming from. All ghc-mod does (for check for example) is intercept ghc's log messages throught withLogger and then spit that out later. So we just don't have the semantic information readily at hand.

Now of course we could parse ghc's log messages and expose a more useful representation but I think given that GHC HQ is working/thinking about adding more semantic info to the pretty printer this might be wasted effort.

DanielG avatar Dec 07 '15 20:12 DanielG

type of course is another matter entirely since we have a full Type AST in that case. If you want to clean that up or expose more of it feel free.

DanielG avatar Dec 07 '15 20:12 DanielG

If we coordinate things right, we can start the types off here, and migrate them into GHC in time, when that work actually happens.

alanz avatar Dec 07 '15 20:12 alanz

@DanielG, at the very least GHC returns SrcSpan and Severity separate from actual message, does it not?

lierdakil avatar Dec 07 '15 21:12 lierdakil

Yeah you're right of course. Looks like I didn't read your question properly ;)

Anyways if you (or anyone else) feels like cleaning that up feel free.

DanielG avatar Dec 09 '15 21:12 DanielG