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: Thomas Morley
Subject: Re: LilyPond boolean syntax? \true and \false
Date: Tue, 5 Jan 2016 21:22:50 +0100

2016-01-05 21:05 GMT+01:00 David Kastrup <address@hidden>:
> 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.

The more I think about it the less I like it.

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

To illustrate. Look at the output from the following compiled in a ly-file:

true = ##t
false = ##f

#(define v1 (vector true false true))
#(define v2 #(true false true))

#(newline)
#(write-me "v1 " v1)
#(write-me "v2 " v2)

#(write-me "(vector-ref v1 1) is: " (vector-ref v1 1))
#(write-me "(vector-ref v2 1) is: " (vector-ref v2 1))

#(if (vector-ref v1 1)
     (write-me "test condition for v1 " "condition is true")
     (write-me "test condition for v1 " "condition is false"))

#(if (vector-ref v2 1)
     (write-me "test condition for v2 " "condition is true")
     (write-me "test condition for v2 " "condition is false"))

No chance to make it work this way, I'd say

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


I think we (i.e. a certain awesome developer called David K) shouldn't
go for it.
Maybe if guilev2 works as the manual Paul quoted promises.

Btw, you complained repeatedly about noone else but you cares about
moving to guilev2.
Otoh, I remember you wrote, all low hanging fruits are done already.

I always felt I wouldn't have the needed depth to help, I never asked
expecitely, though.

Thus, I think you have an impression of my skills, is there anything I can do?

Cheers,
  Harm



reply via email to

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