[Top][All Lists]

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

Re: A few questions regarding markup

From: David Kastrup
Subject: Re: A few questions regarding markup
Date: Mon, 16 Nov 2009 07:15:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Carl Sorensen <address@hidden> writes:

> On 11/14/09 1:29 AM, "David Kastrup" <address@hidden> wrote:
>> Ok, I am digging through harp-pedals.scm and looking at
>> define-builtin-markup-command.
>> Now from the definition of define-builtin-markup-command it looks to me
>> like you can specify default properties and those are let to the
>> specified default values (#f if unspecified) or the respective
>> properties from the list.
>> Now the harp-pedal command defines the property signature
>>   ((size 1.0)
>>    (harp-pedal-details)
>>    (thickness 0.5))
> The property signature is a documentation-only convention.  It has no
> functionality except for producing documentation.

Thanks, but wrong.  Please look in the definition of
define-builtin-markup-command.  The property signature symbols are
let-bound to the respective property values (or the default if none are
there) within the body of define-builtin-markup-command.

Here is the respective part from the macro that does it:

              `(define-public (,command-name ,@args)
                 (let ,(filter identity
                               (map (lambda (prop-spec)
                                      (if (pair? prop-spec)
                                          (let ((prop (car prop-spec))
                                                (default-value (if (null? (cdr 
                                                (props (cadr args)))
                                            `(,prop (chain-assoc-get ',prop 
,props ,default-value)))

If indeed no active Lilypond developer _realises_ that this is the case,
then the respective code should just be thrown out instead of wasting
performance with property lookups that are ignored.

I find it unfortunate that the arguments of
define-builtin-markup-command and define-markup-command diverge in this
manner, since converting a markup routine to an internal one _in style_
should just entail adding the documentation, not restructuring the code.

The idea to have properties automatically defaulted and looked up at the
top is nice, however.  But if the lookup results are needed in a
different scope (as is the case with harp pedals) or only conditionally
in some code paths, the scheme gets less workable.

And if nobody realises what the functionality actually does, this does
not help.

David Kastrup

reply via email to

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