[Top][All Lists]

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

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

From: mike
Subject: Re: Adds some info about pure properties to the CG. (issue 5364048)
Date: Sun, 20 Nov 2011 23:44:32 -0800
User-agent: Roundcube Webmail/0.5.2

On Sun, 20 Nov 2011 15:19:03 -0800, Joe Neeman wrote:
Bah, I just wrote out a nice reply on the codereview site and it got

On Fri, Nov 18, 2011 at 12:03 AM, address@hidden [3]  wrote:

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

> 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
> the same result at all stages in the compilation process. For
> if some side-effect modifies the font size of a grob
> then note-head::print will deliver a stencil of a different

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?

I can't think of a situation where it's desirable, but it's certainly
conceivable. If I write lily code that, for whatever reason, has a
callback which changes Slur 'height-limit then Slur::calc_pure_height
will also change. We tend to avoid the use of set_property after the
translation step, so this sort of thing is unlikely; the point is,
though, that the pure callback itself doesn't worry about such things.
It just tries to avoid side-effects, and if something else with side
effects messes with grob properties then the pure callback can change
its value accordingly.

Lastly, the idea of "not trigger any side effects" is something
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?

The main side effects in lilypond are set_property, set_object and
suicide. These are easy to avoid; the trickier part is that any call
to get_property could conceivably trigger a callback that will itself
have side effects.

OK, will write some more prose.

 >  xi#newcode1901
> Documentation/contributor/programming-work.itexi:1901: @end
> 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
> - If its Y-extent callback is pure, just use it (pure-functions)
> - If its Y-extent callback is ly:grob::stencil-height and the
> 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
> use that (pure-conversions-alist and

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.

I'm not sure which version is better for new readers. It's just
that you're explaining these lists in terms of what they contain,
while I find it easier to think of them in terms of their role in
h also helps to explain why we would bother to have these lists in
the first place).

I'm going to leave it this way if that's all right with you for the purely selfish reason that I grasp these lists better in terms of what they contain. This then can be edited later by anyone who wants to improve the ease of reading of the document (which I'm sure can benefit from other changes as well - I hope that someone who has no clue about pure properties actually takes the time to read this thing so that I can learn what is graspable on a first read and what is not).

The AMSTERDAM AIRPORT is currently blocking me from uploading the patch set ( something...), but I'll get it up on Rietveld once I'm back in a civilized country.


reply via email to

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