Re: Nested context properties -- an implementation sketch

[David Kastrup]

Werner LEMBERG <address@hidden> writes:

>> Well David,
>> 
>> I should not want to let you implement this in the current form
>> without any feedback from the developer list.  [...]
>
> :-)
>
> 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.

The semantics can be summarized as follows:

a) a revert will only cancel the last _matching_ override, and the match
   includes the complete specified property path, _and_ the prospective
   use of \once.  \revert will not cancel \once\override and vice versa.
b) At the end of a timestep, all \once\override are reverted.  All
   non-\once overrides remain in effect and on the stack as if none of
   the \once\override had ever happened.

I have no clear view about \set yet.  It would seem to me that \unset
should be equivalent to \revert, and \set should be equivalent to
\revert+\override.

I am pretty sure that any less strict 1:1 matching of reverts and
overrides will cause surprises to users that are really hard to track
down and explain.

This is a change of existing semantics and will likely require changes
to some Lilypond scores.  I should be quite surprised if such changes
would not make the intent of the writer easier to follow and maintain,
but they would be changes nevertheless.

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.
The version in C will be less readable, but deliver the same results.
The Scheme version was likely overkill to do, but whether or not
somebody actually looks at it, it helped for focussing on the needed
data structures.

So from those not interested in the code (long as it works(TM)), I'd be
at least interested in hearing whether they would be ok with _what_ I
propose it should be doing, never mind _how_ it does it.

-- 
David Kastrup