lilypond-devel
[Top][All Lists]
Advanced

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

Re: preliminary GLISS discussions


From: David Kastrup
Subject: Re: preliminary GLISS discussions
Date: Wed, 29 Aug 2012 15:15:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Graham Percival <address@hidden> writes:

> At the Waltrop meeting, Janek proposed a number of interesting but
> potentially disruptive changes to the lilypond syntax.  On a
> personal note, I really like most of them, but it will take a good
> chunk of work before they're ready to discuss on the main
> development list.
>
> Further complicating issues is that it quickly became apparent
> that I am not personally qualified to judge if a proposal is ready
> for main discussion.

Wouldn't the purpose of a discussion be to present and discuss
advantages and drawbacks?  The question of _discussing_ a change is in
my opinion quite different from _implementing_ a change.

> For example, one idea was to use postfix notation for (almost)
> everything.  David pointed out that this would wreck havok on music
> functions, and I had to admit that I have no clue what a music
> function is.  I mean, I know that there's \commands, but I have no
> clue what the difference is between \p, \relative, \staccato; other
> than their effect on the graphical+midi output.

Well, this was actually more or less divided into several separate
changes.

One part was to _enforce_ having to write a directional modifier for
postevents, meaning that whenever _ or ^ are allowed, you need to write
at least -, like c4-(-[-\p-~ .  This would admittedly simplify the
parser (and other programs trying to parse LilyPond input), particularly
when music functions like \tweak and \displayMusic and event functions
like \bendAfter and \rightHandFinger get involved.

Another part was to keep the undirectional syntax alive but assign
different meaning to it on an as-case basis.

With regard to providing a simpler interface to humans and computers,
the proposals were somewhat conflicting in their direction, so it would
make sense to discuss them separately where this happens to be the case.

> I'm not enthusiastic about cluttering -devel with preliminary
> discussions like teaching me about music functions vs. whatever the
> other thing are.

I am not enthusiastic about cluttering -devel with non-preliminary
discussions where everybody is assumed to have mastered the topics right
from the start.  There are reasons and implications for some of the
design decisions, and part of the aims of such a discussion is leaving
the participants with a better understanding about what is involved than
the manual might provide.

Frankly, the parser is a mess.  Removing some convenience, like what I
characterize as part one of his proposal, will provide at least some
relief, at the cost of making previous syntax invalid and causing a less
natural look of the music expressions.  It is already possible to use
this part of the syntax proposal as a _convention_.  LilyPond just does
not enforce it.

> At one point there was a mailing list on lilynet for syntax
> discussions, but I'm not certain if that's active.  I could also make
> a new gnu.org mailing list...  but either of those options would
> require anybody interested in that discussion to sign up for a new
> mailing list.
>
> Thoughts?  opinions?  alternatives that I haven't considered?
> These discussions are going to produce a *lot* of emails.

And if they come to conclusions, they are going to produce effects on
everybody.  Including people using "LilyPond as a service".

-- 
David Kastrup




reply via email to

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