Something I thought of (having seen the comment about convert-ly using grep ...)
I've got an on-off thing about writing a DATABASIC compiler (never mind) and have come across a tool called Antlr. It is a compiler-compiler and generates lexers, parsers and treeparsers. IF someone wants to put the effort in, it may (or may not be) easy to define various grammars to read in and chuck out different music formats. It sounds as though a lot of the problems (like the swap between < > and << >> for example) would be easy. Especially given lilypond's structure it looks like it would be fairly easy to define grammars which can read in or chuck out different lily version syntaxes, even the \addLyrics / \oldAddLyrics thing maybe. The disadvantage of going down this route is I can see maintenance of convert-ly becoming a big task. The advantage is that adding a new input or output syntax is simply a matter of adding another grammar definition. Only rarely are we likely to have to write a grammar to transform convert-ly's internal representation - just when either (a) we add a completely new 3rd-party format to the tool, or if there's a major syntax change in lily that requires a paradigm shift ... Cheers, Wol -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] .org] On Behalf Of Colin Wilding Sent: 12 July 2006 11:01 To: lilypond-user@gnu.org Subject: Re: Evolutionary User Strategy - A Compromise This is an important dilemma for many users, I think - we want to have all the fixes and features in each new version, but find it frustrating when music produced in earlier versions needs time-consuming manual editing to upgrade. Can I suggest a compromise? I accept that Lilypond has been evolving rapidly and feel privileged to have been able to use it (and contribute comments) during that evolution. At some point, though, the evolution should slow down: the developers should feel happy with the basic structure and syntax and the users should be able to expect that music written for today?s version will look the same in tomorrow?s. How about making a resolution that from version 3.0 onwards Lilypond will be backwards-compatible: in other words, the current version will correctly display a file written in any earlier version 3.x without the need for conversion. For the developers that would mean retaining the behaviour of the earlier versions, but only back as far as 3.0. For the users it would mean that once they had updated their files to 3.0 they could continue to use them without further modification if they wished. If the backward compatibilty subsequently became a burden then the developers could start again with version 4.0 and write a convert-ly just from 3.x to 4.0. Colin Fairchild wrote: > > LilyPonders - > > Users dealing with LilyPond as it evolves are presented with difficult > choices, none good. > > If one knows a score will be completed quickly, never be revisited, and > components of the code structure never will be reused, the choice is easy: > save and share graphics only, dump the ly files for completed scores, and > move on to the latest stable version. I'm not that prescient. > > Constantly adopting the latest version allows use of the latest features, > feedback helps the developers, and the developers provide support. > However, > modifying 'finished' scores to be acceptable by the latest version is not > reasonable. Upgrade modifications require significant effort. The > convert-ly program helps, but misses a lot. > > It is tempting to select a stable version and stick with it. Scores can > be > revisited easily. Syntax and semantics are stable. Downside: the feature > set never gets better and support will fade away unless a sufficient > number > of users make the same choice and help each other. > > It is possible to maintain multiple LilyPond versions. This allows > revisiting old scores, but at a price. The operational environment > becomes > more and more confusing as versions accumulate. > > I have coded tens of scores, most with version 2.4.6, and spent several > hours attempting to move just one (a smaller one) of them to 2.8.5. After > using convert-ly and correcting for its errors, much remains to be done, > especially to position the right text font. Conclusion: repetitive > conversion of scores is untenable. > > The only reasonable solution is to maintain upward compatibility in the > LilyPond processor. New features should be added without changing > existing > syntax. If it is deemed absolutely necessary to change semantics or > define > conflicting syntax, provide for optional interpretations based on the > version specified. Older ly files should generate consistent results as > LilyPond migrates. More exhaustive regression tests are necessary. > > If you can identify a better way, or have other comments, please respond. > > - Bruce > > > > _______________________________________________ > lilypond-user mailing list > lilypond-user@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-user > > -- View this message in context: http://www.nabble.com/Evolutionary-User-Strategery-tf1906879.html#a52859 41 Sent from the Gnu - Lilypond - User forum at Nabble.com. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user * ************************************************************************ * This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 8272 5300, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333. * ************************************************************************ * _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user