Idea: Splitting out parser/ast to separate lib might enable lots of other use cases

I haven't really looked into the details on how you've build the parser/ast bits of elm-format (just gotten started on Haskell), but I can imagine that it I might be possible to reuse/build upon the work for many other contexts beyond formatting ? Of course I might be wrong.

I'm thinking in tooling terms... for things like refactoring, find usages, find type at point, look up definition etc etc.
- I've seen this issue in elm-oracle which is sort of related: https://github.com/ElmCast/elm-oracle/issues/11
- In the slack channel there are discussions on how to create json decoders/encoders to/from elm types
- I've received a feature request for my Light Table plugin https://github.com/rundis/elm-light/issues/14 I imagine this plugin and other language plugins will receive many more like this, which all would require some sort of parsing and an AST representation to enable a sensible implementation

It would be a shame and probably waste of resources if we ended up in a situation where multiple editor plugins create their own parser, or were we end up with a multitude of tools alla elm-oracle elm-format etc that implement their own parser (trying to keep up with elm versions).

As a side note; I've looked a bit into the tooling situation on haskell, and to me it seems quite messy even though there now is an initiative to improve the situation with https://github.com/haskell/haskell-ide-engine. I'm hoping we can do better with tooling for elm.

Probably this doesn't belong as an issue here, but perhaps it should be a discussion on the elm-dev discussion list ?

No file, test, or entry point is named. Start by reviewing the existing parser/AST implementation in elm-format and the linked elm-oracle tooling discussion; this issue is done only after the project agrees on whether and how a reusable parser/AST library should be split out.

Written by the indexing model from the issue text.