Re: is that useful?

[Dave Mason <dmason@xxxxxxxxxxxxxxx>]

>>>>> On Tue, 26 Feb 2002 16:39:48 +0100, sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx (Michael Sperber [Mr.  Preprocessor]) said:


>>>>> "Dave" == Dave Mason <dmason@xxxxxxxxxxxxxxx> writes:
> Dave> On the other hand, if it was a more general SRFI that solved
> Dave> most of the problems, I'd be more likely to use it.

> So we're trying to figure out if the SRFI is general enough.  Walter
> says it isn't.  I say it is.  It solves most of my problems.  Is it
> general enough for you?

I think my point was that I'd like to see such SRFIs be as general as
possible.  If someone has a more general proposal that also solves the
original problem, then we should use it.  Otherwise, if we're lucky,
the more general solution will be proposed for its own SRFI, and then
people will just have to figure out which of the SRFIs meet their
requirements.  My ultimate concern is that the extra cognitive load of
that will reduce the usefulness and hence use of SRFIs and hurt the
process overall.

If we're unlucky, the person with the better solution doesn't bother
to submit a SRFI, and neither does anyone else, and the more general
solution gets lost.  (Not completely lost, of course, since it's in
the SRFI-26 discussion archive `forever', but it seems a little
bizarre to have people combing through SRFI discussions trying to find
useful code that should have been in a SRFI, but never made it...)

To answer your question directly, the original proposal seems to me to
be less than 1 LPU.  Maybe we need a `SRFI Lore' page or something for
the cute ideas that just aren't worth a SRFI.

Some day it might be interesting to have a proper curry operator:
	; assuming a (fold f i l)
	(let ((fx (curry fold)))
	     (((fx +) 0) list))
but, as the SRFI points out this isn't as interesting in Scheme as in
ML or Haskell because syntax intrudes.  And as far as I can see, a
general purpose curry requires access to implementation internals.

I think that with a change in name and a way to deal with out-of-order
parameters it becomes worth having.  It would also be nice to have the
simplicity of the original proposal, for those really simple cases
when the positions are already what you want:

	(section list 1 _ 3 _ 5)
==	(section list 1 _1 3 _2 5)

but still allowing:
	(section list 1 _2 3 _1 5 _...)

(or <1> or $1, I don't much care which, although I think the style I
showed makes the most obvious `slot's.)

By changing the name, 1/2 of the Rationale can disappear, which will
make the SRFI more understandable.

../Dave