lilypond-devel
[Top][All Lists]
Advanced

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

Optional function argument semantics: taste poll


From: David Kastrup
Subject: Optional function argument semantics: taste poll
Date: Fri, 04 Nov 2011 16:10:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

Hi,

I am still overhauling the optional argument parsing to deal with the
issue of lookahead-free but restricted values.

I am already at the stage where I am able to accept 3\cm as an optional
parameter.  The trick is that I parse without lookahead, get the 3, ask
the predicate whether 3 is ok, and if it is, I _commit_ to the result
and do a full parse not bothering about lookahead, rechecking the
result.

There are some problems with that approach: a restricted value set for
example.  3\cm itself is a nice example: if I have the predicate
integer?, then 3 gets read, parsing decides to commit to a number, \cm
gets read, and 3\cm no longer fits the predicate, so Lilypond complains
instead of skipping either just \cm or the whole term, hoping to match
them to a possibly following mandatory number? argument.

I am not bothered about this: the input is confusing enough, and the
purported order of argument types fragile enough that an error seems not
out of place.

I am somewhat more worried about fractions: when writing them as 3/4,
they are unproblematic since they are deciphered in the scanner.
Writing them as 3 / 4, this gets trickier.

With the above approach (check whether the predicate fits after just 3),
we have the absurd situation that an optional argument of type fraction?
won't match 3 / 4 (since it gives up after 3), while scheme? has no
problem (it continues after 3, and sees the rest of the fraction).

Basically, I have two choices:
a) don't try to match, optional fractions are not accepted in wide form.
b) when a predicate does not match an INTEGER x, I check whether it
   matches (cons x 1), and if it does, I continue parsing on the
   assumption that a fraction is likely to occur.  If this assumption is
   wrong, I get a syntax error since x can't be backed up once I
   looked at the next lookahead token and discovered it is not /.
c) let fraction? as well as Lilypond interpret integers as x/1 when
   required.

Personally, I vascillate between preferring a and b.  b does not exhibit
the strange behavior that scheme? can accept a certain form of optional
fraction that fraction? itself can't.  And it does that without mixing
integers and fractions conceptually.  It just says "Ok, you fooled me,
and it is too late to correct that.  Syntax error."

Option a seems like a reasonable restriction as well, since one, as far
as I can see, _can_ enter tight fractions in every mode where wide
fractions would also work (music function calls in figured bass would be
a challenge anyway, I guess).

Actually, Scheme with its own rationals has no qualms about 3/5 being
totally different from 3 / 5.  Retiring the wide syntax would certainly
be the cleanest option, and grep does not show any actual use of it in
our tree.  It does not seem like many people are aware of it.

Yes, it seems like I am already on my own private GLISS project.  With
the thought in mind that fading out 3 / 5 is likely best in the long
run, option a requires the least amount of work and logic.

-- 
David Kastrup




reply via email to

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