The way it's done under the hood can be visualized by the following diagram:
- The EclipseFP code invokes the BuildWrapper executable when a file in the project has changed. BuildWrapper uses the GHC API to load the Haskell module from files, and get the AST. We actually use both the RenamedSource and the TypecheckedSource to combine information from both. From the AST we get a list of all the usages in the file: all the functions, for example, used in the file, and where. All this information is stored in a hidden bwinfo file, in JSON format.
- EclipseFP then picks up the generated file and parses it. The usage data is then written in a SQLite database, whose file is stored in the plugin folder.
- All Haskell searches are then done against the SQLite database.
For the user, this gives the following possibilities:
- open a Haskell module from a dialog showing all known local modules in the workspace
- perform contextual searches for usages of a given object
- perform a search by typing a name in a dialog and maybe specifying additional criteria (search references and/or declarations, search constructors and/or types, etc).
- perform contextual rename of a given object. You can rename a function and everywhere where that function is invoked will be changed, using the Eclipse refactoring plugin.
I'm planning on releasing EclipseFP 2.3.0 pretty soon, so that people can start testing!