lilypond-devel
[Top][All Lists]
Advanced

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

A few questions regarding markup


From: David Kastrup
Subject: A few questions regarding markup
Date: Sat, 14 Nov 2009 09:29:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

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))

So far, so fine.  It
then calls make-harp-pedal without passing it those let-bound
variables.  As far as I understand Scheme and its closures, this means
that the defaults specified in this manner are ignored.

make-harp-pedal then starts off with

  (let* ((size (chain-assoc-get 'size props 1.2))
        (details (chain-assoc-get 'harp-pedal-details props '()))

Which looks rather like defaulting to a size of 1.2 if none is
specified, conflicting with the documented default value which is
ignored.

That does not really make much sense.

Is my understanding of the code correct so far?

Now there are several possible remedies I can see.

a) don't use chain-assoc-get in this manner, consistently.  Instead pass
everything from the defined markup function into the helper function
explicitly, as extra arguments.  This would involve fixing the current
definition of harp-pedal and its helpers.  The ultimate solution would
be to never even pass props on, but rather only the defaults picked from
it.  Advantage would be that the documentation would be consistent with
declaring which values are possibly used with which defaults, no white
lies permitted.  Disadvantage is maintenance of the passed argument list
with possibly many values, from all defined markup commands.

b) fixup props also by let-binding, binding the default values to the
end of the property chain.  This requires a copy of the property chain.
Consing overhead.  Disadvantage is that access to the fixed property
chain can access values not declared in the documentation.

c) fixup props by let-binding, binding any undefined default values to
the start of the property chain.  No copying overhead, but lookup
overhead.  But could probably be combined with the lookup that happens
anyway for let-binding the default values.

d) make the duplicate default values consistent but don't touch the
code.

e) redesign everything

Option d) appears simplest but most error-prone.

Other than that, I think one should go for a).  Likely cleanest.
Disadvantage is that that makes the code diverge from what one would use
for define-markup-command rather than define-builtin-markup-command.

So one should probably add this default-let behavior to the
define-markup-command macro as well.

Do I overlook something important?

-- 
David Kastrup




reply via email to

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