[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
music function refactoring
From: |
Erik Sandberg |
Subject: |
music function refactoring |
Date: |
Sat, 28 Jan 2006 15:22:31 +0100 |
User-agent: |
KMail/1.8.3 |
Hi,
I'm performing some refactorings, which aim to fix the "\partcombine cannot be
inside \relative" bug mentioned in section 8.3.1 (plus other similar
problems).
My plan is:
1. Postpone the applying of music functions: Store all music functions as
music wrappers, and apply the functions after parsing, using a new
toplevel-music-function called apply-music-functions!. This function
recursively searches for music functions to apply, and when it finds one, it
recurses into its arguments before applying it.
2. Make \relative a music function, but prohibit apply-music-functions! from
recursing into its argument.
3. Practical utility functions that work well in \relative mode can be
written, for example:
\relative { c d \interpolate { c c' } b c }
=> { c' d' {c' d' e' f' g' a' b' c''} b' c'' }
AFAICS (1) has minor negative consequences: There will be problems with
relying on side-effects of music functions. For example, variables defined by
music functions can't be used until the next top-level music expression
(still possible with inline #(..)-functions), and it causes problems if you
want to do side-effects on the parser (it will be confusing to mix #(foo ...)
functions with \foo functions, since all \foo functions are called after all
#(foo ...) functions).
--
Erik
- music function refactoring,
Erik Sandberg <=