Re: shiftDurations and tempo

[Jean Abou Samra]

Le 28/06/2022 à 00:15, David Kastrup a écrit :
> David Kastrup <dak@gnu.org> writes:
>
> > Jean Abou Samra <jean@abou-samra.fr> writes:
> >
> > > Le 27/06/2022 à 20:10, Simon Albrecht a écrit :
> > > > Hello everyone,
> > > >
> > > > I’m trying to encode a piece such that I can switch whether or not
> > > > durations will be shifted (note values
> > > > halved/doubled). Unfortunately \tempo isn’t affected by
> > > > \shiftDurations (that would be a sensible feature request, right?),
> > > Go open an issue.
> > >
> > >
> > > > so I tried this:
> > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%
> > > > \version "2.23.9"
> > > >
> > > > durationShiftOne = #-1
> > > > {
> > > >    \tempo #(ly:make-duration (+ 3 durationShiftOne)) = 152
> > > >    \shiftDurations \durationShiftOne #0 { 8 }
> > > > }
> > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > > >
> > > > but unfortunately Lily won’t accept that Scheme expression instead
> > > > of the normal duration.
> > > >
> > > > Can I make that work some other way?
> > > >
> > > > Should the parser be able to take that Scheme expression there?
> > >
> > > \version "2.23.9"
> > >
> > > durationShiftOne = #-1
> > > {
> > >    \tempo $(ly:make-duration (+ 3 durationShiftOne)) = 152
> > >    \shiftDurations \durationShiftOne #0 { 8 }
> > > }
> > >
> > >
> > > You just need to use $ instead of #. See these pages about the difference:
> > >
> > > https://lilypond.org/doc/v2.23/Documentation/extending/lilypond-scheme-syntax.html
> > > https://extending-lilypond.readthedocs.io/en/latest/lily-and-scheme.html#hash-vs-dollar
> > >
> > > The problem is that \tempo has multiple syntaxes (\tempo <markup>,
> > > \tempo <duration> = <bpm> and \tempo <markup> <duration> = <bpm>),
> > > which makes it impossible to accept # here because early evaluation
> > > is needed to disambiguate, I think. I'm no expert of the parser
> > > though.
> > It's sort of like that.  Before looking for a possible following `=`
> > LilyPond has to have made a decision what type the token/expression
> > coming before that has.  It cannot look at the type of a #... expression
> > before deciding to look for `=` but it can (and will) look at the type
> > of a $... expression.
> >
> > Now syntax errors are comparatively unhelpful, so one could try to
> > tentatively accept an #... = ... expression anyway and then barf if the
> > expression type does not support it.  The result would likely not be
> > worse for the user.
> To wit:
> It's debatable whether this partial ability to specify the duration as
> #... but not in the long form including text is worth the confusion.
> Anyone who wants to tackle the resulting parser conflicts is welcome to
> try: Bison appears to do a pretty good job these days proposing
> productions that may trigger the problem when giving the right options.



When you say "tackle the resulting parser conflicts", that means
"add precedences to solve them by making interpretation choices",
not "solve them in a way that always does what the user might intend",
right? As I understand it, there is a shift/reduce conflict on

\tempo <markup>   [here]   #<something> ...

where the single lookahead token #<something> is not enough
to distinguish between \tempo <markup> <duration> = <bpm>
and \tempo <markup> #<more> <unrelated> <tokens>. The only
way to "solve" while not breaking existing use of the second
possibility would be to reduce on

\tempo <markup> [here] #<something>

and thus fail on

\tempo <markup> #<Duration> = <bpm>

as that would be interpreted as

\tempo <markup>
#<Duration> = <bpm> % don't know what to do with this

Does that sound right? I'm interested in understanding the parser
better, but it's a bit foggy for me at the moment.

Thanks,
Jean