Re: Adds some info about pure properties to the CG. (issue 5364048)

[address@hidden]

On Nov 16, 2011, at 2:19 AM, address@hidden wrote:

> 
> http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi
> File Documentation/contributor/programming-work.itexi (right):
> 
> http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1836
> Documentation/contributor/programming-work.itexi:1836: LilyPond).
> Purity is not only about returning predictable values. It's also about
> not having any side effects.
> 
> http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1844
> Documentation/contributor/programming-work.itexi:1844: meaningful notion
> of estimation.  For example, even if a color was
> I would argue that the reason for lacking pure estimation for color is
> that we haven't found a use for it rather than because of any intrinsic
> properties of color.
> 

True.  Text changed.

> http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1888
> Documentation/contributor/programming-work.itexi:1888: taken from the
> stencil.
> Actually, the requirement is different: the print function must not have
> any side effects. The print function doesn't necessarily have to deliver
> the same result at all stages in the compilation process. For example,
> if some side-effect modifies the font size of a grob mid-compilation,
> then note-head::print will deliver a stencil of a different height.
> 

Then I misunderstood what pure means in lily-speak.  I thought that a pure 
function had the dual condition that it (a) always return the same value for a 
given begin and end range; and (b) not trigger any side effects.

Are there any cases where pure functions do deliver different results for the 
same range before line breaking?  And, if not, would this even be 
conceivable/desirable?

Lastly, the idea of "not trigger any side effects" is something that I grok 
more than I understand.  Is there any way to communicate what it means to "not 
trigger side effects" (i.e. never calls (or results in the calling of) 
set_property on another property with a pure estimation, etc.) to someone who 
doesn't know what these side effects are?

> http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1901
> Documentation/contributor/programming-work.itexi:1901: @end itemize
> I think the preceding four lists can be understood as follows: if you
> have a Grob and you want to estimate its height, what can you do?
> 
> - If its Y-extent callback is pure, just use it (pure-functions)
> - If its Y-extent callback is ly:grob::stencil-height and the stencil
> callback is pure, then it's safe to use ly:grob::stencil-height
> (pure-print-functions)
> - If we have a manually-created pure version of its Y-extent callback,
> use that (pure-conversions-alist and pure-print-to-height-conversions)

I agree, but is this not clear from the document as it stands and, if not, how 
should it be modified so that it is clear?  My biggest worry is clarity, as I 
often don't understand what I'm saying, so I'd imagine that others will have an 
even harder time.

Thanks for your feedback!

Cheers,
MS