Re: preliminary GLISS discussions

[Han-Wen Nienhuys]

On Thu, Aug 30, 2012 at 9:21 AM, David Kastrup <address@hidden> wrote:
>> Is there a complete proposal of what is on the drawing board? Barring
>> that, is there a list of (perceived) problems in the current
>> syntax/parser?
>
> The possible values for music following a skipped optional argument are
> constrained to music parseable without lookahead because the decision

I had to let this sink in for a bit, since I had completely missed
that a patch doing optional music arguments had went in. Had I noticed
in time, I probably would have complained (and we might have ended up
in a flamewar).

I have become convinced that optional, unnamed arguments are not a
happy design decision, in any language. In Lily it's particularly
problematic, since we don't group function parameters.  It was already
difficult to understand in

  \func \a \b \c

what the arguments of \func would be (you have to know the arity of
the function); now you have to understand the types of \a and \b as
well as how \func may interpret those.

If you are not afraid to break existing users, optional arguments
(including  \relative) would be the first things to throw out to make
things simpler.

Assuming '-' is compulsory on post-events, you could group things
using ( ) and ,

  \transpose( c', d',
    {
      f g a

    }
 )

or maybe

 \transpose { c' d'
 {{ %% sequential
    f g a
 }}
 }

or even using keyword arguments

 \transpose @from c' @to d' {
   f g a
 }

If the problem is the language being too implicit, or the parser being
too complex, they could be avenues to pursue.

Of course, we have to first agree that the problem to be solved is
parser complexity, and not lack of conciseness / excess of red tape.
Over the years, we worked very hard to cut as much syntactical red
tape as necessary. This has left us with a parser that is hard to
understand.

All of the examples above look jarring to my eye; btw. The basic
expression in lilypond looks like

  c4 d4

rather than

  c4 , d4

ie. elements of the language have no explicit separators. That implies
that we have to do lots of lookahead and precedence twiddling to
determine how to group parts of the language.

> for skipping requires evaluating the music expression first before
> letting the parser change state or pushing back a synthetic token which,
> again, is only possible when there is no lookahead token yet.
>
> This is stalling things like
> <URL:http://code.google.com/p/lilypond/issues/detail?id=2067> and leads
> to behavior surprising to users.

Why should this be in a music function at all? If the user knows
enough scheme to understand that "port" means file, he would be expert
enough to write the expression in Scheme anyway?

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