Re: GOP2-5 - GLISS discussions

[Ian Hulin]

On 14/09/12 07:13, Graham Percival wrote:
> http://lilypond.org/~graham/gop/gop_6.html
> 
> ** Summary
> 
> We’ve gone over the same arguments a number of times, so let’s try
> to resolve them. Fluff will go on a new mailing lilypond-quacks
> mailing list. Serious proposals, if any, will go to
> lilypond-devel. Anybody with a serious proposal must be familiar
> with the Extending manual, must write up a formal proposal, will
> be subjected to multiple rounds of questioning, etc.
1+

> 
> I think it’s also time to consider splitting the language in a
> manner similar to TeX and LaTeX. 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).
> 
Interesting idea, but I think we need to decide on the
language-design/concept/fluff discussion-on-developers-list split first.
I've got opinions on this, but I think, given the criteria you developed
re the new list, it needs bouncing around there first.

> 
> ** Motivation
> 
> Before stabilizing the syntax, I think we should have a discussion
> about possible changes. Many people would like to talk about the
> ly "language" (regardless of whether that involves the parser,
> lexer, naming of functions and keywords and pitches, etc). Whether
> “possible changes” means a “1% chance” or a “0.00001% chance” is
> irrelevant at present. The goal is to share ideas. If you don’t
> like fluff discussions that will probably go nowhere, don’t read
> those emails.
> 
> I don’t know how to make this more clear. We want to have free
> discussions, with no expectations of anything being implemented.
> If this doesn’t seem appealing to you, there is no need to panic.
> Some people enjoy singing in choirs; other people enjoy playing in
> rock bands; other people listen to electronica. There is no need
> to complain about other people’s leisure activities just because
> you don’t enjoy those activities.
> 
> 
> ** The ly language
> 
> There’s some ambiguity in the term "syntax" (at least, some people
> might understand that word in different ways. So I’m coining a new
> term: "the ly language". This refers to anything that takes place
> inside a ly file.
> 
> 
> ** Mailing list
> 
> I suggest that we discuss possible modifications to the ly
> language to syntax on a new lilypond-quacks mailing list. These
> ideas are not formal proposals, and will not be acted upon. In
> exchange, nobody on that email list will complain about
> technically infeasible ideas, wasting developer’s time, having to
> defend the parser, or anything like that. That list will welcome
> all members – there will be no expectation that people discussing
> ideas will be familiar with the parser, be capable of producing
> patches, or even will have read the Extended manual. The intent
> behind moving informal ideas to a separate list is to avoid
> causing programmers any worry from technically infeasible ideas.
> 
> ** ly++
> 
> The current format needs to have a one-to-one correspondance (or
> “bijection”) between ly and scheme. Graphically, the process is
> something like this:
> 
>           ly <--> scheme -> pdf/midi
> 
> However, some ideas on the lilypond-quacks list might not allow an
> unambiguous translation from scheme to the potential new syntax,
> despite having an unambiguous translation from that new syntax to
> scheme. It might be worth considering extending the processing
> chain:
> 
>   ly++ -> ly <--> scheme -> pdf/midi
> 
> At the very least, it’s worth keeping these translations between
> layers in mind; if no scheme->language translation is possible,
> then that idea is not suitable for the ly language and could only
> possibly be used in a theoretical ly++ language.
> 
> 
> ** Language standardization
> 
> The "standardization" part, wherein we very slowly and cautiously
> declare certain portions of the ly language as not open to future
> changes, takes place in:
> 
> https://github.com/gperciva/lilypond-extra/tree/master/gliss
> http://lilypond.org/~graham/gliss/
> 
> This process will begin a few months after we begin having open
> and friendly discussions about the syntax on lilypond-quacks.
> 
> 
> ** 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.
> 
> 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.
>
I think patches should be the *outcome* of this stage, where the current
current patch/review process would take over.

This bit would be discuss the kind of thing like "we use properties and
whatnot, how about using the rest of the OOPS stuff like methods"
Example:
JAZombiesFullScore = {
% declarations and music for music for "Pride and Prejudice with      %
  Zombies - The Musical"

}


%
% Two copies of full score in edition, front one is for visually
%   impaired conductors.
\score {
        \Score.setSize 25
% make everything a lot bigger
        \Score.chooseColors Red Yellow
% Red print on Yellow background
        \Score.Midi.writeTo "TheUndeadMrDarcy"
% Produce a midi file
% and write it to "TheUndeadMrDarcy.midi"
        \JAZombiesFullScore
}


\score {
% New score - so standard black and white colours and standard size.
        \Score.Midi.Suppress
% Do not produce a midi file this time.
        \JAZombiesFullScore
}

This is a poor example, but the concept ideas "Who needs methods
anyway", "Yeah lets do inheritance and full OO" or "What's the need for
this when you're writing scores" should have been ironed out on
lilypond-quacks or whatever the list is called.  By the time it gets
onto -devel it should be more working on more detailed design issues,
like compatibility, "does this fit comfortably into the current LilyPond
design?", "is there currently an alternative syntax model which could be
adapted to do this?", "you want the parser and lexer to do WHAT!".

Anyway, let's have the separate list.

Cheers,

Ian