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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel