Expression closures - use-cases for shortcut lambda syntax(blocks)

Jeff Dyer jodyer at adobe.com
Mon Mar 19 12:01:57 PDT 2007


> From: Dave Herman [mailto:dherman at ccs.neu.edu]

> > without the parens around a single formal, but I've been writing a
lot
> > of ML code lately :) Maybe requiring parens is better; why have two
ways
> > to write something when one will do! Also, for now let's not extend
this
> > syntax to binding forms, inside or outside of a class. I have
concerns
> > about readability.
> 
> In your opinion, should we allow both
> 
>      function(formals) expression
>      (formals) => expression
>
> with the former allowed as both a declaration and expression form and
> the latter allowed as only an expression form? Or do we only allow
> 
>      (formals) => expression
> 
> and only as an expression form?
> 
> If we choose the latter, then there's no way to write function
> declarations with expression bodies, which seems like an unnecessary
> restriction.

This is a trick question! We already have function expressions with a
'function' head and a '{...}' body. Dropping the 'return' and braces as
a *convenience*.

The cool new form being proposed here doesn't replace these functions
with statement bodies, but does replace their expression bodied
counterparts, except when they are used as declarations.

So, we either:

* drop the convenience altogether (sorry Brendan & Lars)
* keep the convenience in declaration contexts only
* keep the convenience in both contexts and have more than two ways
  to write function expressions

I'm less of a fan of function declarations with expression bodies than
some other TG1 members, so I could live with the first option. 

But given that we want to keep this convenience for function
declarations, I actually think that the third option is the best one. It
avoids the usability issue of special casing. I also think that some
users will prefer the keyword form of function expressions over the
punctuated form.

I say we do it all.

Jd




More information about the Es4-discuss mailing list