Re: LilyPond boolean syntax? \true and \false

[David Kastrup]

Paul Morris <address@hidden> writes:

> Thanks to David Kastrup’s work there’s now much less need to use
> scheme syntax in overrides etc. (e.g. the dot syntax instead of #' and
> no longer needing # for numbers).  This has really simplified things
> for users.
>
> As another small step along these lines, would it make sense to free
> booleans from the ##t and ##f syntax?  Compare:
>
>   \override Context.Grob.property = ##t
>
>   \override Context.Grob.property = ##f
>
>   \override Context.Grob.property = \true
>
>   \override Context.Grob.property = \false
>
> Providing \true and \false would (1) allow users to stay in familiar
> LilyPond syntax (avoiding the awkward double ## that’s unintuitive to
> new users) and (2) improve readability by using the whole word.  (I
> for one find it hard to quickly see the difference between ##f and ##t
> at a glance.)
>
> Implementation would be trivial, of course:
>
>   true = ##t
>   false = ##f
>
> Thoughts?

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.

-- 
David Kastrup