Re: is that useful? sebastian.egner@xxxxxx (22 Feb 2002 16:15 UTC)
Re: is that useful? Walter C. Pelissero (25 Feb 2002 12:02 UTC)
Re: is that useful? sperber@xxxxxx (25 Feb 2002 14:33 UTC)
Re: is that useful? Walter C. Pelissero (26 Feb 2002 14:40 UTC)
Re: is that useful? sperber@xxxxxx (26 Feb 2002 14:53 UTC)
Re: is that useful? Dave Mason (26 Feb 2002 15:28 UTC)
Re: is that useful? sperber@xxxxxx (26 Feb 2002 15:39 UTC)
Re: is that useful? Dave Mason (26 Feb 2002 16:45 UTC)
Re: is that useful? Walter C. Pelissero (26 Feb 2002 16:37 UTC)
Re: is that useful? sperber@xxxxxx (26 Feb 2002 16:41 UTC)

Re: is that useful? Walter C. Pelissero 26 Feb 2002 16:37 UTC

Michael Sperber [Mr.  Preprocessor] writes:
 > >>>>> "WP" == Walter C Pelissero <xxxxxx@pelissero.org> 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