Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)

[David Kastrup]

Devon Schudy <address@hidden> 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