Context_def -> Context progress

[Erik Sandberg]

On Monday 16 October 2006 23:41, Erik Sandberg wrote:
>
> I have a clearer plan for context defs now: We could represent each context
> def as a Context object, which is used as a template for new contexts.
> E.g., the Voice context_def in engraver-init.ly defines a Context object
> with various engravers and properties in it, and when a new Voice is
> created during interpretation, the template voice is clone()d, and linked
> into the context tree.
>
> This requires a good mechanism for context cloning, which preserves
> translators and context properties. This can be achieved using signals,
> much like the AnnounceNewContext mechanism: Context::clone sends a
> CloneContext event, containing a reference to the newly created context.
> When the translator group hears this event, it clones itself and all
> translators, and connects the clones to the new context (this should be
> sufficient to preserve \consists etc.)
>
> This suggestion does still not make clear how to separate
> translator-specific and context-hierarchy-specific information, but we can
> wait with that separation.
>
> Plan:
> - create a Context::clone, which copies nothing.
> - replace lots of references to Context_def with references to a Context
> which references that context_def.
> - add hooks for translator groups (CloneContext event)
> - incrementally stuff out from context def to context and translator group.
> This includes the commands \consists, \remove, \type,\override, \revert,
> \set and \tempo.

Hi,

I have started working on this, a first refactoring is attached. Many 
references to Context_defs have been replaced with references to a Context 
('template context'), and a new Context::instantiate intends to replace 
Context_def::instantiate in the future.

In addition, I changed the protection of context keys so that unprotect and 
creation happens in the same scope. I also changed some constness, to make 
key unprotection const correct.

The work so far only aims on softcoding context-def definitions 
as music expressions, this is not much related to the original problem of 
separating definitions for contexts and translators. I think the latter can 
be done by creating a context-init.ly, which is a translator-neutral common 
base for {engraver,performer}-init.ly and recording-group-emulate.

My idea is that in
\context { \name "Staff" \consists "Foo_engraver" }
the { ... } is a music expression, and \context is a music function, which:
- creates a special context (a 'template context').
- interprets the expression in the template context. During interpretation, 
the template context is treated as a bottom context with no parents or 
children. No listeners will listen to the context, so any non-\applycontext 
music will have no effect, and will probably give warnings.
- return the template context in its final state.


However, while I wrote this, I have been thinking about an alternative 
solution to the same problem, which is cleaner but less efficient: We could 
let context_def simply be a music expression which is inserted before any 
music in the context. So e.g., \context Staff { c4 } would be equivalent to 
creating a new, blank context and interpret { \Staff c4 } in it.

A problem with this approach is that all property, \override and \consists 
operations have to be re-iterated for each newly created context. This 
doesn't need to take much time (quote-like constructs could be used to cache 
the result of music interpretation), but the problem is that the size of 
music streams would explode: Each Staff creation will send a bunch of 
\consists and \set events to the new context, this may result in grotesque 
music stream sizes if << \\ >> is used a lot. This weakness is at the same 
time a strength, because music streams will be completely self-contained in a 
natural way (currently they rely on knowledge about context_defs). The 
concept of context_defs will be kept entirely on the iterator side, which is 
very nice IMO. OTOH, it may be more difficult for non-lilypond applications to 
distinguish between e.g. staff contexts and voice contexts, since that info 
is not part of the CreateContext stream event.

Any comments / ideas / opinions?

-- 
Erik

es-061101.diff
Description: Text Data