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
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
