Devon Schudy <dsch...@gmail.com> writes: > dak wrote: >> https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode97 >> ly/satb.ly:97: \new Staff = #(identity ,name) \with { >> Why #(identity ,name) here instead of #,name ? > > #,name didn't work for some reason, so I wrapped it with identity as a > workaround.
Please try refraining from workarounds before checking back with the developer list. And when you actually use workarounds, try putting comments in so that the next developer has a clue what you have been doing and why. Otherwise we will accumulate a lot of cruft that nobody know the reason for, and possibly cruft that could have been fixed rather than dragged around. > ...but I just tried it again and #,name works now, even in versions > from mid-December. I wonder what I did that made it fail? Following up with a non-space character maybe (note that there are quite a few characters looking like a space that aren't). Or writing ,#name. At any rate, I'm not really happy with the macro usage at top level here: I think it would be better if the basic assembly was rather done by music or Scheme functions (Scheme functions should, when used inside of a music sequence, be able to return either music or *unspecified*, and the latter is ignored completely). As explained in <URL:http://web.archive.org/web/20130808154633/http://news.lilynet.net/?The-LilyPond-Report-27#a_kind_of_magic> (I wish the original website were accessible again), it's a bit of good luck that this even works. The bottom line was The current form of the closures argument as an association list of string offsets to anonymous functions was introduced as an emergency measure because Guile version 2.0 was lacking local-eval, a feature of Guile used previously for the purpose of evaluating Scheme inside of embedded LilyPond in lexical closure (the syntactical environment containing local variables) of the outward Scheme layer. Version 2.0.4 of Guile (released in January 2012) saw a return of "local-eval". Would this kind of construct work using local-eval in either Guile 1.8 or Guile 2.0? Frankly, I don’t know. Capturing a lexical environment in the middle of expanding a quasiquote seems like an audacious enterprise. In afterthought, expecting this to work was somewhat optimistic. But LilyPond delivered. And I am not really convinced that if we move to local-eval at some point of time that we'll be able to get `#{ ... #,... #} to work in a reasonable time frame. Maybe that will be considered a show stopper anyway, so we'll stay with the lambda implementation which manages to survive this rather brutal mixture of Scheme and LilyPond. It's nice that it works, but I'd prefer seeing somewhat more natural seeming approaches here. Macro calls as a user interface don't make me happy. They have their place as work horses in things like the make-relative macro. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
