gnu-music-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

message passing...


From: Han-Wen Nienhuys
Subject: message passing...
Date: Fri, 22 Sep 2000 10:06:37 +0200 (CEST)

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?

> 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?)

> \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?

> \score{
>       \paper{
>               \sendmsg{\StaffContext \remove "Time_signature_engraver}
>       }
> }     
> 
> This contains all the information in the original example, side
> effects are controlled, the user thinks in terms of creating new
> objects, modifying them, or modifying existing objects through a well
> defined interface. Under the present system, if something like
> CueVoice is placed into a header file, and then advertised for use,
> unpleasant surprises are certain to occur if someone has a
> modification of StaffContext later in the file. 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.

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>

> 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.

-- 

Han-Wen Nienhuys   |   address@hidden    | http://www.cs.uu.nl/~hanwen/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]