Re: message passing...

[Scott Ballantyne]

Han-Wen Nienhuys <address@hidden> writes:
> address@hidden writes:
> 
> > (I would also
> > suggest that not overloading \translator would improve user
> > comprehension.)
> 
> do you have suggestions for better naming? Would it be better to
> overload \context, or should I add \contextdefinition?
> 

Is it really necessary at all to call \translator in the definition
phase?

contextName = { commands }

\translator{\contextName}


> > Then another mechanism, such as message passing, could
> > be used to modify the context:
> > 
> >     newcontext = \translator {...}
> > 
> > would create a new context.
> > 
> >       \sendmsg{\newcontext, message}
> > 
> > would modify it. With this model, the original CueVoice definition
> > would be something like:
> 
> There are 2 separate issues: we have to have multiple translator
> definitions for the same Staff context (for specifying eg different
> implementations of staff), which is why we have
> 
>   StaffContext = \translator{ ..}
>   PartStaffContext = \translator { .. \StaffContext .. [modifications] }
> 
> and there has to be a mechanism for selecting which implementation of
> Staff you need for a specific paper block, which is what unadorned
> 
>   \translator { \StaffContext .. }
> 
> is for. This is really a different type of assignment, if you want,
> think of
> 
>       Staff := \translator { \StaffContext } 
> 
> instead
> 
> (Should we change this syntax too, and if yes, to what?)
> 

If I understand you correctly, you have different translators, which
become 'active' when associated with a specific paper block. If this
is correct, then I think I would repeat my suggestion above to
eliminate the call to \translator in the definition phase, and simply
define these as as series of commands. Then you can call \translator
within a specific paper block to select the one you wish to
use. \translator{\StaffContext} or \translator{\PartStaffContext}. If
that can't be done, then use, something like definetranslator or
createtranslator would be a good idea.

> > \paper {
> >        CueVoice = \translator{\VoiceContext \name CueVoice }
> >        add_translator_to_system_list(\CueVoice} % eliminate
> >        % overloading of \translator, probably would be better to
> >        % eliminate this step altogether
> >        % and let \accept take care of it, if possible.
> 
> How would we get the toplevel context into the system?
> 

By defining CueVoice outside of any block context.

> > It seems to me that
> > using the concept of modifying existing objects is not only less
> > likely to surprise, it's simpler to use, and easier to understand.
> 
> It has some other unpleasant effects, though:
> 
> 
>    \score { ..
>       \paper { }
>    }
> 
>    \score {
>       \paper { \sendmesg { \StaffContext \remove "timesigs"; }
>    }
> 
> 
> Would the 1st score be typeset with or without timesignatures?
> The solution suggested by the idea that there is a single unique
> StaffContext object would be to change the 1st score as well, and I
> object to that.
> 

I think there's a misunderstanding here (perhaps mine). In the scheme
I'm suggesting, The first score would be typeset by the default
StaffContext, the second score would be set by the modifed
StaffContext. i.e., without time signatures.


> Remember that processing is done after everything is parsed.
> We could change that as well? Seems like an interesting idea. You
> would get
> 
>       \score { .. }
> 
>       <crunch crunch, spits out .tex file>
> 
>       \score { .. }
> 
>       <crunch crunch, spits out another .tex file>
> 

That's a possibility. Another idea is to view lilypond as more of an
interpreter, parsing would generate 'code' for lilypond commands, such
as modifying (or completely replacing) the currently active translator
by another.


> > Note that a user could still completely replace any existing context, by
> > using '=:'
> 
> I'll try to think this over. I'll probably not use your ideas
> directly, but I'll see what I can do.
> 

Without a doubt these are just a faint starting point, and possibly a
false start, for all I know. I would be very disappointed if you just
took these in their present half-baked form.

Thanks for listening.

sdb
-- 
address@hidden