lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: parser.yy: remove `fraction' (issue 6399045)


From: dak
Subject: Re: parser.yy: remove `fraction' (issue 6399045)
Date: Sun, 15 Jul 2012 09:14:00 +0000

message: On 2012/07/15 05:07:13, Keith wrote:
On Sat, 14 Jul 2012 19:14:41 -0700, <mailto:address@hidden> wrote:

> Do we have evidence of people using 2/ 3 anywhere?

I don't know of any scores with spaces alongside the / .

As far as I know, it has never been documented or demonstrated.  The
previous support in the parser was more likely than not added because
the lexer historically did not support fractions in all modes.  That was
changed about half a year ago without complaints.  A conceivable reason
_not_ to allow fractions in all modes would be that in some contexts,
2/4 was not a fraction (which is translated to a pair of numbers) but
rather a numeric _expression_ (which would be translated to an actual
Scheme rational 1/2 indistinguishable from 2/4).  As a side effect of
parsing 2, /, 4 as separate tokens, white space between them did not
matter.  But I don't think this was ever documented as a feature or even
used.

I don't know _any_ place in the LilyPond code base where numeric
expressions are documented or used (possibly excepting unary '-'). The
respective section in parser.yy starts with

/*
        UTILITIES

TODO: should deprecate in favor of Scheme?

 */

and that would make sense and apparently has been effectively done for a
long time.  Scheme also assigns unique meaning to things like 1/2 but
admittedly its expression "syntax" does not lend any ambiguity to that.

I am currently doing some lexer/parser work, and the lookahead needed
for dealing with that kind of ambiguous stuff causes a lot of
complexity.  I prefer to have as little code of the "maintainable by
David when he is having a really good day" kind in the parser as
possible.

While adding convert-ly rules for restrictive syntax changes is in
principle a good idea, on the current LilyPond code base its sole effect
would be to change figured bass code to the worse, possibly rendering it
invalid in addition to illegible.

So my preference would be to leave convert-ly alone.


http://codereview.appspot.com/6399045/



reply via email to

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