On 20 févr. 2013, at 14:06, David Kastrup <d...@gnu.org> wrote:
>
> (define-public (constant-grob-callback callback)
> "Wraps a grob @var{callback} into an unpure-pure-container
> delivering the same results for pure and unpure calculations. This
> means that the result of the callback must not depend on the line
> spacing."
> (ly:make-unpure-pure-container
> callback
> (lambda (grob start end) (callback grob))))
>
> Then look-and-behold, we can define
>
> (define-public grob::constant-height-from-stencil
> (constant-grob-callback grob::stencil-height))
>
> Now look-and-behold, we can get along without a separate comment for
> each such definition since constant-grob-callback already tells us all
> that we need to know (by virtue of its comment).
>
This is an excellent idea - hadn't crossed my mind. Please propose a patch if
you have time.
> Is that where we can stop? Actually, no. If we take a look at
> ly:make-unpure-pure-container, we see
>
> LY_DEFINE (ly_make_unpure_pure_container, "ly:make-unpure-pure-container",
> 1, 1, 0, (SCM unpure, SCM pure),
> "Make an unpure-pure container. @var{unpure} should be an unpure"
> " expression, and @var{pure} should be a pure expression. If
> @var{pure}"
> " is ommitted, the value of @var{unpure} will be used twice.")
>
> Of course, "an unpure expression" and "a pure expression" is pure
> gobbledygook not even having any tangible meaning, since an expression
> is not pure or unpure but rather gets used in a particular context.
>
> Anyway, we already _have_ an API for using the same value in an
> unpure-pure-container twice. Why don't we _use_ it? The superficial
> answer is that pure and unpure callbacks are called in a different
> manner: the unpure callback gets more arguments (or was that the other
> way round? Since the unpure/pure naming is not really related to what
> this does, I can't remember). So in the case of a callback, we can't
> just reuse the callback like we do with fixed values.
>
> Right? Wrong. All we need to do is changing the line
>
> if (pure == SCM_UNDEFINED)
> pure = unpure;
>
> in the definition of ly_make_unpure_pure_container into
>
> if (pure == SCM_UNDEFINED && !scm_is_procedure (unpure))
> pure = unpure;
>
> and then let ly_unpure_pure_container_unpure_part and/or
> ly_unpure_pure_container_pure_part deal with the situation of having
> only one procedure with a single argument stored by concocting a
> three-argument procedure on-the-fly (or change all callers of the
> callback procedure to deal with the one-argument situation for half-full
> containers. That makes the change less encapsulated by making external
> stuff responsible for dealing with half-full containers, but may be
> conceptually simpler).
>
> And lo-and-behold, all we need to write as a callback _directly_ is
>
> (ly:make-unpure-pure-container ly:grob::stencil-height)
>
> and that's it. Now apart from the drawback that either your
> ly:grob::all-heights-from-stencil or the purported
> constant-grob-callback functions are much better documented than
> ly:make-unpure-pure-container, this is quite more readable and obvious
> because it works the same way with callbacks as with fixed values:
> specify only the pure and the unpure will follow suit.
>
Also a great idea.
> We have the advantage that we don't have to look for the best name for
> an additional function because the existing functions can perfectly well
> be made to do the job.
>
> Yes, I should have thought of that previously, but it is really
> exhausting to do this kind of review.
>
> And frankly, I still don't understand why this is not equivalent to
> ly:grob::stencil-height anyway. But at least this is not opening yet
> another can of worms but just making do with the already open ones.
I'm proposing another patch set in a day or so that eliminates the rest of the
lists in define-grobs.scm and does everything via unpure-pure-containers.
After that I'll have a better idea if this is feasible.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
