SRFI 31 procedure vs. named-lambda (2) Dr. M. Luedde (31 May 2002 09:43 UTC)
SRFI 31 procedure vs. named-lambda (2) Chris Hanson (31 May 2002 12:54 UTC)
Re: SRFI 31 procedure vs. named-lambda (2) Al Petrofsky (31 May 2002 23:56 UTC)
Re: SRFI 31 procedure vs. named-lambda (2) Dr. M. Luedde (01 Jun 2002 09:23 UTC)
Re: SRFI 31 procedure vs. named-lambda (2) Al Petrofsky (01 Jun 2002 13:45 UTC)
Re: SRFI 31 procedure vs. named-lambda (2) Dr. M. Luedde (01 Jun 2002 14:36 UTC)

Re: SRFI 31 procedure vs. named-lambda (2) Al Petrofsky 31 May 2002 23:55 UTC

I agree with you that most of the arguments against named-lambda are
obsolete.  Namely:

  1. SRFIs were invented to make a home for useful features without
     bloating the main spec.

  2. The addition of macros means that special forms can be easily
     specified and easily implemented.

  3. The fact that user bindings may now shadow the names of special forms
     means that having extra special forms has little impact on those who
     do not use them.

I dislike the name PROCEDURE because it doesn't mix well with the name
of the PROCEDURE? procedure.  Both LAMBDA and PROCEDURE produce
procedures.  The difference has nothing to with the procedure data
type.  The difference is that one form provides a name that can be
used recursively by the thing which is being named.  Hence the name of
the special form should derive from the words "name" or "recursion",
which is why I find both NAMED-LAMBDA and REC superior to PROCEDURE.

After some thought and a look at the rrrs archives, the idea that
appeals most to me is to revive the well-established and generally
useful rec form, and enhance it just like define so that

  (rec name (lambda args . body))

and

  (rec (name . args) . body)

are entirely equivalent.

Here's an implementation:

  (define-syntax rec
    (syntax-rules ()
      ((rec (name . args) . body)
       (letrec ((name (lambda args . body))) name))
      ((rec name expression)
       (letrec ((name expression)) name))))

-al