Michael Sperber [Mr.  Preprocessor] writes:
 > >>>>> "WP" == Walter C Pelissero <xxxxxx@pelissero.org> writes:
 >
 > WP> The sense of my previous message is: IMHO, SRFI-26 is not general
 > WP> enough and introduces a negligible improvement over standard
 > WP> Scheme.
 >
 > I did a quick grep and subsequent analysis of all calls to MAP and
 > FOR-EACH in the current development version of Lula, which is about
 > 15000 lines of code.  There are more than 80 partial calls to MAP
 > and FOR-EACH which take abstraction operands which are merely
 > specialized calls to other procedures.  All of them fit the pattern
 > of SRFI 26.  On every one of them, I wanted to use something like
 > SRFI 26 while I was writing the code.  I conjecture there is still
 > a number of other calls which would benefit from SRFI 26.
 >
 > So this particular application would benefit from SRFI 26 roughly
 > every 200 lines of code.  I don't think that's too bad.

Do your figures make the SRFI a less incomplete solution?

What your figures say is that your code might benefit from a short
form to express trivial lambda expression, a compact way to express
partial application, or however you want to call it.

I assume you have read
http://srfi.schemers.org/srfi-26/mail-archive/msg00038.html

so you are already aware of the issues about this SRFI:
   - it addresses a trivial problem
   - it doesn't provide a complete solution

Why is the problem trivial?  The above mentioned message shows you how
easy is to write a general solution and a special solution (one
argument) that fix a superset of this SRFI cases.  Others may be
possible with comparable effort.

Why doesn't it provide a complete solution?  The same message explains
why and how the SRFI is incomplete: it lacks parameter skipping,
duplicating and swapping.  The message also provides some
(almost-)real-life examples.

Why an incomplete solution is bad?  Simply because as much as you
needed (not very much) a solution for the cases this SRFI addresses
you will, sooner or later feel the need for a solution for the
remaining cases.

Why that?  Because the remaining cases are not less likely and they
are not on a different complexity level, they are indeed as trivial as
the ones this SRFI addresses.

What do you do when you hit the limits of this SRFI?  Either you write
a special solution for the remaining cases and call it curry2, or
you write a solution for a superset and call it L.  I belive both
situations are bad.

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

Common Lisp has some examples of redundancy of this sort.

Regarding the residual arguments issue, if you like, fn can be fixed
in no time and turn it into:

    (define-syntax fn
      (lambda (form rename compare)
	(letrec ((arg-number
		  (lambda (x)
		    (if (symbol? x)
			(let ((s (symbol->string x)))
			  (if (char=? #\$ (string-ref s 0))
			      (or (string->number (substring s 1 (string-length s)))
				  0)
			      0))
			0)))
		 (number-of-arguments
		  (lambda (l)
		    (let loop ((l l))
		      (if (null? l)
			  0
			  (let ((x (car l)))
			    (max (if (pair? x)
				     (loop x)
				     (arg-number x))
				 (loop (cdr l))))))))
		 (make-argument-list
		  (lambda (n)
		    (do ((n n (- n 1))
			 (l '() (cons (string->symbol (string-append "$" (number->string n))) l)))
			((zero? n) l)))))
	  (if (integer? (cadr form))
	      (list 'lambda (make-argument-list (cadr form))
		    (cddr form))
	  (list 'lambda (make-argument-list (number-of-arguments form))
		(cdr form))))))

So that you can write:

    ((fn + $1 $3) 1 2 3)
and
    ((fn 9 + $1 $3) 1 2 3 4 5 6 7 8 9)

The optional arity is at least as compact as the "slot notation".

Dealing with the, IMHO, not so interesting case:

    ((fn -5 apply $1 $3 $5) 1 2 3 4 5 6 7 8 9)

to expand to

    ((lambda ($1 $2 $3 $4 . $5)
       (apply + $1 $3 $5)) 1 2 3 4 5 6 7 8 9)

is left as an exercise.

--
walter pelissero
http://www.pelissero.org