Re: Rewriting the Translator definition framework

[David Kastrup]

Paul Morris <address@hidden> writes:

>> On Apr 22, 2016, at 8:07 AM, David Kastrup <address@hidden> 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