Re: Project - Eliminating grob parents and outside-staff-priority

[address@hidden]

On 26 sept. 2012, at 21:51, Han-Wen Nienhuys <address@hidden> wrote:

> On Wed, Sep 26, 2012 at 9:17 PM, address@hidden
> <address@hidden> wrote:
> 
>> Another way to think of this is that, in general, we'd try to eliminate
>> grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do
>> traffic-coppery.  Or, inversely, we'd say that positioning only happens via
>> traffic-cop grobs and no grob has the right to position itself.  But it
>> seems like we need to pick one.
> 
> The reason for trafic-coppery is that for many positioning schemes,
> there is no inherent order that can determine how two objects of the
> same type (and hence, with the same set of callbacks) should be
> typeset.
> 
> A typical example of this is NoteCollision of N NoteColumns. The
> NoteColumns have to all move in a coordinated way, and the easiest way
> is to have a function (with local variables) that determines what has
> to happen. You might get around it, by having a bunch of properties
> instead, but you'd still have to store those somewhere, ie in the
> NoteCollision grob.

Not necessarily, it'd just make computation time longer.  If each note column 
had other concurrent note columns in its side-position-elements grob-array and 
we kept the same function from note-column.cc but rewrote it such that instead 
of translating axes by values it returned the offset value for a given note 
column, the function would be called N times for N note columns.  It's a 
tradeoff between efficiency and consistency - I'm not sure which one is better, 
but I'm sure it's possible to eliminate the NoteCollision grob at the cost of 
redundancy.

> 
>> Agreed, but this is just one instance of translate_axis, which is just one
>> example of a side-effect in lilypond. Is your eventual goal to remove them
>> all?
>> 
>> 
>> Yes - that'd be great.  That'll make explicit dependencies a lot easier to
>> handle - everything can be calculated in terms of callbacks.
> 
> I'm all for removing side effects, but you can pursue that separately
> without trying to rewrite the backend.

My goal is not to rewrite the backend.  My goal is to come up with a 
generalized way to do multiple passes at many places in the compilation 
process, and the best way seems to be deleting certain cached properties.  I'm 
all for other ideas, though.

> 
> 
>> To keep the main thing the main thing, the goal is to be able to wipe
>> certain caches, restore the original callbacks, and know that all grobs
>> properties that depended on the restored property will also be recalculated.
>> My idea is an idea for simplifying LilyPond so that this work is easier, but
>> there is no point in doing that if it won't help reach that goal.  I'm open
>> to any and all suggestions.
> 
> Have you thought this through?
> 
> In order to do cache invalidation, you will have to construct the
> reverse graph. If A.x depends on B.y, now A points to B. For proper
> cache invalidation, if B.y changes, then A.x becomes invalid. This
> means that A has to store a back-reference to B. Hence all pointers
> have to be stored both ways (including inverting 1-N relations into
> N-1 relations), and the both-way links have to be rewritten correctly
> during line breaking.

I'm sure this is doable - it'd just be a royal pain.  It'd meant that 
get_property would have to take the "me" grob as an argument and somehow make 
the grobs aware of each other.

Cheers,
MS