Re: Rewriting the Translator definition framework

[Carl Sorensen]

On 4/22/16 6:07 AM, "lilypond-devel on behalf of David Kastrup"
<address@hidden on behalf of
address@hidden> wrote:

>
>Hi folks,
>
>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.
>
>Now the sore point is that the basic type for which Scheme functions are
>defined is that of a Translator.  And Engravers and Performers are
>inherited from Translators, and it is only when inheriting from
>Engravers/Performers that it is clear where the documentation is coming
>from: static and specific to some Translator type, or dynamic and
>defined per Engraver (as with Scheme engravers).  Similar for some
>dispatch tables.
>
>So the salient point would be to use virtual inheritance for access to
>the translator documentation.  We don't use virtual inheritance
>elsewhere yet but, well, it's not like it hasn't been around a long time
>now (basically since times before there even was a C++ standard other
>than the ARM).  So it's not a particularly new challenge for the
>compiler, and its use would also be quite straightforward.  I don't see
>a comparably straightforward way to introduce documentation via a side
>path, and it would also open up the path for having other translator
>types (unspecific translators like the Timing_translator or even
>performers) created dynamically by Scheme later on without having to
>extend the macro mess.
>
>I think that would be considerably cleaner than dragging a number of
>unused static components around for dynamically defined types.

I think that if this can be done, it would be a great advantage.  Using
standard C++
constructs instead of LilyPond specific macros would help improve the
accessibility of
the code.

Thanks,

Carl