Nicolas Sceaux <nicolas.sce...@gmail.com> writes: > As a maintainer of 100+ Mbytes of LilyPond files, I'm very interested > in this topic. > > IMHO, we should aim at stabilizing what is currently hardcoded in the > lexer and parser (notes, file structure...). Nowadays, only David > works in this area, he has the best expertise on the subject, and he > probably knows what best should be done.
I am mostly working on extending the range of things that "just work". The main thrust is to stay upwards compatible. There are cases like footnote syntax where the "most natural" argument order now is not available due to technical reasons. In a similar vein, some of David Nalesnik's (and Harm's) functions require things like quotes around "Staff.NoteHead", something that should at one point of time become unnecessary. Moving that sort of complexity into the parsing possibilities of music functions means that the language is more or less open-ended. At the current point of time, there are a number of arbitrary-seeming restrictions when parsing. I am working on lifting them. So basically I am working on getting a framework where a lot can be done at runtime. Of course, it would be nice if one could at one point of time process the syntax of different versions just by plugging in different Scheme and LilyPond startup files. > I don't see how LilyPond files could be converted automatically, without > loss or deterioration, because of their complexity as soon as scheme > extensions are involved. However, if we have a toolkit which allows: > ly-file 'A.ly' -> PDF file 'A.pdf' > ly-file 'A.ly' -> MusicXML-file -> ly-file 'B.ly' -> PDF file 'B.pdf' > where A.pdf and B.pdf are identical, (even though A.ly and B.ly are not) > then a part of the problem is solved. > (I have no clue if this is possible). Not practically, I guess. Reasonably useful two-way XML conversions would be somewhat helpful, but of course that's not a conversion retaining the expressivity of LilyPond as a source file format: for example, most music functions would likely just end up expanded which rarely makes for a well-readable source. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
