<div dir="ltr"><div dir="ltr" style="font-size:12.8px">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.<div><br></div><div>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)".</div><div><br></div><div>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.</div><div><br></div><div>Here are some implementation options I'm considering:</div><div><br></div><div>1. Add a ghci command to implement my heuristics directly, since ghc already understands modules, packages and import statements.</div><div>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.</div><div>3. Write a separate tool that reads Haskell imports and duplicates ghc and cabal's name resolution mechanisms.</div><div>4. Write a tool that reads Haskell imports and suggests imports from a list of commonly imported symbols, ignoring which packages are actually visible.</div><div><br></div><div>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.</div><div><br></div><div>Any thoughts?</div></div></div>