Re: [frogs] Stepping into the code for nested properties

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 5/12/10 11:13 AM, "Rodolfo Zitellini" <xhero.gm@xxxxxxxxx> wrote:

> I did some digging with the debugger (and pretty-print :)
> It seems that when overriding nested props are treated exactly like
> non-nested ones, as Neil suggested. When you do an \override, in the
> CAR of the current property list is placed a new list with the
> elements of the same list:
> (<many elements>) -> ((<many elements>) <many elements>)

Remember that these are alists, not lists.  Pretty-print sometimes chooses
to show them in a way that it's not ovbious they are alists.

So, in alist form, I think you get two prepends:  one for left, which gives
you:

(bound-details . ((left . ((Y . new-y-value)
                           (Y . old-y-value)
                           (other-left-prop . other-value)))
                  (other-detail . other-detail-alist)))

and then a second for bound-details, which gives you

(bound-details . ((left . ((Y . new-y-value)
                           (Y . old-y-value)
                           (other-left-prop . other-value)))
                  (other-detail . other-detail-alist))
                  (left . ((Y . old-y-value)
                           (other-left-prop . other-value)))
                  (other-detail . other-detail-alist)))

So you've prepended the new value for Y onto the left alist; then you
prepend the new value of left onto the bound-details alist.

At least, that's my understanding of the way it works. (And in writing this
down, I think I've discovered what I needed to know about my new autobeaming
data structure -- thanks for the insight!)

> 
> The new value is then prepended, but the old one is maintained in the CAR:
> ((<the_element> <other elements>) <the_element> <other elements>) ->
> (<the_element_new> <the_element> <other elements>) <the_element>
> <other elements>)
> 
> So we end up with a "backup" copy of the list and the current list in
> the CAR, with two copies of the modified prop: old and new values.
> Nested properties are treated similary. If you do an override, say in
> (bound-details left <an_item>) only the sublist of the nested prop is
> duplicated and not the whole prop:
> 
> (bound-details (left <my_item> <other_items>)) ->
> (bound-details
>            (left <my_item_new> <my_item> <other_items>)
>            (left <my_item> <other_items>))
> 
> I hope I got this correctly! :)
> 
> Now, what seems to trigger the problem is that in the debugger I see a
> call to execute_revert_property() before every
> execute_override_property(). So the code:
> 
> \override TrillSpanner #'(bound-details left Y) = #'99
> 
> seems to generate a revert on #'(bound-details left Y) before setting
> the property.
> If this is the first override in that context
> execute_revert_property() just returns. BUT if an override was already
> done the CAR of it's properties contains the current used properties.
> nested_property_revert_alist() will then find the property you are
> overriding and it pops it out of the list. After the override you end
> up with something like this:
> 
> (bound-details
>            (left <my_item_new> <other_items>)
>            (left <my_item> <other_items>))
> 
> note that in the first instance of (left) the old value of <my_item>
> is missing, since it was popped by the revert.
> 
> When you explicitally do a \reverts on this property,
> nested_property_revert_alist() seems to care only of the first (left)
> that it encounters, and pops (correctly) <my_item_new>, leaving the
> nested property without a copy of <my_item>.
> This extends easily to the \revert-one-some-prop breaking after an
> \override-another: nested_property_revert_alist() always pops out the
> list the \reverted item, even if it is the only copy present. It seems
> then that other parts of the program just access the first instance of
> the nested prop they encounter, thus not finding it's subproperty,
> this even if subsequently in the list other copies of the nested
> property (with all elements) are present.
> Can't the default value just be copied from the "backup" part of the
> context's property alist, which is always present?

We shouldn't need to copy from the "backup" part.  We should just eliminate
the whole prepend, imo.  That is, we should revert Y  in the left sublist;
then we should revert the left sublist in bound-details.  That should get us
back to the original condition.

But that logic only works when we revert exactly what we overrode
previously.  If we had done an override on (bound-details left Y) and then
did a revert on (bound-details left foo), we'd lose the override on
bound-details left Y as well with the logic I described above.

That's the logic that has been giving me grief in my autobeaming code.

I hope this was helpful, and that what I said was reasonably accurate.

Thanks,

Carl


---
----
Join the Frogs!