I would have embraced the current syntax a lot more readily if the documentation/tutorial had included your explanation of what the parser and location arguments can be used for, as you've Han-Wen has just explained. Just reading it makes me want to sit down and start defining new music functions!
I suggest including that information, along with an example of defining a new variable using 'parser' in the documentation. IMO the appropriate place to add this would be <http://lilypond.org/doc/v2.8/Documentation/user/lilypond/Extending-music-syntax.html#Extending-music-syntax> Cheers, Aaron V. On Tue, 02 May 2006 10:44:08 +0200 Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > Graham Percival schreef: > > In all honesty, I'm with Geoff on this one. All the #() stuff > > looks scary, and having the "parser location" "non-arguments" (I > > mean, they're never referenced in the actual code) was the straw > > that broke my > > They are if you do real-world stuff. In particular, the location > argument is there so you give a warning message with the correct line > numbers, using > > (ly:input-message location "this is an error") > > the "parser" argument is there so you can access parser state (eg. > for defining new variables). > > This discussion about having macros and whatnot (which inevitably > comes with supposedly easier to understand fragments pseudo-code) is > the umpteenth one. > > Be warned that I won't accept patches that attempt to add any ad-hoc > programming/macro language features. This has been my position for > the last 10 years, and I don't see any reason to change it. > > I recommend that people read the GUILE rationale [1] before they > attempt to do any cute "easy" syntax design first. > > [1] http://www.gnu.org/software/guile/guile.html#whatisit > > "The true cost of doing it yourself" > > _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
