[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LilyPond boolean syntax? \true and \false
From: |
David Kastrup |
Subject: |
Re: LilyPond boolean syntax? \true and \false |
Date: |
Tue, 05 Jan 2016 18:45:01 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
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