Add the support of `alda-code` in Alda 2

[UlyssesZh]

alda-code accepts just a string to work, so Alda 2 should be able to support it even with a much simpler lisp than Clojure. This function is important because it can serve as workaround for some features that Alda currently does not support (#323, #133, etc).

[UlyssesZh]

In alda-rb, alda-code is also an essential function in the implementation of Alda::Score#load.

[daveyarwood]

Good call. I think we can add alda-code to Alda 2. I'll have a look at this soon.

[daveyarwood]

I started looking at this briefly tonight, and it's more challenging than I expected! There is a cyclical package issue that we'll need to work through.

Right now, the way the code base is structured, there is a parser package with a ParseString function that can parse a string of Alda code and turn it into a list of score updates []model.ScoreUpdate. A Lisp S-expression like (alda-code "c d e") is one example of a model.ScoreUpdate. The alda-lisp implementation lives in the model package alongside a bunch of other things, like notes, rests, chords, etc.

The problem is that the parser package depends on the model package, so if I'm in the model package (client/model/lisp.go) trying to define an alda-code function in the alda-lisp implementation, I can't just call parser.ParseString, because if I bring in the parser package, I get a cyclic package dependency error:

package alda.io/client
        imports alda.io/client/cmd
        imports alda.io/client/code-generator
        imports alda.io/client/model
        imports alda.io/client/parser
        imports alda.io/client/model: import cycle not allowed

It seems like a refactor is needed, which I am not opposed to doing. I'll just have to think about how I can restructure things to avoid this cyclic import.

Help would be welcome, if anybody has any ideas about how to do this restructuring.

[daveyarwood]

I pushed this commit https://github.com/alda-lang/alda/commit/6fdfe8fa6cf10e34b1800cad32a79f813a38cff5 on a branch with my work in progress.

[daveyarwood]

I think I have an idea of how to do this. We could expose defn as a public function called something like model.LispDefn, and call it from the parser package.