Re: message passing...

[Mats Bengtsson]

> 
...
> Sure. First of all, what I perceive as multiple assignment operators
> need to go, even if message passing isn't implemented. Recently, I
> tried to write a context:
> 
> \paper {
>        \translator {
>                  \VoiceContext
>                  \name CueVoice
>                  ...
>        }
> }
> 
> \translator{\StaffContext \accepts CueVoice}
> 
> But this caused problems, since it was apparently overwriting the
> existing StaffContext. 

I'd rather say the problem in your example was that you did NOT 
overwrite the existing StaffContext. When you later in the file did
\translator{\StaffContext \remove ...}, your previous declaration
of the translator for contexts of type "Staff", was overwritten.

I look at it this way (which might give some ideas for 
a possible renaming and change of syntax):

The idenitifiers (variables/containers) \StaffContext, \VoiceContext
a.s.o can be seen as templates for the declaration of translators
("context handlers") for contexts of type Staff and Voice, 
respectively. If you want to modify the behaviour of the
translator for \context Staff in a single score, it's 
convenient to start from the template so you don't have
to declare the full \translator from scratch. If you want
to reuse the modification, you could either make a change
in the template or define a new template (based on an
existing one). 

The multiple use of \translator both when defining an 
identifier (variable) with the template and in the declaration 
is consistent with the use of identifiers throughout the 
Mudela syntax. You could define an identifier for a piece
of music using
violinpart=\music{...}
but Lilypond will not notice that piece of music until you
actually refer to the identifier in a \score{}.
Likewise, you could set the identifier \StaffContext but
Lilypond will not notice it until you refer to the 
variable in a \paper section.

Is it possible to just say
\paper{
  \StaffContext
}

instead of

\paper{
  \translator{\StaffContext}
}

Otherwise this is inconsistent with e.g. 
\score{
  \violinpart
}


> To save the existing StaffContext, and still
> use my own defined context, I ended up having to do (courtesy of one
> of the developers, I couldn't have figured this out by myself, in my
> present state of knowledge)
> 
> \paper {
>        CueVoiceContext = \translator {
>                      \VoiceContext
>                      \name CueVoice;
>        };
>        \translator{\CueVoiceContext}
> StaffContext=\translator{\StaffContext \accepts CueVoice};
> }

I would add a \translator{\StaffContext} here for the cases
where you don't refer to the identifier in the paper section
of your specific score.
> 
> \score{
>       \paper {
>              StaffContext = \translator {
>                           \StaffContext
>                           \remove "Time_signature_engraver";
>               };
>               \translator{\StaffContext}
>       }
> }

If this change is only for this specific score, there's no
need to modify the template, just say

\score{
  \paper {
    \translator{
      \StaffContext
      \remove "Time_signature_engraver";
    }
  }
}


The problems I see with the current solution is

- The keyword \name used in the declaration of a \translator
  to specify the type of \context to be handled by the 
  translator. What could cause confusion is that each 
  \context instance has a name. Comparing to C++, the
  \name would rather correspond to the name of the class
  (such as "Staff") whereas '\context Staff = soprano'
  specifies the name of the instance (corresponding to 
  the variable name in C++).
  OK, this is a minor problem.

- It's clumsy to change the default context hierarchy.
  In the example above, you had to modify the translator
  for Staff contexts in order to make it accept the new
  context type CueVoice as ancestor. In the TODO file, 
  I've seen a note about changing from \accepts to
  \acceptedby, which would then be declared in the 
  CueVoice translator, I presume. The problem is that
  you then would have to change all translators for 
  context types that could be included in an CueVoice,
  so it would just move the problem.

- Sometimes you may want two different versions of 
  e.g. a Staff context. As a (silly) example, you'd want
  two staffs with repeat bars and two without, i.e. 
  the Repeat_engraver should be removed for some 
  instances. To do that today, you have to define
  a new translator and add it to the hierarchy.


Regarding the ideas about message passing, I hope
you remember that the translators are some kind of
meta objects that handle the context instances.
There's only a single instance of each translator
for each score and the translator doesn't change
during the processing of the score (maybe this
isn't true any more with the new property push
mechanism in 1.3.85). "Message passing" sounds as
if you want some kind of dynamics.

      /Mats