RE: Evolutionary User Strategy - A Compromise

[Anthony Youngman]

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:
address@hidden
[mailto:address@hidden
.org] On Behalf Of Colin Wilding
Sent: 12 July 2006 11:01
To: address@hidden
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
> address@hidden
> 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
address@hidden
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.

* ************************************************************************ *