[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rewriting the Translator definition framework

From: Trevor Daniels
Subject: Re: Rewriting the Translator definition framework
Date: Fri, 22 Apr 2016 16:42:56 +0100

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]