lilypond-devel
[Top][All Lists]
Advanced

[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 21:05:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Simon Albrecht <address@hidden> writes:

> On 05.01.2016 18:45, David Kastrup wrote:
>> 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?
>
> I must say I also like the idea.
>
>> 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.
>
> Could \true and \false be implemented as parser keywords?

Probably.  It would be a lot of effort, and they would consequently
behave different from other fixed expressions assigned to identifiers
(being unavailable in Scheme being one of the effects).  So the result
would likely be less than more consistent.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]