lilypond-devel
[Top][All Lists]
Advanced

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

Re: What's the deal with the module system?


From: David Kastrup
Subject: Re: What's the deal with the module system?
Date: Mon, 23 Nov 2009 16:21:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Mon, Nov 23, 2009 at 11:56 AM, David Kastrup <address@hidden> 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





reply via email to

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