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

[David Kastrup]

Valentin Villenave <address@hidden> writes:

> Greetings everybody,
>
> David's new code with #/$(scheme) styles does offer a lot of exciting
> possibilities... but it is also hugely disruptive when it comes to
> existing code!

Not all that disruptive when you use convert-ly.

> Consider for instance the following:
>
> \version "2.15.19"
>
> myvar = { b'4 }
>
> #(ly:parser-include-string parser
>   "myvar = { a'2 }")
>
> \new Staff \myvar
>
> This used to print the overwritten variable, which it doesn't anymore
> and I think I get why.

With all due respect, I doubt that.  The reason is rather boring: my
changes broke ly:parser-include-string because I did not understand what
the pending_include whatever were for.  I pushed two changes to staging
just now fixing this.  While the above example works fine now, when
using ly:parser-include-string, it is preferable to use $ to avoid
having your string getting injected _asynchronously_ after parser
lookahead (the above use is in a place without lookahead).

With the last change I pushed, the pending_include stuff is removed
completely.  This is possible because the separation of reading and
evaluating embedded Scheme makes it possible to _read_ embedded Scheme,
clean up the input pointers, and _then_ evaluate the read expression
including any ly:parser-include-string (this separation can be used even
for the $ code-path).

> What's a lot more baffling, however, is that the variable isn't
> overwritten _even_ when prefixing the Scheme expression with $ instead
> of #.
> (At least it isn't overwritten until after Lily's already parsed and
> processed the staff.)
>
> Thoughts?

A bug that made it through the reviews, nothing inherently bad about the
design.  Thanks for the test example, by the way.

While #(ly:parser-include-string ...) will continue working in
situations where there is no parser lookahead (like above), using
$(ly:parser-include-string ...) is likely safer.

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 way you'd have to fear fewer disruptions to your existing scores in
future.

-- 
David Kastrup