lilypond-devel
[Top][All Lists]
Advanced

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

Re: Page breaking fails for multiline embedded scorelocalhost/


From: Carl Sorensen
Subject: Re: Page breaking fails for multiline embedded scorelocalhost/
Date: Mon, 3 May 2010 09:19:38 -0600

Boris wrote:

> Right now, we start from the list of markups, and for-each markup,
> apply the markup function and destructively append! the resulting
> stencil to the result list under construction.
>
> The procedural nature of this design, is somewhat limiting in terms of
> expressive power. For what I am trying to do -- building a more
> flexible/general markup formatting facility -- the formatting of a
> markup may sometimes be context-controlled, i.e. formatting of the next
> piece of markup may depend on how the previous markups were formatted. For
> this, the design where the markup's stencil is completely defined
> by the single markup element in the list fed into
> interpret-markup-list, is not sufficient. One way to address it, is
> simply to pass another argument to the markup
> procedure, containing the context where we are along the way. A more
> elegant way is to do it in continuation passing style: the markup
> function, which represents one step in building of the stencils list,
> takes the tail of the markup list (the head is the current markup
> function itself) and the partially-built list of stencils, formats the
> current piece pf markup, tucks it on to to the stencils-list being
> built, and tail-recursively executes the rest of the markup with list
> of stencils grown by the just-now-formatted stencil. This way, each
> step can reason about what has been already built, looking backward
> (although only in terms of stencils), and what is yet to be built,
> looking forward (although only in terms of markups).

I'm not sure what you have in mind here, but I would agree with this being a
more elegant way of doing it.  I always look at ! functions in Scheme as
something that would be best avoided if possible, because there's generally
a more expressive way to do things that avoids the ! function.

Thanks,

Carl





reply via email to

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