Re: pure/impure?!?!

[Keith OHara]

On Sun, 24 May 2015 01:55:30 -0700, David Kastrup <address@hidden> wrote:

> Anyway: how do impure functions reference (and trigger?) line breaks?

Non-'pure' functions reference line-breaks very indirectly.  Spanners are 
broken into two or more grobs at line-breaking, so their functions work on the 
split Grobs that have a line-break column as a bound.

I would have to trace to find the path whereby functions trigger line-breaking. 
 I think the path is when the Y-extent of a Grob depends on the Y-extent of a 
VerticalAxisGroup.   The pure version of the VerticalAxisGroup.Y-extent uses 
functions like rest_of_line_pure_height(,start,end) while the non-pure version 
ends up calling generic_group_extent(), which I suspect eventually calls the 
line-breaker.

The facility for any 'pure' estimate of a property to depend on the start/end 
columns seems to have started with the *_of_line_pure_height() of 
VerticalAxisGroups.  I cannot think of any other object for which they are 
used.   The 'start'/'end' parameters are passed down the call stack, so if a 
'pure' property depends ultimately on the Y-extent of a VerticalAxisGroup, it 
would need a sensible start/end pair; I do not know of a case where the 'pure' 
call-chains for properties of Items (as opposed to Spanners) ask for 
VerticalAxisGroup dimensions.

Conceptually, the height of the arc of a slur could be estimated for a 
potential line-breaking, but that has not been implemented.  If in the future 
we implement that, it seems that the control logic that is evaluating potential 
line-breaks would need to provide start/end information, or better the 
horizontal positions of the slur bounds, to the height-estimator for the Slur; 
I cannot imagine a way for Slur to seek out the potential line-breaks.

But I think we can remove the 'start'/'end' parameters from 'pure' functions 
for Items.  Items have a 'pure' version of their functions as a way to promise 
that these functions *not* depend on line-breaking.