Re: New read/eval Scheme syntax inconsistent in handling existing code

[David Kastrup]

Valentin Villenave <address@hidden> writes:

> On Mon, Nov 21, 2011 at 7:39 PM, David Kastrup <address@hidden> wrote:
>
>> A bug that made it through the reviews, nothing inherently bad about
>> the design.  Thanks for the test example, by the way.
>
> Yes, it looks probably a bit far-fetched but said bug did break all of
> my scores! (Hence the disruption thing.)

Could you recheck with current staging?  It would appear that you are in
possession of the most comprehensive test suite available...

>> The above file works fine with current staging.  Since you, as
>> opposed to the Lilypond code base, appear to make extensive use of
>> ly:parser-include-string, you might want to consider contributing a
>> few regression tests capturing the essence of your usage patterns.
>
> That's what I wanted to know: since parser-include-string was
> originally implemented upon a request of mine, I wasn't sure it was
> considered vanilla LilyPond syntax and supported as such.

I don't throw out functionality as a rule.  ly:export was an exception
to that rule because its presence was fundamentally incompatible with
maintaining predictable timing for #.  But I backed up this step with a
set of convert-ly rules of rather high quality and coverage (including
the entire Lilypond code base).

> Do you think this warrants a regtest of its own, or should it rather
> be added to include-string.ly?

I think extending include-string.ly is ok.  I am somewhat surprised that
it did not trigger, actually.

-- 
David Kastrup