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