*Lispification intensifies*

[daveyarwood]

Started on this in the moar-lisp branch. What we have happening on the master branch is only half lispified -- instaparse emits Hiccup, which is then manipulated as Hiccup data and then transformed into Clojure code. We can do one better by having instaparse immediately transform the Hiccup into Clojure code (this is working ✅ ), which can then be evaluated (this needs work ❌ ).

I'm having trouble writing a top-level macro (alda-score) that reorganizes the body of the Clojure code, which is a series of instrument calls, with an optional global-attributes form in the first position. The result should be a score form with a variable number of consolidated parts as args. alda-score's job is to assign parts to each of the instrument calls and consolidate repeated instrument calls into part forms, each containing the instrument name and instance number and all of the music-data for that instance consolidated into the one part. This is mostly working at this point, except that an internal function update-data returned by instrument-call is receiving two arguments for some reason. I also just realized that comp is not the right thing to use in order to apply each instrument-call in sequence to the working data (comp will do them in reverse order).

When I was debugging this yesterday with @micha, he brought up the idea of leveraging the power of vars (possibly within a Boot pod) to hold the working data when doing the work that alda-score needs to do. This might help to simplify the process of part consolidation, or at least make the code cleaner. I'm sure it is possible to get things working the way I'm currently doing it, but the way I'm approaching the problem might be overly complicated in light of the options I have available.

Another thought I had is that part consolidation doesn't necessarily need to happen. I could take Alda's algorithm for assigning a part (which is currently part of the update-data function returned by each instrument-call and make it a standalone function, which can then be called by the part function. So the syntax of parts would go from e.g. (part "violin" 1 (music-data ...)) to (part "violin" (music-data ...)) and the part function would figure out that it's instance 1, given the working data stored in some var that was initialized by the score function and modified by any preceding parts.

While we're at it, it would probably make sense to give each instrument its own unique ID (perhaps the instrument name and a random number) instead of representing an instance as a map of the instrument name to a number. The ID can be stored in a var, corresponding to an Instance record. There needs to be a way to find any existing instance records of a certain instrument (e.g. piano), so the part can know whether to append to an existing instance's music data or create a new instance.

[daveyarwood]

More ideas, leading in the right direction:

Get AldaLisp working in the REPL first. Once that's working, it's just a matter of getting the parser to emit AldaLisp code and it should just work. The key thing I've been missing is that an Alda score (like a Lisp program) is an imperative program. Top-level things are being modified. I've been trying to coerce everything into functions that depend on the context that contains them, which is probably doable, but also more complicated than it needs to be, and harder to work with and debug.