As I have already announced elsewhere, I am trying to write a lexer that reads 
the commands and their corresponding syntax via a specification.
In the process, the following questions came to my mind:

1.
For the lexer, a logic of:|Literal & Context => Music-Event |would be ideal.
Thanks to the great documentation (thank you!), however, I suspect that the internal 
logic is actually as follows:|Context => Engraver => Consumed Types => Literal|
If I understand correctly, it should also be possible to determine the allowed 
context of a literal using introspective functions. Is that correct?

2.
Maintaining my lexer seems incredibly easy; when adding new commands, you 
simply update the specification it reads.
The only limitation for extensions is how complex the syntax is allowed to be 
for the lexer to still interpret it.
The decision on how complex the syntax may become in the future determines 
whether the lexer remains performant. It would be desirable if new commands 
could be added without increasing the overall complexity of the syntax.

In my opinion, LilyPond can be interpreted solely using retrospective 
disambiguation.
If you could promise never to allow prospective disambiguation, the lexer would 
remain usable for all future changes.

I walked to the*bank*  and*fished*. (retrospective)
I*deposited*  money in the*bank*. (prospective)

3.
Which internal structure of LilyPond could I use as a blueprint for the nodes 
of my Abstract Syntax Tree:
music expressions, music classes, or both?

4.
Is there a practical way to extract the vector paths of the glyphs for my 
editor so that I can use them as a|QPainterPath|  in Qt?

Best regards,
Christian||


Reply via email to