Re: stepping down as project manager

[Graham Percival]

On Fri, Oct 12, 2012 at 01:03:38PM +0200, David Kastrup wrote:
> Graham Percival <address@hidden> writes:
> 
> > I'll do the thing
> > which every computer science student should do at least once in
> > their life: I'll make my own language.  I'm not comfortable with
> > the level of abstractions that lilypond offers.
> 
> That's rather abstract.  Is the level too high or low for you?

Too low, I guess.  There's nothing shocking about the things that
I want for people who've followed ideas from the past month and a
half:

- everything is postfix.
- because of all-postfix, all notes (or time events, in the case
  of something attached to the end of a note, i.e. ending a cresc)
  can be extracted with the regex '\b[a-z]' or something like that.
  Basically, any whitespace (or beginning-of-line) followed by a-z
  is the beginning of a note.  Every note consists of
    pitch dur remainder
  with the dur and remainder being optional as per usual lilypond.

  The result is a very easy-to-parse language, both for humans and
  computers.

  I suppose in parser-talk this might be called "top-down parsing"
  (since I begin with all text between {...}, split that into
  notes, then look at each note) instead of "bottom-up parsing" in
  bison (which operates on a per-character basis).  Or maybe it
  would be called "starting a new parser mode for each note".  Meh.
  I'll be taking a course on compilers when I start this work, so
  I'll learn the proper terminology then.

- triplets written with 3:2.  I'll probably use python for the
  language, so having a dictionary of hard-coded rules like
    "\tuplet x:y" => "\tuplet y/x" (or \times y/x )
  will be really easy.  And since it's a python script, it would
  be easy for any user to modify that list of hard-coded rules
  to suit their needs.

- triples can also be written with integers, i.e.
    a4 c a6 c e
  Due to the easy-to-parse language, it won't be hard to replace
  that with
    a4 c \times 2/3 { a4 c e }
  in the final .ly file.

  Will this support weird stuff like 33:12 tuplets?  no, but I
  don't care.  I want simple music to be expressed in a simple
  manner.  If somebody wants 33:12 tuplets then they can add
  their own hard-coded rules to their script.

  In fact, I'm not even going to bother trying to support all
  "standard" tuplets.  I'll implement just enough to work for
  my music, and if anybody wants anything else, they can
  add it themselves and send me a patch.

- of course I'll have some hard-coded rules which take any
  override after a note (in my language) and place it before the
  note (for the .ly file).

- anything else that suits my fancy.  I'm not trying to make a
  general-purpose language here.  I'll be guided by my current
  music.  Whatever works for those, I'll add.  If somebody else
  likes the language and uses it, great!  If nobody does, then
  I'll still be happy.


> > Just like different programming languages make it easier (or harder)
> > to write certain types of programs, a different sheet music language
> > would make it easier to express the type of music that I write.
> 
> I doubt that the best answer lies outside of LilyPond.

I don't see how this language can work inside of LilyPond.

> Whatever wrappers you put around LilyPond, they won't be able to work
> with abstractions that can easily be made to work inside of LilyPond,

Yeah, but I *don't* *care* about most of LilyPond.  You've
probably already spotted a problem that my easy-parsed music
doesn't work with tablature or melismas or woodwind fingering
charts.  Who cares?  I don't write that type of music, so I don't
care if my language fails to deal with it.

Will it fail to allow arbitrary music functions?  maybe; I'm
comfortable with that.  Will my syntax fail to allow
\displaymusic?  probably; I'm comfortable with that.  Will it fail
to parse existing .ly files?  almost certainly; I'm comfortable
with that.  Will it have hard-coded rules?  definitely; I'm
comfortable with that.

> So I am hardly in the position to state that your choices are wrong for
> your own, personal goals.  I just don't see them leading in a direction
> useful for LilyPond itself.

Ok.  I'm comfortable with that.

> Whatever you think useful outside of
> LilyPond would likely be even more useful inside, and if it is not
> feasible to get it there, it probably should.

The first step IMO is trivially-parsable music.  I've repeatedly
tried to move in that direction with postfix notation; those ideas
haven't gone far.

> Trying to pin down decisions before the required knowledge
> and experience are available does not make things easier.

Funny that you mention that.  I was talking about the situation
with my oldest friend (now a professional programmer for the past
11 years).  He couldn't believe that I was spending so much energy
arguing with people who argued against project requirements on the
basis of the current implementation.  I tried to defend it as
being a matter of volunteer open source vs. professional
programming, but it felt a bit weak.  That conversation was the
biggest thing which prompted me to re-evaluate that part of my
life.

A few people here have pointed out that designing a new language
from scratch is very different from modifying an existing
language.  Well, that's what I've decided to do.  Start a new
language, with no guarantees of supporting the wide range of sheet
music that lilypond supports.  The goal is making it easy to
read+write simple music, while still allowing for more complicated
notation than ABC and guido.

- Graham