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? sperber@xxxxxx 26 Feb 2002 14:53 UTC

>>>>> "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.

WP> Why that?  Because the remaining cases are not less likely [...]

They are less likely in *my* code.  I was just providing some
empirical data.

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.

WP> Curry2 is bad because you will have two macros for obviously similar
WP> cases.  L is bad because it will replace curry (this SRFI) in the long
WP> run: why bother with a lesser macro if you are more confortable with
WP> another one?

WP> Common Lisp has some examples of redundancy of this sort.

Sure, but we're not writing a language standard, we're writing a
library proposal.  The problem with Common Lisp is that the
redundancy is not sufficiently modularized.  There's no problem with
redundancy in the SRFI process --- indeed we're expecting and
soliciting a lot more of it.  Will Clinger has some excellent thoughts
on the issue at

http://srfi.schemers.org/srfi-6/mail-archive/msg00002.html

--
Cheers =8-} M.
Friede, Völkerverständigung und überhaupt blabla