On Thu, Aug 13, 2009, Graham Percival <gra...@percival-music.ca> said:
> On Thu, Aug 13, 2009 at 09:28:02AM +0200, Marc Hohl wrote: >> I mean, we code and read music from left to right, so >> it seems nore natural to me to have the command changing >> the behaviour of a note in front of it. Some like postscript and HP calculators (3 5 7 multiply swap divide), some , especially multi-lingual have trouble with operator precedence is (a & b | c & d). (a&b) | (c&d)) or (a & (b|c) & d) or (((a&b)|c)&d) or... Physical proximity provides an intuitive association that can be false, but is more easily seen than rule-based associativity. The use of '\' to preface both function tokens and operator tokens allows an omission of whitespace before the token, and this allows a left-associative operator to be adjacent to its operand. Both right-associative operators and functions must be setoff by whitespace from their operand(s) for the tokens to be distinguished. a b c d\lefty e f g (above) \lefty has an intuitive association with the d. a b c \righty d e f g (above) \righty is intuitivly ambiguous, (below), \righty has a false intuitive association with the 'c' a b c\righty d If all \foo were right-associative it would be easy to read them. Is it possible to make monadic operators right-associative so as to end this confusion? Yes, i realize this could have a nasty impact; if done at all it would mean devising a new set of right-associative operators and deprecating the old ones (never eliminating them of course, such being the fate of deprecated stuff). BTW, the average user lumps functions and operators together in his mind as thingys with similar syntax (\foo) that 'affect' notes. Unless the documentation stresses this issue with ample illustrations which are commented to this point it will remain a confusing muddle (do you _recall_ which C operator binds more strongly, left-shift, or prefix-increment?). -- Dana Emery _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
