Re: GOP2-5 - GLISS discussions

[John Mandereau]

Il giorno gio, 13/09/2012 alle 23.13 -0700, Graham Percival ha scritto:
> 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).

Why splitting the language instead of just extending it?  Could that
"additional layer (ly2/ly++/lyz/whatever) be just a set of .ly/.scm
files that get loaded on top of the main ones, like we have now with
makam.ly or gregorian.ly, or if it's not feasible replace default
init.ly with an alternative init file?  I mean, having a so different
pre-processed language that it would require a new parser and a new
lexer would make maintenance and error reporting of music languages (the
"ly++" preprocessed one, ly and scheme) harder, for a possibly limited
gain, whereas the ongoing work of David on the parser brings more power
to the user without the cost of an extra language.



> ** 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.

I'm busy again in life as usual and my time for LilyPond dropped again,
but I want to get something done anyway (maintaining Patchy, put some
effort in GUB, routinely fix little bits of the build system...);  so,
even if I'm in a quite different situation from David, I can
euphemistically say too "I've been distracted by syntax "discussions"".
I may not understand more than the average reader of this list
technically developed replies from David to recent language changes
proposals, but I found it irritating that discussion went on ignoring
his replies.  If I had the authority for this, I would recommend to
define the problems well and try to understand the parser a bit better
to avoid long fluffy threads and have instead productive discussion
(i.e. each proposal end up with some patch or dies after a few
messages); however, the passion that the ly language raises makes it
somewhat unlikely, so if fluff about language can't be avoided I vote
for a separate list, having the bad feeling that, seconding opinions
already exrepssed by others on this list, a significant amount of time
and energy may be wasted on that "quacks" list, that may be better spent
learning about lily internals, the parser or whatever else.

What I just wrote might sound condescending, but I have no particular
knowledge on LilyPond parser myself, it partly explains why I haven't
take part in recent discussions about syntax and language, and it is
motivated by spending energies in the project in an efficient way.



> ** 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.

"the ly language" is certainly a better term than "syntax" in some
contexts of discussion (such as the names of the reserved words and
predefined functions), especially as no hard line can be drawn between
syntax and semantics of the ly language.



> ** 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.

LilyPond is a software program, not a vague topic of discussion, so I
don't see the point of discussing technically infeasible ideas, other
that feedback from knowledgeable programmers could motivate authors of
"proposals" dive into the parser and think again so they come up with
better ones (i.e. with patches) at the next iteration; so to repeat the
beginning of my comment to "** Motivation" above, IMHO only passion
about language fluff can motivate the creation of a separate mailing
list to avoid lengthy unproductive discussion on -devel list.



> ** 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.


My gut feeling is that a target for standardization of some LilyPond
music representation better than the ly language could be some
intermediate format with music streams, with conversion back to ly using
a kind of displayLilyMusic function:
- David has announced that the parser is not stabilized and may needs
work for many months, so I'm not sure what "very slowly and cautiously
declare certain portions of the ly language as not open to future
changes" means, if it's not the product of people who know enough of the
parser and ly language, or even better the class of input files that are
left unchanged by applying some yet-to-be-created extension of
\displayLilyMusic to the parsed input;
- I generally feel bad about declaring some parts of the language frozen
and then a few years later discovering that changing something frozen is
actually highly desired.



> ** 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.

Ideally, this should *require* a patch which does not introduce
conflicts in the parser.

My two cents,
John