lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: preliminary GLISS discussions


From: Graham Percival
Subject: Re: preliminary GLISS discussions
Date: Fri, 31 Aug 2012 19:31:42 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Aug 31, 2012 at 01:20:14PM -0300, Han-Wen Nienhuys wrote:
> On Thu, Aug 30, 2012 at 9:02 AM, Graham Percival
> <address@hidden> wrote:

> Automated readers - I am not very convinced about this. Reading .ly
> correctly implies having a complete scheme interpreter at your
> disposal.  Or are we limiting ourselves to cases where there is no
> escaped scheme (including any escapes that are present when using
> identifiers) ?

A syntax highlighter could stick all #(...) in one color, while
still being very useful for "normal" lilypond tasks.  This could
be useful in software like frescobaldi, lilypondtool, or even some
GUI which actually interacts with lilypond files itself.

> All of these concerns have some validity, but can we also think of how
> important each problem is? If we could start over from scratch, there
> is a case for having '-' always. Unfortunately, we are not starting
> from scratch.

Yes, this is true.  The amount of pain caused by any change should
of course be considered.

> Python 3.0 was released in 2008, and has a couple of obscure syntax
> syntax changes, that can be detected and fixed mostly automatically.
> At the same time, inside google we're still stuck with python 2.6 and
> will be for a few years to come, because of all the legacy code.

Hmm, as a casual observer (and still using python 2.6), I thought
that the 2to3 move was going quite well.  It was supposed to be a
5-year process [citation needed], and we're currently 4 years into
that process, and most libraries have been ported [citation
needed] ?

> Think about what will happen to people's scores, and how it would make
> people feel if they have to hand-comb their scores to fix them up.
>
> With the recent news of Sib and Finale's demises, people were quick to
> point out the advantages of open source, but we would not be much
> better if we were to obsolete everyone's .ly files and stop
> maintaining the old lilypond versions.

My initial guess, based on occasionally trying to print out string
quartet or trio parts for casual chamber music, is that at least
30% of mutopia files require manual updates to compile in lilypond
2.14.0.  At the Waltrop meeting, I was talking to somebody (sorry,
can't remember who) who wasn't updating to 2.14 because it changed
the automatic beaming syntax from 2.12 and it was too much of a
hassle to switch.

Yes, changing the syntax is painful.

The basic question is "is it too late to change anything, and can
we mitigate that pain?".  I think it's not too late, particularly
if the change can be done automatically, and particularly if we
promise support for the new syntax.  Alternatively, if it really
_is_ too late to change anything, then let's declare that to be
policy and make a promise not to change things.  (although I see
that the last syntax change was only a few days ago, so that
probably wouldn't fly)

I don't think that we can make any blanket judgements about this.
I think we should discuss each proposal, evaluate it on how much
simpler / more flexible / more powerful / more whatever it makes
the language, how much trouble it will cause, etc.


It would have been nice if we could have done this a few years
ago, but unfortunately we just didn't have the right team in
place.  Now we have:
- David, who is fluent in the parser and low-level scheme (and
  lots of other stuff, too!)
- hard-core developers like Mike, Janek, Keith, etc., who can
  seriously discuss implementation details

We could not have had a serious discussion about syntax changes
back in 2008 or 2009.


> > For the specific example of post-fix modifiers,
> >
> >   a4 \parenthesis b c d
> >   a4 \staccato b c d
> >
> > Which note is parenthesized?  Which note has a staccato?  other
> 
> The question is starting off on from the wrong premise.
> 
> * the command is called \parenthesize. It's a verb, and I don't think
> we have any postfix verbs

Hmm.  If all music functions are verbs, that would be a nice rule
we could tell people.  Better if we could tell people that all
commands which come before notes are verbs... I suppose we could
rename \relative to \relativize ?

However, we _do_ have some users who are not so familiar with
English.  Now, if English was a sensible language then we'd have
some obvious way to denote verbs (similar to capital letters in
German), but unfortunately it's not a sensible language.  :(


I'm not arguing that postfix-only is definitely the best way to
solve this problem[1].  I'm not even arguing that we *should*
solve the problem; maybe all the solutions will cause more trouble
than they are worth.

What I *am* arguing is that we should seriously discuss these
issues.  For the past 5 years I have always given the blanket
answer "no, don't discuss any syntax change; wait until GLISS so
we can do them all at once".  I think the time for this is now --
we certainly shouldn't wait much longer.


[1] in this case, "problem" means the lack of clarity in terms of
which note is effected in:
  a4 \parenthesize b c d
  a4 \staccato b c d

- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]