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 01 Jun 2002 13:44 UTC

> Al Petrofsky writes:

>  > 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.

>  Following your line of thought, wouldn't we obtain a new instance of
>  the `cons' vs. `pair?' mismatch?

Cons is the fundamental pair constructor.  It would have been
reasonable to name it PAIR, but adding an auxiliary pair constructor
now and naming it PAIR would be confusing.  Similarly, lambda is the
fundamental procedure constructor.  If you were designing a new
language and made your construct the fundamental one, with an
auxiliary form named anonymous-procedure for what we now call lambda,
then that would be consistent, but it's twenty years too late to make
such a change to the very heart of scheme.

> Agreeing on functionality, it remains to find the right balance
> between respecting the history of Scheme (`rec') and providing (what
> seems to me) a more systematic name (`procedure').

I don't think we've agreed on functionality.  Rec's semantics are more
general and powerful than procedure's, allowing things like this:
(rec ones (cons 1 (delay ones))).

Rec's semantics are also a simpler special case of letrec's, just as
the name REC is a substring of LETREC.  The addition of
signature-style recs would be consistent with signature-style
definitions.  I thus find rec to be a good fit with the system.

-al