[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rewriting the Translator definition framework
From: |
David Kastrup |
Subject: |
Re: Rewriting the Translator definition framework |
Date: |
Fri, 22 Apr 2016 17:51:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
"Trevor Daniels" <address@hidden> writes:
> 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.
If people write C++ code as part of their compositions, they really
don't have any expectation of it going to compile with any LilyPond
version other than what they wrote the C++ code for.
> I guess there will be very few of these,
My guess is exactly zero when not considering Mike, and even when
considering Mike, I don't think he'd expect to just plunk C++ code into
a new version and have it work unchanged.
> but it would be a shame if they were to be limited to 2.18 stable
> without a rewrite.
When writing C++ code, you are limited to _very_ close versions of
whatever you wrote the C++ code for.
> 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?
I'm pretty sure that we are not talking about the same thing, and I am
not even sure what you are actually thinking about. From the Scheme
side, I don't see that anything would change in manners that are not
upwards-compatible.
--
David Kastrup