lilypond-devel
[Top][All Lists]
Advanced

[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


reply via email to

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