On Fri, Jul 27, 2012 at 12:56:12PM -0300, Han-Wen Nienhuys wrote: > On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival > <gra...@percival-music.ca> wrote: > > Let’s decide whether to try to stabilize the syntax or not. What > > type of project do we want LilyPond to be? What kinds of > > guarantees (or at least firm intentions) do we want to give to > > users with respect to lilypond 2 or 5 years from now being able to > > read their current ly files? > > I think Lily is way past the point for us to decide that the language > needs to be changed in any major way: syntax is not what stops people > from using lilypond, and changing it in notable ways will only drive > people away from Lily.
If we're not going to change a piece of syntax, then why not inform users of that fact so that they can rely on it being the same? At the moment we have something like a "de facto" standard -- if somebody writes a GUI which exports lilypond 2.12 code, then it will probably work in lilypond 2.16. Unless it doesn't, in which case convert-ly will fix it. Unless it doesn't, in which case the GUI fails and the user needs to manually edit the exported .ly files and/or file a bug with the GUI project. Of course, then the GUI front-end needs to either support multiple .ly backends (i.e. "output to lilypond 2.12", "output to lilypond 2.16"). Or else it could drop support for lilypond 2.12 and only output for lilypond 2.16. Regardless of GLISS, we already *are* changing the format in non-convert-ly ways. Just last week, Keith found an example from mutopia that failed to compile after a proposed patch was applied. Now, I still support making that change, but I think we should give users (and programmers of projects which convert or export to lilypond) some hope that simple music won't be changed. I'm not saying that GLISS will necessarily involve any change of notation. I think we should discuss each notation element separately, and we should certainly consider whether any disadvantages of the current notation outweigh the pain of changing. Maybe we'll decide that it's not worth making any changes at all, so GLISS really will just be "input syntax *stabilization*". > We've had this problem for many years in the 1998-2003 period, when it > was a usable but limited program, and people had to re-tweak their .ly > files every few months because we had to get out of a corner we > painted ourselves into. Right. I was good friends with the guy who tried to maintain the rosegarden lilypond export when we were doing 1.6 to 1.8. I think that was when we changed from simultaneous music being <> to <<>> ? I can't remember the specifics, but he was pretty frustrated and in the end gave up. > Rather than "defining" some stable subset (and then getting into a lot > of discussion on what that subset should look like), I think we should > just take the overall decision on intent, that is: what are we trying > to do? My suggestion is: > > * big changes: not OK I agree with this. > * small changes, especially when they clean up things (I'm thinking of > the 4. vs 4.0 change David is working on): in principle OK, but the > upgrade path should either be automatic or cause failure on > compilation. I disagree; we're not going to be perfect with any new syntax. I think it's worthwhile to introduce new syntax for a year or two, find out what works and what doesn't, and fix it if necessary. Just look at all the iterations that footnotes have gone through! > * small changes that do not fall in the latter should be done over two > stable releases. First, you make the old syntax trigger compile > failure, and only the 2nd stable release you introduce a new > interpretation. That requires a fair amount of programmer effort to add the extra error checks and remove them later. > > ** Stability or not? > > > > Stabilizing a language is a tricky process. If you do it too > > early, then you’re stuck with whatever mistakes or poor design > > decisions. > > LilyPond has been around for 15 years, and its basic syntax for 9 > years. It would be weird to suggest that we'd be stabilizing to early. In general, yes. But some aspects of our syntax haven't been around for a long time -- footnotes, woodwind fingering, compound meters, etc. Do we have the best syntax for those? I mean, maybe David can figure out a way to allow us to write \compoundMeter (3+2)/8 or simply \time (3+2)/8 instead of \compoundMeter #(3 2 8) > > and then we guarantee that this file will compile, completely > > unmodified (no convert-ly allowed), for every lilypond 3.x > > version. This seem like a really small step, but I really don’t > > think that we can overestimate how much time, energy, and > > arguments this will require. > > I think this reasoning is red herring. Arguments take as much energy > as the participants want to invest in it. If you spend too much time > on it, stop writing replies to discussions. If people declared somebody as the ultimate dictator of input syntax, then sure we could avoid arguments. But I'm trying to move us to a more inclusive, community-based model of development. It would be nice if we could reach consensus, or at least agree on the advantages and disadvantages of a particular point. So far I think this model has worked for GOP discussions. Yes, they take a *lot* more time and effort than if somebody just declared the answer, but I'm betting that this inclusive method of project management will lead to a better project overall. Occasionally I've side-stepped policy discussions, such as when I introduced the patch countdown, Patchy git-cl testing, and the staging branch. But those instances should be the exception, not the rule. I'm hoping that if we have regular well-researched policy questions introduced on Tuesday and go through the two-week discussion period, developers will be happier and more motivated to work on lilypond. I'm considering this to be an experiment on the time-scale of years, not weeks, and I'm not inclined to change the experimental procedure in the middle of it. > I understand the desire of each of these changes, but I don't see any > of them either: > > * expand on what people can do with LilyPond Other than indirectly possibly motivating people to work on converters and GUIs from lilypond code, I don't see GLISS as adding new features to lilypond at all. Rather, I'm expecting that new development continues as before; after some syntax has been around for long enough that we're confident that it's good, we declare it as "stable" so that users and programmers can rely on it. > * dramatically simplify our parser/lexer code in a way that brings > future rewards. David is working on this. Some of his changes will break user code, and some users will be upset by this. I'm trying to make users feel better by phrasing it as a "give and take" situation. Yes, some things will break, but other things will have a guarantee of stability -- and the area of stability will increase over time. > * dramatically expand our user-base Syntax stability can't hurt converts and GUIs. I hope that GLISS can indirectly increase our user-base by making it easier for people to convert music into lilypond. - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
