Re: Rewriting the Translator definition framework

[Trevor Daniels]

David Kastrup wrote Friday, April 22, 2016 1:07 PM

> 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.
> 
> Any principal objections?

Not really an objection; just a thought.  I can't comment on the
technicalities, and I've every confidence you can carry this through,
but I wonder about the position of existing compositions that include 
custom C++ engravers in the old (i.e. current) style.  I guess there
will be very few of these, but it would be a shame if they were to be
limited to 2.18 stable without a rewrite.

Might it be better to move forward to 2.20 before doing this so they 
could take advantage of all the 2.19 improvements in a stable release?

Trevor