Re: LilyPond boolean syntax? \true and \false

[Paul Morris]

> On Jan 5, 2016, at 12:45 PM, David Kastrup <address@hidden> wrote:
> 
> Don't like this since it will lead to people using "true" and "false" in
> Scheme programming, making for non-portable/non-idiomatic Scheme.  Also
> #f and #t are self-quoting forms while false and true are symbols.  This
> means that if you are writing
> 
>    \override whatever.break-visibility = ##(false true true)
> 
> then _all_ of the elements will be symbols and behave the same (either
> all behave like #f or all like #t or an error gets raised at run time).
> 
> I really don't think we'd be doing people a favor by creating this trap.

Hmmm… those are valid points.  Thanks for pointing these things out.  Too bad 
there are these complications if people don’t use LilyPond syntax for LilyPond, 
Scheme syntax for Scheme, and keep the two separate.  I suppose there’s not a 
good/easy way to enforce that separation for cases like this.  (I guess that 
was Simon’s parser keyword suggestion.)  

While I could see an argument for making things easier for most users and use 
cases, and especially for beginners, even if that entails introducing the 
potential for complications for more advanced use cases (involving scheme), and 
a need for more discipline in when to use what, exceptions to the 
interchangeability between LilyPond and Scheme…  

…but I don’t feel that strongly about it.  In some ways most LilyPond users 
will have to be or become advanced anyway (although I’m not sure in which 
direction that points on this, except perhaps to reduce both the potential 
benefits and drawbacks of either scenario).

Cheers,
-Paul