Hi,
you might have been wondering what I've been up to in the last month or
so. I have by now accumulated several rewrites of the
"dispatcher"/"listener"-related internals of
engravers/performers/translators and got them working. Unfortunately,
by the time I finish one rewrite, I have learnt enough to figure out why
the approach in general is more complex to maintain than desirable and
how the work might be better organized.
Also the first rewrite was sort of embarrassing in that I got every
wrinkle out until the last point remaining were Scheme engravers. And
those would not have fit into this approach well at all. But they are
too important for that.
As things currently stand, I suspect that the current mechanism for
creating Scheme engravers with their own variables (namely providing a
function creating an engraver description) does not have likable
performance characteristics and, more importantly, does not really work
reasonably at all with regard to registering Scheme engravers like C++
engravers so that they can be called by name and documented in the same
manner.
I'll probably come up with something GOOPS-related eventually and the
closure mechanism for creating Scheme engravers will be deprecated.
At any rate, I am starting over _again_ but I think that I am now at the
stage where my plan of execution is nicely streamlined and "Listeners"
from both C++ and Scheme level (as well as their creation from the
bowels of the respective engraver types) are quite straightforward to
deploy and debug and don't rely on all the C level macro hackery.
It _is_ sort of a nuisance to have several iterations of working
branches that have each taken quite a bit of work to run fine but that
end up catering for what amounts to ultimately being the wrong kind of
data structure for long-time code maintenance.
Reminds me of the old joke about an experimental physicist asking the
university dean for funding of an accelerator, and the dean goes "why
can't you be like the mathematicians? All they need is pencil, paper,
and a wastebasket. And the philosophers don't even need a
wastebasket..."
So in short, I've been tending the most important resource a good
programmer should have in his possession: the wastebasket. And I expect
people to ultimately be glad about all the code I have thrown away once
I get to throwing away the current code we work with.