Functions that churn out lambdas - when?

I just wrote my own "repeated" implementation (SICP lecture 3x), and I thought the same could have been done with something of the format (repeated procedure item times), instead of dealing with another layer of abstraction by churning out a procedure that does the actual iteration ((repeated procedure times) item). At this point, choosing between both forms seems like an arbitrary flip of the coin - can anyone on /prog/ enlighten me?


(define (repeated' procedure item times)
  ((repeated procedure times) item))

But you have no idea how to order arguments, and I suggest:

(((repeated times) procedure) item)
Since scheme doesn't automatically curry ：（

[/code]
(defun repeated (f n)
  (lambda (item)
    (loop repeat n do (funcall f item))))
[/code]

Or:

(defmacro repeated (f n)
  `(lambda (x)
     (progn ,@(make-list n
                          :initial-element `(,f x)))))

(and if you must absolutely do it like >>2)

(defmacro repeated (n)
  `(lambda (f)
      (lambda (item)
        (dotimes (n ,n) (funcall f item)))))
Note you can use &rest items and APPLY instead of FUNCALL (but then f might be called as an 0-ary function).

Use:

(funcall (funcall (repeated 10) #'princ) '|SICP |)
SICP SICP SICP SICP SICP SICP SICP SICP SICP SICP
NIL
Never said it's going to look pretty!

There's a difference between the code from >>3 and >>4.
>>3's should return NIL, while >>4's will return the value of the last call to f.

>>5
I don't see the benefit of using a defmacro here? Why not use a regular function and declare it to be inlined, it should yield the same behaviour.

>>1
Both can be expressed in terms of each other, but unless you have a good reason just go with the simplest one.
The form in SICP is good for teaching abstract bullshite.

Also, SRFI 26 is better than automatic currying.

>>6
REPEATED will not be used with a functional form obviously: you are interested in the side-effects, not the value computed.

>>7
There is none. I nonetheless implemented it as a macro.

>>1,5
This really emphasizes the fact that LIFP (Lisp Isn't Functional Programming).

>>10
No, this really emphasizes the fact that common lisp isn't a LISP1; in scheme you can write (((repeated times) procedure) item).

>>11
I saw someone make a CL extension which let you use results from function in the CAR of the S-Expression, this would basically make the code (((repeated times) procedure) item) valid, and still keep it a LISP2. I'm not sure why they explicitly forbid this behaviour when they designed ANSI CL. Personally, I don't mind FUNCALL and APPLY at all, as they provide useful visual cues, but I don't understand their decision to forbid that case.

>>12

I saw someone make a CL extension which let you use results from function in the CAR of the S-Expression, this would basically make the code (((repeated times) procedure) item) valid, and still keep it a LISP2.
Either the extension was limited (therefore rendered pointless by the commitee), or it introduced other limits in the language (incompatible with the rest design).

((foo bar) baz) is just syntactic sugar for me and I don't need it, because the occasions I do this are very rare.

but I don't understand their decision to forbid that case.
I don't know the answer. You can ask in #lisp on irc.freenode.org or in <news:comp.lang.lisp>.

>>13
((foo bar) baz) is just syntactic sugar for me and I don't need it, because the occasions I do this are very rare.
In other words, LIFP!

>>14
What's the matter, too lazy to type a funcall or apply? Having 2 namespaces doesn't make it less functional, it just makes the syntax for calling functional values just slightly longer. Lisp never claimed to be purely fictiunctional, it allows you that and much more. If we didn't have Lisp-2, macros would be harder to write as reliably, and that's a price I'm willing to pay. Lisp-2 also makes code using functions more clear to understand visually.

LIFP Isn't Functional Programming

>>14
No, it is not the case that CURRYing rarely occurs in the language, (on the contrary), but that you don't need THIS syntax for it. LIFP isn't true, the functional paradigm can be embraced in either CL or scheme.

>>16
About as true as "TIRA isn't a recursive acronym".

But to get back to OPs question:

When you have nested lambdas like that, you might ask yourself what the utility does and what is the most natural way of going about it, in accordance to the rest of your utilities and style you've adopted. So, for instance, given that (((repeated times) proc) item) repeats a (proc item) form 'times' times, I'd design it as:

(define (repeated proc item times)
  (if (> times 0)
    (begin
      (proc item)
      (repeated proc item (- times 1)))))

or in its more general form (to execute a block of forms N times), like this:


; this is common lisp because I don't know anything about scheme macros
(defmacro repeated (times &rest forms)
  `(progn
     ,@(make-list times :initial-element `(progn . ,forms))))

and if you're willing to go even more general, you'll write REPEATED like this:
(repeated (3 (form1) (form2)) (5 (form1) (form4)))


(defmacro repeated (&rest args)
  `(progn                
     ,@(mapcar (lambda (x)
                 `(progn
                    ,@(make-list (car x)                              
                                 :initial-element `(progn ,@(cdr x)))))
               args)))
Now you are able to execute arbitrary blocks of code arbitrary times in sequence, for instance:


(repeat (3 (princ 'X)) ; print X

>>18
The last code didn't get through, hit the submit too early.

(repeated
  (3 (princ 'X)) ; print XXX
  (2 (princ '|random number: |)
     (princ (random 10))))
==> XXXrandom number 6random number 0

>>16
LISP Isn't Serious Programming