[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shiftDurations and tempo
From: |
David Kastrup |
Subject: |
Re: shiftDurations and tempo |
Date: |
Tue, 28 Jun 2022 01:04:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Jean Abou Samra <jean@abou-samra.fr> writes:
> 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.
It's a bit foggy to the wizards. It's quite opaque for most.
Here is Bison's take on the conflicts:
lily/parser.yy: warning: shift/reduce conflict on token SCM_TOKEN
[-Wcounterexamples]
First example: "#{" $@1 "\\tempo" text • SCM_TOKEN '=' tempo_range
Shift derivation
start_symbol
↳ 3: "#{" $@1 embedded_lilypond
↳ 51: identifier_init_nonumber
↳ 81: music_assign
↳ 190: simple_music
↳ 201: event_chord
↳ 408: tempo_event
↳ 175: "\\tempo" text
embedded_scm_bare '=' tempo_range
↳ 22:
• SCM_TOKEN
Second example: "#{" $@1 "\\tempo" text • SCM_TOKEN music_list "end of input"
Reduce derivation
$accept
↳ 0: start_symbol
"end of input"
↳ 3: "#{" $@1 embedded_lilypond
↳ 55: music_embedded
music_embedded music_list
↳ 184: music
↳ 186: music_embedded_backup
↳ 180: music_assign
↳ 189: embedded_scm
↳ 190: simple_music
↳ 40: embedded_scm_bare
↳ 201: event_chord
↳ 22: SCM_TOKEN
↳ 408: tempo_event
↳ 174:
"\\tempo" text •
lily/parser.yy: warning: shift/reduce conflict on token SCM_IDENTIFIER
[-Wcounterexamples]
First example: "#{" $@1 "\\tempo" text • SCM_IDENTIFIER '=' tempo_range
Shift derivation
start_symbol
↳ 3: "#{" $@1 embedded_lilypond
↳ 51: identifier_init_nonumber
↳ 81: music_assign
↳ 190: simple_music
↳ 201: event_chord
↳ 408: tempo_event
↳ 175: "\\tempo" text
embedded_scm_bare '=' tempo_range
↳ 23:
• SCM_IDENTIFIER
Second example: "#{" $@1 "\\tempo" text • SCM_IDENTIFIER music_list "end of
input"
Reduce derivation
$accept
↳ 0: start_symbol
"end of input"
↳ 3: "#{" $@1 embedded_lilypond
↳ 55: music_embedded
music_embedded music_list
↳ 184: music
↳ 186: music_embedded_backup
↳ 180: music_assign
↳ 189: embedded_scm
↳ 190: simple_music
↳ 40: embedded_scm_bare
↳ 201: event_chord
↳ 23: SCM_IDENTIFIER
↳ 408: tempo_event
↳ 174:
"\\tempo" text •
Which actually does not look all that different from your analysis.
--
David Kastrup