Re: Issue 2024 in lilypond: Patch: Let #{ ... #} pass its $ handling to environment cloning

[lilypond]

Comment #4 on issue 2024 by address@hidden: Patch: Let #{ ... #} pass its $  
handling to environment cloning
http://code.google.com/p/lilypond/issues/detail?id=2024

I am rather serious about this.  The last upload removes all uses of  
ly:export _via_ convertrules.  Automatically, even though this involves  
non-trivial editing of Scheme code and embedded Lilypond.  In the process,  
it slightly changes the call syntax of, I think, 5 Scheme functions which,  
for no imaginable reason whatsoever, are called in Scheme rather than as  
music functions, but return a packed identifier that is only ever useful  
used in Lilypond syntax.

This is not a question of GLISS but rather of sanity.  This patch does not  
address the sanity angle; it merely requires the user to use $ when using  
those functions rather than #.  As a side benefit, their return values are  
now useful when called from Scheme, but I doubt anybody actually wants to  
do that.  They should really be turned into music functions.  All manual  
uses of ly:export are also patched away, and definition and use of a  
similarly weird function in the baerenreiter regtest are automagically  
detected and changed.

After this gets accepted, I will remove ly:export altogether, and split the  
phases of reading and evaluation # expressions, getting rid of their  
synchronization problems.

You better review this before it passes a countdown.  As I said, I am dead  
serious about it.  It straightens out a lot of wrinkles and inconsistencies  
in the interaction of Lilypond, Scheme, and #{ ... #} code blocks, with an  
interplay that is logical and understandable rather than a series of  
unrelated hacks.

You'll need to handbump VERSION for reviewing at the moment, since  
convert-ly has to pick a not-yet existing release number.  Let's hope that  
we get the official version bump soon.