Re: GOP2-5 - ly language discussions

[David Kastrup]

Graham Percival <address@hidden> writes:

> I suggest that we have a separate mailing list to discuss wild
> ideas. Initially these will probably be about modifications to the
> ly language, but other candidates are mutopia, kickstarter,
> crowd-typeset music, closer ties with online music editors, etc.

I don't think it makes sense to have a separate list I am not supposed
to be reading discussing Mutopia, Kickstarter, crowd-typesetting, closer
ties with online music editors etc.

Instead I would propose a label [talk] in the subject of normal list
postings.  [talk] subjects are not supposed to be subjected to the
scrutiny desirable for decision-making.  People are not supposed to miss
out on substantial matter or decisions by skipping [talk], so once we
are talking serious material, remove the [talk] tag.

> This mailing list will aim to have the casual atmosphere of a
> friendly discussion at a pub or coffee house. To reflect the "wild
> discussions" nature while maintaining a reference a pond of
> lilies, I suggest the name lilypond-quacks. A more mundane
> suggestion would be lilypond-casual-chat.

We can use the [quack] tag as an alternative.

> [...] Sarcastic and disparaging comments about people’s lack of
> knowledge will not be welcome on this list.

> ** Formal proposals
>
> If somebody has a serious suggestion for a change to the ly
> language (with the exception of renaming internals, which we do on
> a completely ad-hoc basis), there will be a much more involved
> process. All proposals must be sent to lilypond-devel.
>
> Ideally, this will include a patch, examples of ly files before
> and after the change, at least two weeks of discussion (similar to
> GOP), etc. At a very minimum, the proposal must take into account
> previous relevant discussions on lilypond-devel, the Changes
> documents, and the Extending manual.

Either we will have double standards here, or I'll be seriously tied
down.  Much of the parser work I am doing is of incremental nature, and
the overall direction includes keeping existing files working according
to expectations as much as reasonable/possible while straightening out
and sometimes extending the underlying logic.  This work is generally
regarded with total apathy (it is not like it is not spelled out in
reviews _if_ anybody could be interested in it) so there is little point
in delaying each step by having to create formal proposals and obeying
two weeks of silence.

> Any omissions or mistakes in a formal proposal may be subjected to
> sarcastic and disparaging comments.

No.  We may have problems getting to a reasonably common ground of
communication and decency, but that does not mean that we should tell
people it is fine to not even try.  The net result would be that the
only people willing to work on LilyPond are rude and thick-hided.

I'd rather say something like "Without the [quack] tag, proposals and
discussions on the developer list have the implied consequence of
leading to changes in LilyPond, so they will also be put under scrutiny
by senior developers, taking time otherwise spent on development of
LilyPond.  Don't waste their time by not bothering to check your
proposals against the basic guidelines and information referenced
above.  If you are not sure, use the [quack] tag."

Since it will presumably happen that developers relabel a followup to an
unsuspecting newbie, it might make sense to prefer the better known and
less loaded [talk] tag over [quack] in order not to give the impression
one is making fun of the original poster.

> ** ly++
>
> One vague possibility might be to split (or extend) the ly
> language in a manner similar to TeX and LaTeX. This GOP proposal
> does not endorse this possibility, but merely mentions it in case
> we end up with vastly divergent informed opinions on the ly
> language.
>
> Namely, the current language could remain (almost?) unchanged,
> while an additional layer (ly2? lz? ly++ ?) could provide an
> easier way to write music, which would then be translated into ly
> for normal compiling. This could resolve a great deal of friction
> between people who want more “syntactic sugar” and those who want
> less sugar (or at least, no more than current).
>
> Such an extension is not intended for any additional functionality
> that could be loaded like gregorian.ly or bagpipe.ly, and any
> argument in favor of ly++ would need to demonstrate that it could
> not be fulfilled with a .ly init file. 

I don't think that this makes any sense.  We will likely want a MusicXML
input layer at one point of time (bypassing the LilyPond parser
altogether) for understandable reasons of reliability and dependability,
and this will cause a definite maintenance cost.  LaTeX/TeX don't work
by preprocessor or translation.  LaTeX is a much extended document frame
work built upon plain TeX.  It seems definitely desirable to me to work
towards hooks, abstractions and infrastructure that enable something
like the separate package and document class ecosystem of LaTeX.  But it
does not make sense to create language translation tools outside of the
Guile/LilyPond framework for that.  LaTeX is built using TeX primitives
and plain TeX commands, and that is pretty much the worst programming
environment imaginable.  The advantage of being able to work with one
integrated system and executable still has outweighed the disadvantages.

In relation to that, Scheme runs circles and loops around TeX.  If you
take a look at a festering abomination like MusiXTeX written in TeX,
much saner subsystems implemented via preprocessor like PMX still don't
have comparable traction.

Ask yourself this question: would you want to implement your ly++ layer
in Guile?  Guilev2 has an integrated parser generator.  It has XML
processing.  It has, naturally, no problem understanding integrated
Scheme, reading and writing it.  I have the suspicion that your answer
would be "not really".  This proposal appears to me to be primarily
motivated by the desire to avoid Scheme altogether.  And that's a dead
end.  We won't get a healthy LilyPond ecosystem based on ignoring its
architecture.

-- 
David Kastrup