Re: grob-property: if callback is independent of layout, call just once (issue 42190043)

[dak]

https://codereview.appspot.com/42190043/diff/1/lily/unpure-pure-container.cc
File lily/unpure-pure-container.cc (right):

https://codereview.appspot.com/42190043/diff/1/lily/unpure-pure-container.cc#newcode45
lily/unpure-pure-container.cc:45:
On 2013/12/14 09:47:33, MikeSol wrote:
> Looking good.

> The only thing is - how do we verify that this actually ignores start
and end?

The function does not get passed start and end, so it has little choice
but to ignore them.

> For example, let's say that there is a scheme function with optional
arguments
> for start and end that is used as the pure and unpure function.

You are confused.  If the second container element is _unbound_, which
is what is being checked here, the function in the first container will
_always_ be called without begin and end arguments.

> It'll evaluate
> just fine for unpure cuz begin and end are optional.  But begin and
end may be
> useful when it is pure.  If this is the only function passed to the
constructor,
> it will return true for the function above and yet perhaps be an
operation that
> we don't want to cache.

> Conversely, it is possible to do:

> (ly:make-unpure-pure-container foo foo)

> that should be cached but it would return false for this function.

Well, but in this case the function foo will be called without begin/end
for the pure case and _with_ begin/end for the unpure case.  Different
thing.

> So, my proposal would be:

> 1) if there is a single function, verify that it takes only one
> argument

Doesn't matter.  It will always get only one argument.

> 2) if there are two functions, verify that the second takes only one
argument

> All of this is of course predicated, like I said above, on being able
to check
> the number of arguments a scheme function takes, which may or may not
be
> possible...

I would try to avoid this: the fine details here differ significantly
between GUILEv1 and GUILEv2, and it does not appear that you can rely on
this information being available at all or at least with the same
mechanism for functions defined in C in GUILEv2.  So there is a large
danger that we would be painting us into a corner here.

Once can, of course, call the function with three arguments and trap an
error (if one occurs).  But error trapping is not likely efficient.

> Or create a new type predicate for a new class of functions instead of
doing a
> boolean test (which seems like a pain...so I like the boolean approach
above).

https://codereview.appspot.com/42190043/