On Dec 14, 2013, at 12:00 PM, [email protected] 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
