Re: Macro pre-processing?

[Aaron VonderHaar]

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 <address@hidden> 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"
> 
>