haskell-ide-engine
haskell-ide-engine copied to clipboard
haskell
Go to definition of library methods
I don't think this is possible via the ghc api. We would have to use some third-party tool like codex or hasktags
@wz1000 Or maybe a bug should be filed against ghc to make this possible? What exactly is the issue?
This isn't a bug with ghc, as ghc doesn't know about the source files of installed packages, it just cares about the .hi and .o files.
In most cases, the source files of the dependencies aren't even available locally.
This isn't a bug with ghc, as ghc doesn't know about the source files of installed packages, it just cares about the .hi and .o files.
Yeah, I figured as much, but that doesn't mean that that information couldn't be embedded in those files right? stackage/hackage could be used to retrieve the missing source code if needed.
This is a feature that many other languages provide, it seems silly to have the answer for haskell to simply be 'this is not possible'.
@IvanMalison well, like I said, it could be possible by making use of tools like codex and hasktags
There is a deeper UX issue as well here. Any edits you make to the source files of your dependencies won't be reflected in your program. Maybe it would be better to return the html hscolor source file generated by haddock to make this clear.
Any edits you make to the source files of your dependencies won't be reflected in your program.
This should be the expected behavior, as in many other languages (dependency source files are read-only).
This should be the expected behavior, as in many other languages (dependency source files are read-only).
Yeah, agreed, I'm not sure this would really surprise many people. If you're really worried about it, you could make any source downloaded as a dependency have read-only permissions.
it could be possible by making use of tools like codex and hasktags
Those tools are pretty unsatisfactory because a) they rely on heuristics for the most part b) You have to regenerate tags which is annoying c) They introduce additional cognitive load (why should I have to think about which go to definition command I need to use) d) they require additional setup
Also why should a language with such a sophisticated and accurate type system have to rely on tags. There is nothing about haskell as a language that should preclude this feature. In fact, haskell is IDEALLY suited for this sort of thing bc of its functional nature and the strength of its type system.
Rust has racer, scala has ensime, go has guru, even clojure (which is dynamically typed, mind you), has a much better story here with cider.
It's kind of embarrasing that despite being around for longer than any of these languages, haskell doesn't really have good jump to definition support.
@IvanMalison I don't see a way to get GHC to give us this info, so I think we will have to rely on tags or something similar, perhaps making use of the info GHC can give us(whether a symbol is a type constructor or a data constructor, the module it is defined in etc) to improve the accuracy. HIE can also handle setup and tag regeneration.
If you want to take a stab at it(using any method), PRs are very welcome. You can also join us on #haskell-ide-engine on freenode.
Since we would only use tags for external dependencies, tag would need to be regenerated only when dependencies change. Also, since we can tell by looking at the package a symbol is defined in whether the definition info should be queried from GHC or tags, the process could be entirely transparent to the user.
I don't see a way to get GHC to give us this info.
As things currently stand, right? Or is there a major technical limitation you have found that would prevent making this sort of information accessible with changes to GHC? It seems like it should be possible to simply add this information to the .hi files, although I can imagine that such a change might be met with quite a bit of resistance for one reason or another.
There is a deeper UX issue as well here. Any edits you make to the source files of your dependencies won't be reflected in your program. Maybe it would be better to return the html hscolor source file generated by haddock to make this clear.
Like most emacs useres, I absolutely despise leaving my editor, it should be easy enough to open the files in read-only mode in the editor, right? Perhaps this should be configurable?
Since we would only use tags for external dependencies, tag would need to be regenerated only when dependencies change. Also, since we can tell by looking at the package a symbol is defined in whether the definition info should be queried from GHC or tags, the process could be entirely transparent to the user.
This is a fair point -- as long as the process is entirely transparent to the user, I guess I would be fine with this.
I still maintain that it is silly, and also a bit antithetical to the ideals of haskell IMO, to use such a coarse, imprecise tool when the language/compiler has such a strong type system and ability to infer things about the code.
I spent the last week working on an android project, and it reminded me of how incredibly strong the Java IDEs are at doing things like this. I always have 100% confidence that the IDE will do what I want when I press the jump to definition key. Doing this in haskell should be no harder than doing it in Java.
Ohh, this would be so amazing to have. :heart: Hoogle is nice, but nothing beats M-. and a quick informed look at the library code I’m currently calling.
Esp. that I could read the Hoogle docs straight in that source.
I used to do this a lot when working with other languages, and such a feature feels really-really nice and useful.
E.g. looking at
-- | @'flip' f@ takes its (first) two arguments in the reverse order of @f@.
flip :: (a -> b -> c) -> b -> a -> c
flip f x y = f y x
it’s much clearer than just 'flip' f@ takes its (first) two arguments in the reverse order of @f@.
@wz1000 Hey. I tried to reach you on irc but it seemed that you were afk.
here's what I wrote:
wz1000: Hey, I've heard that you are working on some changes to ghc
that would exporting a new type of file that would allow hie to
much more information [13:36]
I'm actually at bayhac right now, and was hoping to do something with this today or tomorrow. If there's any other way I can help out with hie I'd love to do that too.
@wz1000 I understand that your GSOC project can potentially help in this situation?
At least make the information potentially available.
Looks like there is a status update here: https://gist.github.com/wz1000/5ed4ddd0d3e96d6bc75e095cef95363d
@alanz So it sounds like .hie file output won't ever be backported to old versions of ghc? How does hie plan to handle that?
If it is supported, we use it. Otherwise the info needs to come from somewhere else.
I believe we should bring in something like ctags/hasktags support, and codex is able to make a tags file for a given project including its libraries.
I was greatly disappointed by this as well. I've tried to setup sthg with haskdogs/hasktags but failed to do so https://github.com/grwlf/haskdogs/issues/4 .
@alanz Based on the milestone title, I wonder if it is still going to happen. I'd like to contribute. How can I get started?
@cdornan I believe the plan was to integrate HieDb or maybe eventually hie-lsif. Now that the first release candidate for ghc 8.8 is ready hie I think it just needs ingratiation?
@wz1000 Is that still right? Can HieDb be used with stack's precompiled libraries, nix and hie-bios?
As a workaround for VSCode this works:
stack install hasktags haskdogs
Then haskdogs in your project directory.
Finally install ctagsx as an extension in VSCode and enjoy.
