lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: music function patch


From: Erik Sandberg
Subject: Re: music function patch
Date: Mon, 18 Sep 2006 15:15:51 +0200
User-agent: KMail/1.9.1

On Monday 18 September 2006 12:46, Han-Wen Nienhuys wrote:
> Erik Sandberg wrote:
> > Hi,
> >
> > The attached patch cleans up music functions:
> > - functions can have any arity, and parameters can be mixed in any way.
> > - implementation: A music function generates a sequence of tokens, so
> > e.g. a (markup? music? scm?) function generates tokens MUSIC_FUNCTION
> > EXPECT_SCM EXPECT_MUSIC EXPECT_MARKUP. After that it's easy to write a
> > grammar to parse the argument list.
> > - there is still a restriction on 'event functions': A function can only
> > be applied to a post-event or chord-element if the function has exactly
> > one music parameter, and if that parameter is last. If this rule is
> > violated, there will be confusing parser errors ("unexpected
> > EXPECT_MUSIC") due my implementation, but I also added an error message
> > which describes the problem in English.
>
> IIRC, this patch is still pending. Can you have a look at integrating this?

BTW, would it be interesting to generalise music functions so they can return 
non-musics as well? It would be easy to add an extra token RETURNS_MUSIC, so 
lexer produces e.g.
MUSIC_FUNCTION RETURNS_MUSIC EXPECT_MUSIC EXPECT_SCM
for an identifier containing a (scm music) => music function, and
MUSIC_FUNCTION RETURNS_DURATION
for an identifier containing a function with no parameters, returning a 
duration.

Advantage: \breve can rewritten as a 0-ary music function; this simplifies our 
grammar slightly (and I think it will make music macros a bit more elegant; 
the way I currently treat identifiers doesn't feel good).

-- 
Erik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]