idea: tool to suggest adding imports

[Erik Hesselink]

I wrote halberd a while ago. It was mostly as an example of using the
haskell-names and haskell-packages packges (combined with
haskell-src-exts) that Roman Cheplyaka was working on at the time,
combined with a useful tool that I wanted for myself. The downside is
that haskell-packages doesn't use the same package database as ghc, so
you had to compile the packages twice: once with ghc, and once with
haskell-packages. That made the task of actually integrating it with
an editor in a useful way for large projects seem pretty hairy, so I
didn't continue working on it. Later there was a big API change in
haskell-names that I never took the time to support, so it currently
doesn't support the newest versions of its dependencies.

Let me know if you (or anyone else) wants to work on it or rip out
useful parts. Perhaps I can help out a bit.

Regards,

Erik

On 18 March 2016 at 20:12, Harendra Kumar <harendra.kumar at gmail.com> wrote:
> That's cool, I'd love to have that feature in my editor. Have you seen this:
>
> https://hackage.haskell.org/package/halberd
>
> The readme says:
>
> ---cut---
>
> Halberd is a tool to help you add missing imports to your Haskell source
> files. With it, you can write your source without imports, call Halberd, and
> just paste in the import lines.
>
> Currently, it tries to automatically choose an import if there is a single
> sensible option. If it can't, it will prompt you with a simple menu. After
> running, it prints the imports, which you need to copy manually. Editor
> integration is planned.
>
> ---cut---
>
>
> I have been thinking of exactly the same problem. That's how found this. I
> have not tried it yet but this could be a starting point even if its not
> working perfectly. In the best case you will have to just do the editor
> integration part.
>
>
> -harendra
>
> On 18 March 2016 at 23:57, John Williams <jrw at pobox.com> wrote:
>>
>> I have an idea for a tool I'd like to implement, and I'm looking for
>> advice on the best way to do it.
>>
>> Ideally, I want to write an Emacs extension where, if I'm editing Haskell
>> code and I try to use a symbol that's not defined or imported, it will try
>> to automatically add an appropriate import for the symbol. If instance, if I
>> have "import Data.Maybe (isNothing)" in my module, and I try to call
>> "isJust", the extension would automatically change the import to "import
>> Data.Maybe (isJust, isNothing)".
>>
>> The Emacs part is easy, but the Haskell part has me kind of lost.
>> Basically I want to figure out how to heuristically resolve a name, using an
>> existing set of imports as hints and constraints. The main heuristic I'd
>> like to implement is that, if some symbols are imported from a module M,
>> consider importing additional symbols from M. A more advanced heuristic
>> might suggest that if a symbol is exported from a module M in a visible
>> package P, the symbol should be imported from M. Finally, if a symbol is
>> exported by a module in the Haskell platform, I'd like to suggest adding the
>> relevant package as a dependency in the .cabal and/or stack.yaml file, and
>> adding an import for it in the .hs file.
>>
>> Here are some implementation options I'm considering:
>>
>> 1. Add a ghci command to implement my heuristics directly, since ghc
>> already understands modules, packages and import statements.
>> 2. Load a modified version of the source file into ghci where imports like
>> "import M (...)" are replaced with "import M", and parse the error messages
>> about ambiguous symbols.
>> 3. Write a separate tool that reads Haskell imports and duplicates ghc and
>> cabal's name resolution mechanisms.
>> 4. Write a tool that reads Haskell imports and suggests imports from a
>> list of commonly imported symbols, ignoring which packages are actually
>> visible.
>>
>> Right now the options that look best to me are 2 and 4, because the don't
>> require me to understand or duplicate big parts of ghc, but if modifying ghc
>> isn't actually that hard, then maybe 1 is the way to go. Option 3 might be a
>> good way to go if there are libraries I can use to do the hard work for me.
>>
>> Any thoughts?
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>