"C. Stroppel" <[email protected]> writes: > 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|
I think you need to work more with LilyPond: contexts, engravers, grobs and so on are backend mechanisms. By the time they come into play, the parser is finished. > If I understand correctly, it should also be possible to determine the > allowed context of a literal using introspective functions. Is that > correct? I have no idea what those words mean. > 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) Again, I have no idea what you are talking about here. > 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? Music expressions contain items belonging to different classes. I have no idea what you mean as "blueprint for nodes". Music expressions have a print form. The print form will work as input to LilyPond but does not need to match the actual input. LilyPond input does not solely consist of music expressions either. > 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? There is a Scheme backend. I don't know how useful it is for your purposes. -- David Kastrup
