On Thu, Aug 30, 2012 at 9:21 AM, David Kastrup <d...@gnu.org> 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 - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel