Re: LilyPond boolean syntax? \true and \false

[David Kastrup]

Paul Morris <address@hidden> writes:

>> 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.

The two are not intended to be kept separate regarding their
_identifiers_.  It's one of LilyPond's strong suits (and a
modularization nightmare) that Scheme and LilyPond all access the same
variables and values and are only separate regarding their syntaxes.

> 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.)

It would be rather heavy-handed.  But the problem in my opinion is not
as much how good/easy a way to enforce a separation of LilyPond/Scheme
entities using keywords would be, but rather the separation itself is
not a good idea.  It's just not in the spirit of what we do elsewhere.

> While I could see an argument for making things easier for most users
> and use cases,

I don't really think it's a question of easy or not, more one of visual
ugliness or not.  Basically one needs to keep the # count correct inside
and outside of Scheme.  I don't think we'd help people by writing #'#f
and #'#t here: we had that discussion for #'#(...) as opposed to ##(...)
already.  The main issue just is a consequence of our escape-to-Scheme
character being the same as the Scheme reader's escape-to-special
character.

If we are not going to change that, I don't think that trying to create
circumventions for common doublings is going to help in the long run.

And frankly, how much of an issue is it in practice?  If I search for
"boolean" in ly/music-functions-init-ly, I get 0 matches.  None of the
music functions in there takes a boolean argument.  Same for
ly/property-init.ly.  So it's mostly set/override/tweak and global
boolean properties that actually are at issue here.  Except for tweak,
the boolean tends to be right at the end of the line where the ##t/##f
difference is exposed as well as one could hope for.

-- 
David Kastrup