[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI 31 procedure vs. named-lambda (2)

This page is part of the web mail archives of SRFI 31 from before July 7th, 2015. The new archives for SRFI 31 contain all messages, not just those from before July 7th, 2015.



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