[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP2-3 - GLISS or not

From: David Kastrup
Subject: Re: GOP2-3 - GLISS or not
Date: Tue, 24 Jul 2012 18:46:09 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Nicolas Sceaux <address@hidden> 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

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 '' -> PDF file 'A.pdf'
> ly-file '' -> MusicXML-file -> ly-file '' -> PDF file 'B.pdf'
> where A.pdf and B.pdf are identical, (even though and 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]