Re: Nested context properties -- an implementation sketch

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Sun, Aug 14, 2011 at 05:31:11PM +0200, David Kastrup wrote:
>> Werner LEMBERG <address@hidden> writes:
>> 
>> > Unfortunately, I have nothing useful to say.
>> 
>> Well, there is the code (obviously bound to be streamlined before
>> implementation) and there are the proposed semantics.  At least for the
>> latter, I would want to get some sort of feedback.
>
> I agree.  :(
>
>> The semantics can be summarized as follows:
>
> Those look fine to me.

There are likely two contentious changes.  The first is related to
nested properties: namely that the pairing of override/revert of a
property x should be independent from override/revert of a nested
property x.y.  However, if overrides and reverts of x and x.y are not
acting as if they were issued independently, and if overrides and
reverts of x and x.z are not acting as if issued independently, then it
gets quite hard to let overrides and reverts of x.y and x.z act as if
they were issued independently.  And that would make working with nested
properties less straightforward in my opinion.

The second is that \once\override will not mix with \override\revert.
Currently \once\override ... \override will have the second \override
active just for the current timestep, and revert to the previous value
afterwards.  \override ... \once \override ... \revert \revert will at
first revert both overrides, but reinstate the state after the first
override at the end of the timestep.  If I understand the code
correctly.

I prefer to have behavior corresponding to simple well-defined rules
rather than implementation artifacts.  Even if it means that the
implementation is harder to write.

>> Once I rewrite the property code in C, getting negative feedback about
>> the semantics afterwards will be a major pain.  So I made a toy
>> implementation (it is already suffering from too much premature
>> optimization for a toy, but is still more or less readable) in Scheme.
>
> If you really want to poke the hornet's nest, and if the scheme
> implementation can be used for any arbitrary lilypond file (i.e.
> just by adding an \include "new-overrides.ly" to the top), then we
> could ask on the lilypond-user mailing list.

Since a number of other Context internals in addition to the grob
property list manipulators themselves are written in C++, such a
replacement is unfortunately not feasible to do without recompilation as
far as I can see.

> Since we'll be having a release candidate as soon as Mike fixes
> his python 2.4 problem in output-distance.py, I'd ask you to wait
> until 2.16 is out before pushing this change.  That's the only
> real feedback I can give, sorry.

I'll not likely be that fast, anyway.  On the other hand, once the stuff
works for me, it seems reasonable to get it out for massive testing.  So
it seems a bit awkward that we don't have a release branch separate from
master.

Since the change of semantics would not be limited to nested properties,
it does not make sense to rush this in under the pretense of it being a
mere bug fix, however.  It is more like fixing a design flaw.

-- 
David Kastrup