Han-Wen Nienhuys <[email protected]> writes: > On Mon, Nov 23, 2009 at 11:56 AM, David Kastrup <[email protected]> wrote: >> >> Hi, >> >> in the course of seeing how much code can be shared between >> define-builtin-markup-command and define-markup-command, the main >> difference appears to be scope. >> >> That's not much of a problem: just call the defining command, then >> (export ...) the result. Except that lilypond jiggles with symbols and >> procedure properties and similar in some functions. I quote: > > The Lilypond language has a concept of scoping, ie you can do > > > foo = 1 > > #(begin > (display (+ foo 2))) > > with \paper, \midi and \header being nested scope inside the .ly > file-level scope. "foo = 1" is translated in to a scheme variable > definition. > > This implemented using modules, with each scope being an anonymous > module that imports its enclosing scope's module. > > The reason to put some functions ("builtin") outside the .ly level, is > that in case of > > lilypond a.ly b.ly > > we want to reuse the built-in definitions, without changes effected in > a.ly leaking into the processing of b.ly
Wouldn't just putting the built-in definition at public scope accomplish that? define-builtin-markup-command and define-markup-command have a lot of code duplication. Now this is sort of a special command because there will rarely if ever be any need to use define-markup-command in Lilypond itself (creating a private markup). Assuming that we do need both for some defining word, wouldn't something like (define-toplevel-alias (define-builtin-markup-command arg1 arg2 . rest) `(define-markup-command ,arg1 ,arg2 . ,rest) :exports `(,arg1 ,(symbol->keyword arg1) ...)) or the respective equivalent code (which is straightforward enough except that something like the above contraption could autogenerate the doc string) be much better than copy&paste of the definition and replacing every defining word with define-toplevel* or similar? -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
