This page is part of the web mail archives of SRFI 26 from before July 7th, 2015. The new archives for SRFI 26 contain all messages, not just those from before July 7th, 2015.
Michael Sperber [Mr. Preprocessor] writes: > >>>>> "WP" == Walter C Pelissero <walter@xxxxxxxxxxxxx> writes: > > WP> Why an incomplete solution is bad? Simply because as much as you > WP> needed (not very much) a solution for the cases this SRFI addresses > WP> you will, sooner or later feel the need for a solution for the > WP> remaining cases. > > So far I haven't. Given the number of lines I've written and the > number of instances where I've wished for something like CURRY, I > doubt that I ever will. I'm sorry but your figures are still irrelevant. The reason why you can't see the point for a more complete solution than this SRFI is that you limited your view to map and for-each. It's obvious that the ability to swap, duplicate or omit a parameter is not an issue for map and for-each, as _you_ specify the argument list. Are map and for-each the only higher-order functions in your code? If your only problem was to slim-down the map and for-each pattern you might as well written some macros around them without bothering with curry, partial evaluation and such. > I agree that CURRY may be *too* general for most practical uses. > The FN macro you provide, on the other hand, requires significant > implementation machinery over CURRY, and arguably is not as easy to > read. On the other hand, the implementation effort involved in > CURRY is --- in my eyes --- still sufficiently small to warrant the > added generality over the F you presented. The complexity thing is rather unsubstantial as the implementation is indeed trivial and as the value of an abstraction is not in its implementation simplicity, but mostly in the simplification it brings to your code. Yet again, I'm not trying to put forward fn as a replacemente for curry. -- walter pelissero http://www.pelissero.org