http://lilypond.org/~graham/gop/gop_6.html
** Summary
We’ve gone over the same arguments a number of times, so let’s try
to resolve them. Fluff will go on a new mailing lilypond-quacks
mailing list. Serious proposals, if any, will go to
lilypond-devel. Anybody with a serious proposal must be familiar
with the Extending manual, must write up a formal proposal, will
be subjected to multiple rounds of questioning, etc.
I think it’s also time to consider splitting the language in a
manner similar to TeX and LaTeX. Namely, the current language
could remain (almost?) unchanged, while an additional layer (ly2?
lz? ly++ ?) could provide an easier way to write music, which
would then be translated into ly for normal compiling. This could
resolve a great deal of friction between people who want more
“syntactic sugar” and those who want less sugar (or at least, no
more than current).
** Motivation
Before stabilizing the syntax, I think we should have a discussion
about possible changes. Many people would like to talk about the
ly "language" (regardless of whether that involves the parser,
lexer, naming of functions and keywords and pitches, etc). Whether
“possible changes” means a “1% chance” or a “0.00001% chance” is
irrelevant at present. The goal is to share ideas. If you don’t
like fluff discussions that will probably go nowhere, don’t read
those emails.
I don’t know how to make this more clear. We want to have free
discussions, with no expectations of anything being implemented.
If this doesn’t seem appealing to you, there is no need to panic.
Some people enjoy singing in choirs; other people enjoy playing in
rock bands; other people listen to electronica. There is no need
to complain about other people’s leisure activities just because
you don’t enjoy those activities.
** The ly language
There’s some ambiguity in the term "syntax" (at least, some people
might understand that word in different ways. So I’m coining a new
term: "the ly language". This refers to anything that takes place
inside a ly file.
** Mailing list
I suggest that we discuss possible modifications to the ly
language to syntax on a new lilypond-quacks mailing list. These
ideas are not formal proposals, and will not be acted upon. In
exchange, nobody on that email list will complain about
technically infeasible ideas, wasting developer’s time, having to
defend the parser, or anything like that. That list will welcome
all members – there will be no expectation that people discussing
ideas will be familiar with the parser, be capable of producing
patches, or even will have read the Extended manual. The intent
behind moving informal ideas to a separate list is to avoid
causing programmers any worry from technically infeasible ideas.
** ly++
The current format needs to have a one-to-one correspondance (or
“bijection”) between ly and scheme. Graphically, the process is
something like this:
ly <--> scheme -> pdf/midi
However, some ideas on the lilypond-quacks list might not allow an
unambiguous translation from scheme to the potential new syntax,
despite having an unambiguous translation from that new syntax to
scheme. It might be worth considering extending the processing
chain:
ly++ -> ly <--> scheme -> pdf/midi
At the very least, it’s worth keeping these translations between
layers in mind; if no scheme->language translation is possible,
then that idea is not suitable for the ly language and could only
possibly be used in a theoretical ly++ language.
** Language standardization
The "standardization" part, wherein we very slowly and cautiously
declare certain portions of the ly language as not open to future
changes, takes place in:
https://github.com/gperciva/lilypond-extra/tree/master/gliss
http://lilypond.org/~graham/gliss/
This process will begin a few months after we begin having open
and friendly discussions about the syntax on lilypond-quacks.
** Formal proposals
If somebody has a serious suggestion for a change to the ly
language (with the exception of renaming internals, which we do on
a completely ad-hoc basis), there will be a much more involved
process.
Ideally, this will include a patch, examples of ly files before
and after the change, at least two weeks of discussion (similar to
GOP), etc.
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
