Paul Morris <p...@paulwmorris.com> writes: >> On Apr 22, 2016, at 8:07 AM, David Kastrup <d...@gnu.org> wrote: >> >> I am currently doing pitch 2 at first-class Scheme engravers and am >> sorely tempted to scratch the whole macro-based mess and do it via >> inheritance and templates. > > I can’t comment on the implementation questions, but it will be great > to have first-class scheme engravers.
Ok, just to make it clear: this is not necessary for first-class scheme engravers. The approach I already pushed to a branch can definitely be boiled down to a smaller version like I planned on doing, and it would work. And even the approach I pushed to the branch, while being more cumbersome and requiring more cleanup work, would work. It's just that whenever I touch the current code, I feel dirty. It's a bunch of a hardwired cludged-together mess, and I get in a bad mood when figuring out that unnecessary and unused fields abound in various variants of translators because the design is so unclean that you basically need to dump a least common multiple of necessary fields for every derived type into the core translator type. And this mess is close to impossible to properly refactor. So the work I am putting in here is _definitely_ not because bolting first-class scheme engravers on top of the current code would be as hard as that. Anybody who set his mind on it would be finished in a reasonable amount of time. The problem is that I find that the more I work with the code, the less I _want_ to bolt anything on top of it rather than throw the whole mess out. > So thanks for working on this! (Also, while I’m at it, your recent > dotted list work, allowing "violin.1” etc, is also really nice.) Well, I think Simon already pointed out that its use cases are more limited than actual variables. It would not be easy to fix that. Basically, fixing it would be similarly complicated as making c' \tweak color #red \p work without adding - before \tweak: first evaluating an expression in the parser and _then_ assigning it semantic status (in this case, as a post-event rather than a tweaked music expression on its own). I won't rule out that it will be done at one time, but the latter problem has been around basically forever and has been on my agenda for at least five years. Cleaning up the C++ code, in contrast, has a better expected arrival time. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
