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