Rewriting the Translator definition framework

[David Kastrup]

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.

Any principal objections?

-- 
David Kastrup