Re: Anybody invested in ly:make-simple-closure?

[David Kastrup]

Mike Solomon <address@hidden> writes:

>> On 24 Sep 2015, at 13:18, David Kastrup <address@hidden> wrote:
>> 
>> Han-Wen Nienhuys <address@hidden> writes:
>> 
>>> IIRC, it was introduced to compose offset callbacks,
>> 
>> Oh, it's still being used for that as far as I can tell.  Just not from
>> Scheme.
>
> I think before lambdas were widely used they made lots of sense.  I
> used to like these because they were easier (for me) to debug than
> lambda functions, where all heck could break loose on the inside.  But
> it is true that they are not used much anymore.  I’d vote for
> depreciating them.
>
> The pure/unpure stuff has definitely needed reorganising for almost 9
> years now - there must be a better way to do it.

Well, the basic target for me is that whatever needs a start/end column
for its decision-making has to ask for it.  And when it asks for it,
that request is put on record and any resulting value is only considered
cached for the respectively recorded preconditions.  If some property
callback does not ask for start/end column either directly or by reading
other grob properties depending on such values, the value is cached as
being final.

Basically the pure/unpure business should be determined dynamically.
Then stuff like an accidental for a tied note at the start of a bar can
make the unpure/pure split only when all the preconditions are met and
just behave boringly otherwise, having its dimensions and stencil just
generated once and then cached.  And even when it makes the split, it
will only generate one set of values for each start column but not
differentiate according to end column.  Half-pure, so to say.

The end goal has to be that the depency tracking is not the job of the
programmer of the basic typesetting code or extending LilyPond with new
graphical features becomes too much of a specialist job.  Amateur
typesetters need to be able to do that without being experienced core
programmers, or we have a bottleneck for typesetting knowledge passing
into LilyPond.

-- 
David Kastrup