Go to definition of library methods

[jarandaf]

Is it currently possible? It seems it only works for local methods.

[wz1000]

I don't think this is possible via the ghc api. We would have to use some third-party tool like codex or hasktags

[IvanMalison]

@wz1000 Or maybe a bug should be filed against ghc to make this possible? What exactly is the issue?

[wz1000]

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.

[IvanMalison]

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'.

[wz1000]

@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.

[jarandaf]

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).

[IvanMalison]

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.

[wz1000]

@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.

[wz1000]

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.

[IvanMalison]

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.