return when desugaring to closures

[David Herman]

Sorry, I was unclear. I meant 'lambda' for the expression form and 'define' for the definition form.

Dave

----- Original Message -----
From: "Brendan Eich" <brendan at mozilla.org>
To: "David Herman" <dherman at ccs.neu.edu>
Cc: "Peter Michaux" <petermichaux at gmail.com>, "es3 x-discuss" <es3.x-discuss at mozilla.org>, es-discuss at mozilla.org
Sent: Thursday, October 9, 2008 9:12:26 PM GMT -05:00 US/Canada Eastern
Subject: Re: return when desugaring to closures

On Oct 9, 2008, at 4:28 PM, David Herman wrote:

> How would people feel about the declaration form being 'define'  
> instead of lambda? As in:
>
>    define const(x) {
>        lambda(y) x
>    }
>
> Maybe I'm just accustomed to Scheme, but it looks awkward to me for  
> the declaration form to be called lambda. Dylan also used 'define'.

For named functions, it's less cryptic, it has clearer connotations.  
For anonymous functions, e.g.:

   (define (x) {...})(x)

or

   return foo(define (y) {...}, z);

your mileage *will* vary, but it seems worse by a hair to me. But I'm  
used to "lambda" as a term of art.

The obscurity of "lambda" helps it avoid collisions (we have ways of  
unreserving keywords in property-name contexts, but these do not work  
for formal parameters and variables named "define", which seem  
likelier at a guess than "lambda" -- spidering the web could help  
confirm this guess).

The obscurity also arguably partners "lambda" better with "function".  
Setting up "define" as a cleaner "function" seems to switch domains of  
discourse. Concretely, we have in ES3.1 Object.defineProperty and  
similarly named functions. These "define" APIs were prefigured by  
Object.prototype._defineGetter__, etc.. This sense of "define" has  
meant "bind property name to value or getter/setter".

On the other side, Python, E, etc. use "def". But we would be verbose  
like Scheme and Dylan. So "define" vs. "lambda".

End of my bike-shedding ruminations.

/be