Decompiler - Code Formatter

[Scowluga]

This PR introduces the Alda code formatter as part of the complete decompiler.

Code formatters can be arbitrarily complex, with entire papers dedicated to the study of how and where to insert spaces and new lines.

Code formatters can also support customization.

For now, we will aim to create a simple formatter that can be expanded upon as requested in the future.

[daveyarwood]

Agreed - let's not go overboard right now and research how to write a code formatter. For now, we'll get a lot of value out of just printing essentially un-formatted code. Maybe we can do something like this simple logic in alda-clj, where I used some really basic heuristics to decide where to insert spaces and newlines between events.

Of course, after we do the parser refactor to produce an AST, I think we'll have much better information available to work with, with events being properly nested, etc. So it should be easier for us to do more sophisticated/nice things with our code formatter.

For example, the AST could break the top-level score up into parts, which would make it trivial for us to format something like:

piano: c d e f g
clarinet: c d e f g
acoustic-bass: c d e f g

as:

piano:
  c d e f g

clarinet:
  c d e f g

acoustic-bass:
  c d e f g

We would have 3 "part" AST nodes, each of which has an instrument call node and a bunch of event nodes, so the above would just be a matter of putting the instrument call on its own line, followed by the formatted events on subsequent lines, and indenting each of those lines.

...but I'm getting ahead of myself. Maybe for now, we could just have the code formatter do as little as possible, and focus on getting the overall structure in place that will allow us to both import MusicXML -> Alda, and format Alda code.

[Scowluga]

Yeah I agree completely with you. There's diminishing returns here. It is quite valuable to get everything hooked up (generation, formatting). And formatting can be simple. Newlines after comments, variable definitions, part definitions. Tabs depending on the nested depth within the AST, a space between different part definitions, etc. We can get something that works here relatively simply.

Then maybe as the need arises for more detailed formatting, we can go from there. But for the main purpose of MusicXML import for now, a simpler formatter is nice.

[Scowluga]

Previous work on this task is a bit stale. Closing and restarting.