[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: grob-property: if callback is independent of layout, call just once
From: |
Mike Solomon |
Subject: |
Re: grob-property: if callback is independent of layout, call just once (issue 42190043) |
Date: |
Sat, 14 Dec 2013 12:09:13 +0200 |
On Dec 14, 2013, at 12:00 PM, address@hidden wrote:
>
> 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.
Ah, ok, didn’t know that.
>
>> 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.
Ok.
>
>> 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.
>
Sounds like more trouble than it’s worth.
LGTM then.
Cheers,
MS