Re: [GSoC] Proposal: Modular LilyPond Parser (C++)

"C. Stroppel" <[email protected]> writes:

> Dear Community,
>
> For documentation purposes, in case someone reads this discussion in
> the archive at some point, I wanted to close the loop by letting you
> know that I did not get a spot in the Google Summer of Code. However,
> I hope that the applicants who did get a spot will have a lot of
> success with their projects.
>
> What are the next steps?I will continue working on the project anyway
> and am currently looking into other funding programs. The architecture
> is already almost completely clear in my head.
>
> To summarize, here is what I took away from our discussion:
> + lexer.ll and parser.yy are sufficient specifications.

There are lots of lexical tie-ins where the actual tokens for the parser
are generated as a consequence of evaluating expressions.

This is the case for every \xxx sequence, for every $... expression, and
most particularly for parsing music function and markup command
arguments.

That renders particularly parser.yy a very incomplete template, meaning
that you want to employ lots of heuristics for external parsing when you
don't have the means of actually evaluating the expressions in context.

> + Nevertheless, it was suggested that the lexer could flexibly read
> lexemes and syntax from a specification.
> + Concerns were raised as to whether a parser without Guile makes
> sense at all.

It certainly makes sense in that things like syntax highlighting will
not generally be able to rely on Guile, more specifically on LilyPond's
Guile in the context of a particular document, being available.

> I haven't been able to gauge yet whether there is actual interest in
> my project. Regardless of that, I would like to reach out to you with
> a few questions in the coming days, if that is alright with you. It
> will be better to do that under a different subject line (Questions
> regarding Specification and Lexer), though. Thank you for all the
> examples you have sent me.

The parsing done by available Emacs modes right now is dissatisfactory.
Other IDE support also would benefit from good and fast parsing.
Frescobaldi does a comparatively nice job but that does not mean that
there isn't potential for improvement.

The problem with your project is that you want it to land in a space
where it is thoroughly used by a community that always has a large
interest in keeping its development going.  That is tricky to plan for
in a reliable manner, so there is always the question how to move best
such that your project's fate evolves from being bound to a single
person.  Not all factors here are easy to plan for.

-- 
David Kastrup