[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lilypond Syntax Development and 3.0
From: |
David Kastrup |
Subject: |
Re: Lilypond Syntax Development and 3.0 |
Date: |
Mon, 27 Jul 2009 13:31:35 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) |
A few comments from a consumer...
Graham Percival <address@hidden> writes:
> SUMMARY
>
> Start: Sep 2009.
>
> Length: 6-9 months. We're not going to rush this.
>
> Goal: define an input format which we commit to being
> machine-updateable for the forseeable future. Any future patches
> which change the syntax in a non-convert-ly-able format will be
> rejected. (subject to the limitations, below)
>
> LIMITATIONS and SCOPE
>
> - We're going to have lots and lots of emails flying around. They
> don't really fit into either -devel or -user, so we'll use a
> mailist on lilynet.net. Maybe the already-created proposals
> mailist, maybe a address@hidden mailist.
Huh? Why would a discussion about syntax not fit into -devel?
Anyway, here is my thought: we want a reliably machine-readable and
writable input. Everything that does not concern the art of typesetting
should be accessable easily from a C parser library. Of course I have
my own pet language for manipulating score material (Lua), but then many
people do.
If one has something like a flex/bison syntax and/or a parser library
and/on definite rules for what can, can't be done, then one has a lot of
flexibility.
The level one would like is that reading lilyput input and writing a
lilyput input file that does the same, just transposing a voice, should
not take more than 10 lines of code/script. Also reading an input file
and writing an equivalent input file (just not using \input anymore)
should be easy to do.
In a similar vein, score editors should be able to export and import
Lilypond code with an expectation of not having information loss occur
(short of whitespace/source formatting, and possibly that can be
preserved using intelligent schemes as well that keep track of manual
source line breaks, indentation and comments).
--
David Kastrup