[Top][All Lists]
[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
Re: music function patch, Han-Wen Nienhuys, 2006/09/18
- Re: music function patch,
Erik Sandberg <=