> On Jan 5, 2016, at 5:15 PM, David Kastrup <d...@gnu.org> wrote: > > 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.
Indeed… this presents an exceptional case where, as you pointed out, introducing \true and \false leads to problems if users don’t use them only for LilyPond and start to use them in Scheme rather than #t and #f. So these proposed identifiers only make sense (if they do) as syntax sugar on the LilyPond side, which would require a convention of not using them on the Scheme side... >> 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. …and as you say here, having to have such a convention is not in the usual spirit. I think you’re right that enforcing a separation is not a good idea. If this makes sense it would have to be because we trust users working in scheme to still use #t and #f. > 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. I definitely agree that ## is better than #'#. My idea was to provide a way for users to avoid having to use Scheme at all for simple booleans (so no # needed). I think \true is easier and prettier than ##t in the simplest cases, which leads to the question of whether it is worth the potential confusion if people start using “true" and “false” in Scheme. I’m not sure whether it is or isn’t... > 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. You’re probably right. It may depend somewhat on which users we want to prioritize. This kind of thing makes most sense for users who will never need to use/learn scheme to do what they want to do. It won’t affect experienced users who know it’s better to use idiomatic #t and #f in Scheme. In between are those this might trip up… and we probably have a lot of folks in that middle ground... > 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. Good points. When we get to Guile 2.0 then the readability concern can be addressed by using ##true and ##false, so that part is no big deal. Thanks for considering this. I trust and defer to your judgment and that of others. Those who want to use this syntax can of course easily add it in include files, etc. Cheers, -Paul _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
