Re: preliminary GLISS discussions

[Han-Wen Nienhuys]

On Thu, Aug 30, 2012 at 9:02 AM, Graham Percival
<address@hidden> wrote:
> That's why I wanted to make sure that proposals are in "good
> shape" before discussing them on the main list.  But there seems
> to be general consensus that we want to discuss all proposals here
> anyway, so I can roll with that.
>
>> For example, I understand that requiring '-' for every post event
>> would simplify the parser. At the same time, it is not clear to me
>> what benefit simplifying that part of the parser will bring us.
>
> - people writing automated lilypond importers or exporters
>   (including algorithmic composition)
> - people reading/writing lilypond scores manually (see below).

Automated writers are a non-argument: exporters can choose to prepend
the '-' always.

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) ?

I don't see people implementing a parser with the scheme hookup
independently (as it would have to be compatible with LilyPond), and
neither do I see people integrating the lilypond parser itself,
because there is no way to separate it out from Lily, and it brings
all the headache of integrating GUILE into a program.

Manual readers: there is a point for having more consistency, although
some of the confusion can be alleviated by careful formatting.

  c4\> c4\! c4

vs

  c4 \>c4 \!c4

suggest different things, but I think we can train people to write the
former form automatically.

Manual writers:  can we make up our minds here? I've always been
against frivolous syntax for shortcuts (one example in particular is
the "q" for repetition).  Why do we put in "q" for users to save some
keystrokes, and at the time propose to require a mostly redundant '-'
in front of zillions of postevents?

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.

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.

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.

I think we can reap some of the benefits of the proposal (eg. naming
spanner identifiers consistently) without breaking anyone, and we
could focus on those.

>> Before we go around proposing solutions, it would be good to know what
>> problems we are trying to solve.
>
> 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

* "Which note is parenthesized" suggests that parentheses can only
happen on note level, where as a4 -\parenthesize-. is syntactically
valid and (hopefully) produces a staccato dot with parens.

> than memorizing all lilypond commands and/or experimenting for
> each command, how can the user determine the difference?
> with a post-fix sytax, it's much more clear:
>
>   a4 b-\parenthesis c d
>   a4-\staccato b c d
>
> The initial proposal was that all "modifiers" should be postfix.
> i.e. the syntax is
>   NOTE-NAME DURATION -(any modifer to that note)
> That could simplify syntax highlighters, converters, etc.  A more
> extreme version of this thought is to use explicit delimiters for
> modifications, i.e. something like
>   a4 b4{ \staccato }
>
> David pointed out that this would look extremely weird for music
> functions such as \relative, so Janek and I are re-thinking the
> proposal.  Jan threw out the idea that music functions could be
> denoted with a different symbol, i.e.
>   @relative {
>     a4 @parenthesis b c d
>     a4-\staccato b c d
>   }
> but that was just an off-the-cuff remark after 30 seconds of
> thought.  It may or may not be a great idea.
>
>
> These ideas are obviously not fully "fleshed out", but this makes
> a good example of the meta-discussion of how we want to organize
> the discussion of such ideas.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen