Re: [Parser] Lookahead in music function arguments
Werner LEMBERG wl at gnu.org writes:
I lean towards letting numbers in function arguments just evaluate
to themselves, never mind units.
Sensible.
+1. However, it should be documented, together with the work-around.
It was only a couple months ago that David allowed 3\cm to be used as a
number within music. Formerly it was allowed only in \paper {indent=3\cm}
and other such blocks.
Only people reading this mailing list knew about it, none has said they
use it, and I cannot imagine anyone else has stumbled upon it and started
to use it. So there is nothing to document and no desired behavior for
which to provide a work-around.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
Keith OHara k-ohara5...@oco.net writes:
Werner LEMBERG wl at gnu.org writes:
I lean towards letting numbers in function arguments just evaluate
to themselves, never mind units.
Sensible.
+1. However, it should be documented, together with the work-around.
It was only a couple months ago that David allowed 3\cm to be used as a
number within music. Formerly it was allowed only in \paper {indent=3\cm}
and other such blocks.
Only people reading this mailing list knew about it, none has said they
use it, and I cannot imagine anyone else has stumbled upon it and started
to use it. So there is nothing to document and no desired behavior for
which to provide a work-around.
Well, there is a whole lot to document as the state before and after
change is not really given a whole lot of attention in the manual, but
then quite a bit of it is transitory as well. The use of 3\cm in music
is actually not even possible right now since cm itself is only defined
in paper blocks (possibly layout blocks as well) and besides, real
numbers are not recognized in music mode. This was, more or less,
preparing for the situation that we want to use define-scheme-function
for providing functions doing calculations in layout blocks. That is,
after all, quite feasible.
In assignments, things like 3\cm are unambigous as \cm has nowhere else
to go. And as the last function argument of a toplevel function, the
situation would be similar. However, if the function is not toplevel
and not in end position itself, the \cm could equally well be a
different function argument.
I am not fond of the idea of treating last argument specially. In
particular, it implies that the last argument will more likely than
others cause lookahead to occur, and that's the least desirable
situation for having lookahead.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
2012/10/8 David Kastrup d...@gnu.org: Keith OHara k-ohara5...@oco.net writes: Werner LEMBERG wl at gnu.org writes: I lean towards letting numbers in function arguments just evaluate to themselves, never mind units. Sensible. +1. However, it should be documented, together with the work-around. Speaking as a user: I never used 3\cm (don't like it), but I know others did (in \paper ). So no objection from me, and there will be the workaround. Do you suspect other disadvantages/changes than already mentioned? -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
Thomas Morley thomasmorle...@googlemail.com writes:
2012/10/8 David Kastrup d...@gnu.org:
Keith OHara k-ohara5...@oco.net writes:
Werner LEMBERG wl at gnu.org writes:
I lean towards letting numbers in function arguments just evaluate
to themselves, never mind units.
Sensible.
+1. However, it should be documented, together with the work-around.
Speaking as a user:
I never used 3\cm (don't like it), but I know others did (in \paper ).
So no objection from me, and there will be the workaround.
Do you suspect other disadvantages/changes than already mentioned?
There are a few other things that are simply unused and which I consider
phasing out since they don't really fit all too well with LilyPond.
Assignments can do some numeric expressions involving +, -. *. / but
without parentheses. Strings can be concatenated using +. The
consequences for that kind of thing are again involving lookahead. Its
effects are less onerous typically than within function arguments.
Forming expressions in Scheme is straightforward enough that a separate
(and not really documented or used) LilyPond layer that can't really be
used inside of function arguments does not appear to make all that much
sense.
There has been some talk about delimiting arguments. One change with
interesting consequences might be making { ... } equivalent to ##{ ... },
giving { ... } only sequential music grouping meaning when more than
one music expression is inside. This would give a rather painless way
of grouping arguments of arbitrary type. ##{ ... } is not all that
painful either, but it appears more contrived, in contrast. It would,
however, be a way to use things like the above mentioned LilyPond
expressions in arguments _and_ use { } for grouping expressions, like
{ 4\cm + \line-width }. With regard to those expressions, I am still rather
split between ripping them out and documenting them. Allowing them only
delimited within braces as function arguments might be an interesting
compromise.
It would require actually writing \sequential { ... } if you really,
really need sequential music, like as the target of \pushToTag (as a
workaround, \tag could take a look at its target and turn it into
sequential music if it is unsuitable for \pushToTag, but that is a bit
of an invasive change).
So there are a few drawbacks. One advantage would be that #{ #} and { }
would have a perfectly straightforward equivalence.
What I am currently doing is making LilyPond strings (whatever or
what_ever-huh) in function arguments equivalent to symbols if the
predicate does not accept a string. That's sort of a corollary of
turning xxx.yyy into a list of symbols. Of course, the regtests told me
that this disagreed with my too-clever argument list declaration of
\accidentalStyle which used symbols to distinguish
\accidentalStyle #'Voice teaching from \accidentalStyle teaching.
The obvious fix to that is changing the syntax to
\accidentalStyle Voice . teaching
here, or just Voice.teaching. Accidental styles are, due to the current
word syntax, fine without quotes even for piano-cautionary or similar.
Making strings autoconvert to symbols when required releaves the user
from having to learn too many fine distinctions of the Scheme
interfaces. Implementing this is comparatively straightforward. What
is much harder is to decide _what_ input forms should be considered
canonical then and taught to users (and tools).
Two related tracks I am working on is removing special classes of
XXX_IDENTIFIER in the parser, and special classes of XXX_FUNCTION. If
that work is completed, you can do a lot of things using scheme
functions that are not possible right now.
Much is rather hand-wavy right now and without a clear list of followup
consequences and dependencies. powerful, predictable, logical are the
directions I try moving in, while retaining as much backward
compatibility as can be fit into that model. Some strategies regarding
the language design only evolve while I work.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
On Mon, Oct 8, 2012 at 12:48 PM, Thomas Morley
thomasmorle...@googlemail.com wrote:
Speaking as a user:
I never used 3\cm (don't like it), but I know others did (in \paper ).
So no objection from me, and there will be the workaround.
Wait, does David suggest to change things so that we won't be able to
write \paper { indent = 2\cm } ? Or does the suggested change concern
something else?
Janek
PS David, i see that you wrote a long email - i'm sorry but
unfortunately i don't have time to read it :(
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
Janek Warchoł janek.lilyp...@gmail.com writes:
On Mon, Oct 8, 2012 at 12:48 PM, Thomas Morley
thomasmorle...@googlemail.com wrote:
Speaking as a user:
I never used 3\cm (don't like it), but I know others did (in \paper ).
So no objection from me, and there will be the workaround.
Wait, does David suggest to change things so that we won't be able to
write \paper { indent = 2\cm } ?
No, he doesn't.
Or does the suggested change concern something else?
Yes, it does.
PS David, i see that you wrote a long email - i'm sorry but
unfortunately i don't have time to read it :(
I hope this one was short enough.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
On Mon, Oct 8, 2012 at 10:40 PM, David Kastrup d...@gnu.org wrote:
Janek Warchoł janek.lilyp...@gmail.com writes:
Wait, does David suggest to change things so that we won't be able to
write \paper { indent = 2\cm } ?
No, he doesn't.
Or does the suggested change concern something else?
Yes, it does.
PS David, i see that you wrote a long email - i'm sorry but
unfortunately i don't have time to read it :(
I hope this one was short enough.
It's perfect! Many thanks!
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
Hi, On Sun, Oct 7, 2012 at 8:11 PM, David Kastrup d...@gnu.org wrote: [...] In general, not requiring lookahead makes things more versatile. [...] thanks - i think i more or less understand why we prefer not to require lookahead. However, i'm not sure whether you are asking us for any opinion (if so, what is the question, and can we see before/after example?) or just letting us know about lookahead - ? Sorry for being so direct, but i'm very short on time recently :( cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
Janek Warchoł janek.lilyp...@gmail.com writes: Hi, On Sun, Oct 7, 2012 at 8:11 PM, David Kastrup d...@gnu.org wrote: [...] In general, not requiring lookahead makes things more versatile. [...] thanks - i think i more or less understand why we prefer not to require lookahead. However, i'm not sure whether you are asking us for any opinion (if so, what is the question, and can we see before/after example?) or just letting us know about lookahead - ? Sorry for being so direct, but i'm very short on time recently :( I am considering removing existing functionality that's not likely to have seen any use so far, but at least is nailed down in regtests (input/regression/optional-args-backup.ly). So I am looking for objections. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
On Mon, Oct 8, 2012 at 12:46 AM, David Kastrup d...@gnu.org wrote: I am considering removing existing functionality that's not likely to have seen any use so far, but at least is nailed down in regtests (input/regression/optional-args-backup.ly). So I am looking for objections. ok. I think i don't have any. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Parser] Lookahead in music function arguments
I lean towards letting numbers in function arguments just evaluate to themselves, never mind units. In particular integers are used quite often in manners where a unit behavior of identifiers would be rather more than less surprising. +1. However, it should be documented, together with the work-around. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
