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

[rundis]

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: Code intelligence ElmCast/elm-oracle#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 Feature request: types rundis/elm-light#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 ?

[avh4]

Yes, this is what I want to get to, and the reason that I started working on elm-format in the first place!

After getting the 1.0 release finish, I want to review the AST and make sure it is well-defined and gives everything an appropriate name. Once that's cleaned up, I'd like elm-format to be able to convert Elm source code to/from a JSON representation of the AST to support tools like the ones you mention.

However, things like rundis/elm-light#14 will require elm-compiler, since elm-format does not do any type inference, or even checking whether all variable references are defined. It's still an open question how best to keep elm-format and elm-compiler in sync with each other.

[mrmurphy]

@avh4 Would it make sense to just build tooling features straight into the compiler? It seems like an appropriate place for that to live, and it'd may be easier to keep in-sync that way?

[mgold]

To provide an un-asked-for opinion, ideally the compiler would export the AST (or type errors) on request, but that involves adding a lot of complexity to a project that Evan has taken exclusive stewardship of. Having this as a separate project allows it to move without waiting on compiler support.

Furthermore, not verifying type-correctness and variable references is a strength of elm-format, because it can format code while you're debugging compiler errors. This is often when you need formatting the most. Long-term, I'd like to see elm-format format code which it knows is invalid (i.e. a let without an in).

[alex-tan]

Having the formatter usable as a Haskell package would be useful to me as well. I'm actually using this project as a submodule already to format rough elm source output from a program I'm working on to do automatic code generation based on database table structures. Here's what I had to do to get it to compile (plus adding all the same dependencies to the root project).