Avoid macros in SATB framework.

Avoid macros in SATB framework.

Use define-once instead of satb-defaulting.

[Devon Schudy, 2014-01-13 18:32:25]

Omitting PianoDynamics now works. Remove duplicate \version.

[Trevor Daniels, 2014-01-13 23:48:37]

LGTM
I can deal with my comment before I push 
after the review if you like.

Trevor

https://codereview.appspot.com/51230043/diff/20001/ly/satb.ly
File ly/satb.ly (right):

https://codereview.appspot.com/51230043/diff/20001/ly/satb.ly#newcode260
ly/satb.ly:260: \version "2.18.0"
This needs to be present, but commented out,
else users will not receive a warning if they
omit their \version statement.

[dak, 2014-01-14 14:30:45]

https://codereview.appspot.com/51230043/diff/20001/ly/satb.ly
File ly/satb.ly (right):

https://codereview.appspot.com/51230043/diff/20001/ly/satb.ly#newcode75
ly/satb.ly:75: #(define-once Key *unspecified*)
I don't see that using some Scheme interface rather than providing that facility
on the LilyPond level makes a lot of sense.  For one thing, this will not
overload identifiers defined in the Guile module rather than the parser even
though

Key = \key\default

would do.  Let's keep in mind that the whole idea of the satb template is not as
much as getting a single job done, but rather for us to start developing a
template infrastructure.  That means that whenever a particular facility is not
available in an immediately useful manner, we want to define it (not in the
template, but in LilyPond proper) rather than work around it.

The goal is not just that an ordinary user finds it easy to _use_ a particular
template, but also that he or she finds it easy to define his own templates. 
That's what we need to get a template ecosystem off the ground.

[Trevor Daniels, 2014-01-15 10:50:07]

On 2014/01/14 14:30:45, dak wrote:

> https://codereview.appspot.com/51230043/diff/20001/ly/satb.ly#newcode75
> ly/satb.ly:75: #(define-once Key *unspecified*)
> I don't see that using some Scheme interface rather than providing that
facility
> on the LilyPond level makes a lot of sense.  For one thing, this will not
> overload identifiers defined in the Guile module rather than the parser even
> though
> 
> Key = \key\default
> 
> would do.  

So you you mean that define-once should be added to LilyPond
as a generally available facility, or that some other
mechanism is needed?

> The goal is not just that an ordinary user finds it easy to _use_ a particular
> template, but also that he or she finds it easy to define his own templates. 
> That's what we need to get a template ecosystem off the ground.

To do this we'll need a general mechanism for defining such built-in
templates - what the variables' names are and their defaults, and the
context structure with the variables in place - and a means of
invoking them.  Perhaps we should set up a new issue to track the
discussion of this.

Trevor

[Trevor Daniels, 2014-02-28 22:19:04]

This patch seems to have stalled.

@David: Could you perhaps spell out more
clearly what needs to be done to meet your
objections.

Trevor