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

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