Re: Questions regarding Specification and Lexer

Note: Since English is not my native language, I have included the=20
original German version of my message at the end for additional clarity.

Regarding 1. Introspection function for the specification
=2D--------------------------------------------------------

I am currently investigating whether the relationship between LilyPond=20
syntax and its internal structures can be extracted automatically.

The question is:  In which context can a LilyPond command be applied?

For example:

    \key name scale

So the desired lookup would be:

    \key -> Allowed Context

At the moment I can do this manually by following the internal structures.

In the Internals documentation I find the Music type:

key-change-event

which is exactly what I need.

- Syntax:

\key name scale

- Music types: (key-change-event event)

- Accepted by: Key_engraver and Key_performer

I now understand that Engravers are responsible for graphical output,=20
while Performers are responsible for MIDI output.

Looking at Key_engraver I find:

- Music types accepted: key-change-event

- Contexts:
   GregorianTranscriptionStaff,
   InternalGregorianStaff,
   InternalMensuralStaff,
   KievanStaff,
   MensuralStaff,
   PetrucciStaff,
   Staff,
   VaticanaStaff

So I can infer the chain backwards:

\key-> key-change-event-> Key_engraver-> Staff (or specialized Staff=20
variants)

In short:

\key -> Staff

I assume that VaticanaStaff, MensuralStaff, etc. are specialized Staff=20
contexts with different default settings.

The only thing that is not completely clear to me is why \key also works=
=20
in a Voice context. My current assumption is that this is related to the=
=20
context hierarchy: the Music event is not necessarily handled only by=20
the immediate context, but can be consumed by suitable translators in=20
parent contexts.

For \clef this analysis becomes more difficult because the corresponding=
=20
Music type is not as obvious in the Internals documentation.

My idea is that the steps I am currently doing manually could probably=20
be automated with existing introspection facilities.
=2D-----------------------------------------------------------------------=
=2D--------------------------------------------------
I can already automatically list all translators (Engravers/Performers)=20
and the Music types they accept.

I also suspect that the reverse mapping

Context -> Translator

can be extracted automatically from the existing context definitions.

The only step for which I have not found a direct introspection function=
=20
yet is:

LilyPond syntax -> Music type

for example:

\key -> key-change-event

I would especially like to ask David Kastrup whether he sees a suitable=20
way to implement such an introspection mechanism and whether this would=20
be something he might consider contributing.

Does such an internal mechanism already exist, which I have overlooked?

If not, would it make sense to add a small introspection function that=20
extracts this mapping from the Music definitions (define-music-type or=20
similar)?

In the end, this could allow generating the complete specification=20
needed by my syntax highlighter automatically.

This would also make the specification robust against future LilyPond=20
versions.

Would a manually maintained specification still be needed then?

Ideally, a manually written and reviewed reference specification could=20
serve as regression test data (Golden Master / Reference Data) to verify=
=20
that the automatically generated specification is still correct.

Best regards,

Christian



German version:

In der Hoffnung, dass es f=FCr uns alle leichter vers=E4ndlich versuche ic=
h=20
es mal in meiner Muttersprache am Ende der Mail.
Der erste Teil war =FCbersetzt von ChatGBT.


zu 1. Introspektive Funktion f=FCr die Spezifikation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Fragestellung: In welchem Kontext kann \key angewendet werden (\key ->=20
Allowed Context) ?
Dazu kann ich von Hand auf die Suche gehen.

In den Internals finde ich KeyChangeEvent - perfekt, danke!

Syntax: \key name scale.
types: '(key-change-event event)
Accepted by: Key_engraver and Key_performer.

Inzwischen verstehe, ich Engraver sind f=FCr die Grafik zust=E4ndig und=20
Performer f=FCr das MIDI.
Also unter Key_engraver finde ich:

Music types accepted: key-change-event
part of ..context(s) ...: GregorianTranscriptionStaff,=20
InternalGregorianStaff, InternalMensuralStaff, KievanStaff,=20
MensuralStaff, PetrucciStaff, Staff and

VaticanaStaff.

So kann ich also r=FCckw=E4rts Schlussfolgern:
\key -> key-change-event -> Key_engraver -> Staff

Kurz:
\key -> Staff

Ich nehme an VaticanaStaff und so weiter sind nur ein Staff mit=20
speziellen Einstellungen?

Warum \key dennoch im Kontext einer Voice akzeptiert wird kann ich nur=20
vermuten.
Vermutlich weil eine Voice implizit einen Top-Kontext sucht und=20
automatisch einen Staff und einen Score erzeugt? Oder wird das \key von=20
der Voice an den Staff durchgereicht? Nebenbei scheint mir, dass eine=20
StaffGroup nicht automaisch erzeugt wird, richtig?

Bei \clef wird dieses Vorgehen schwieriger, weil der entsprechende=20
Event/Typ nicht so offensichtlich in den Internals auftaucht.

Meine Idee: Was ich da von Hand mache, l=E4sst sich durch verschiedene=20
Funktionen die bereits existieren automatisieren.

Eine Liste aller Engraver kann ich mir automatisch ausgeben lassen. Auch=
=20
die Events, die die Engraver konsumieren. Beides ist mir bereits gelungen.
Ich vermute auch der Schritt Kontext->Engraver l=E4sst sich mit den=20
bereits vorhandenen Funktionen automatisieren?

Der einzige Schritt, f=FCr den ich bisher keine direkte=20
Introspektionsfunktion gefunden habe, ist:

\key -> key-change-event

Also die Zuordnung zwischen einer LilyPond-Eingabesyntax und dem=20
erzeugten Music-Typ.

Gibt es daf=FCr bereits eine interne M=F6glichkeit, die ich =FCbersehen ha=
be?

Falls nicht, w=E4re es sinnvoll, eine kleine Introspektionsfunktion zu=20
erg=E4nzen, die diese Zuordnung aus den Music-Definitionen=20
(define-music-type o.=E4.) ausliest.

Am ende k=F6nnte man eine Funktion schreiben, die die komplette=20
Spezifikation, die mein Lexer f=FCr das Syntax-HighLighting ben=F6tigt=20
automatisch ausgibt.
Damit w=E4re die Sicherheit f=FCr alle zuk=FCnftigen Versionen gegeben. Ic=
h=20
habe =FCberlegt ob David Kastrup eine M=F6glichkeit sehen w=FCrde und Lust=
=20
h=E4tte soetwas zu schreiben. Ich =FCberlege zudem, ob man daf=FCr =F6ffen=
tliche=20
F=F6rderprogamme gewinnen k=F6nnte.

Brauche ich nun keine Spezifikation mehr von Hand schreiben?

Idealerweise k=F6nnte man die von Hand geschriebene und von euch=20
abgesegnete Spezifikation als Regression Test (Golden Master/ Reference=20
Data) nehmen, um zu pr=FCfen, ob die automatische Funktion funktioniert.

Sch=F6ne Gr=FC=DFe

Christian