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

Jeff Dyer jodyer at adobe.com
Fri Mar 16 08:40:58 PDT 2007


Just to recap

###

Vassily wrote:

> 4. Some simplest idioms like 10.times do {} from Ruby.
> (10).times(function(){
>    print("Hi");
> })
> 
> Now, all those "function" just doesn't look like functions, bat rather
> blocks. 
> So word function is meaningless here and unnecessary complicates the
code.

###

Brendan wrote:

> Syntax matters, it's the user interface. It is not too late, but it
> is late. We should discuss pros and cons here in a thread.

###

Graydon wrote:

> A little haskell-loving part of me likes this (the backslash, not the
> lambda), but I also don't think it reads very well. Actually, no: I
> think "function(x) x" reads poorly, and this makes it either slightly
> better or slightly worse depending on your skill level. New users will
> balk, experienced users will like it.

###

Brendan wrote:

> Seriously, we are not going to inject any alien syntax. Vassily
> proposed a shorthand in expression closures: \ for function. Let's
> try to get back to that.

###

Lars wrote:

> I think "function" is significantly more self-explanatory to everyone
> not coming from the functional programming camp, and probably even to
> some of those (I include myself).  Anyone from the C/C++/Java/C#(?)
> camp will read "\" as meaning "the following character has an unusual
> meaning", which is not right here.  So you're overloading "\".  This
> is not the end of the world, but a consideration.
> 
> The committee has already decided not to use "fun" as a shorter
> keyword for "function" because the savings were not worth the
> cognitive load.  I think the same argument applies for "\".
> 
> In fact, the experience I've had with using the expression-function
> form in the standard libraries suggests that it is really only useful
> for fairly trivial stuff -- a couple of lines of code at most.  Beyond
> that you'll be much happier going to a multi-statement form, because
> the expression language is so limited -- it's not like Scheme, say,
> where everything is an expression.  So I would suggest that we not
> overestimate the value of the expression-function form.  (And once you
> go beyond a couple of lines, the extra "{", "}", and "return" make
> little difference in the amount you have to type and read, and
> generally make things more readable.)

###

P. T. Withington wrote:

> I would rather programs were
> easy to read than easy to write, since I spend a lot more time doing
> the former.

###

Igor wrote:

> For me function(args) { .... } is just too verbose and makes code
> harder to read especially in the case of many short lambdas.

### 

Lars wrote:

> Shortness isn't a reasonable metric by itself.  (Beating ML and
> Haskell even less so.)  The language has to balance compactness and
> clarity.  And though ES has aspects of a functional language (and ES4
> will be even more so than ES3), it is more fundamentally imperative.
> No doubt many uses will be found for the expression function syntax,
> but going to this level of terseness does not seem to be justified.
> As Tucker said, programs are read much more often than they're
> written.  "function" provides all readers with a reasonable idea about
> what follows.  "\" is overly terse, and makes sense only if you think
> "lambda" would make sense in the same context (I don't, particularly
> -- it's bad UI, to use Brendan's terminology).

###

Dave wrote:

> FWIW, I think I agree with Tucker and Lars. I don't see much value in
> introducing single-token synonyms. If it's a writeability issue,
mumble
> mumble keyboard shortcuts and IDE's mumble mumble.
> 
> Re: readability, I just don't see the 5 extra characters as that huge
a
> hardship. In a perfect world maybe the operator would have been "fun",
> but I think programs can survive a few gratuitous "-ction"s.

###

Remember (Igor) that ES4 introduces a shorter form of function
expression which avoids the need for '{', 'return', and '}' -- not a
small step forward in saving characters, and in expressing more
naturally the idea of functions as expressions. As Brendan and Dave
remind us, what is being proposed is to have a shorter spelling for
'function' in this case. As Lars and Dave point out, the working group
has tried to save shave some of those eight characters to no avail.

So here is where we stand:

The primary arguments for the proposal are based on ease of typing and
aesthetics for some (expert?) programmers. The primary arguments against
are based on ease of reading and aesthetics for some (non-expert?)
programmers. Lars also points out that the use of '\' in this way is
lexically inconsistent with the rest of the language and other C like
languages where it means "escape the next character". This contributes
to the readability problem for users with less sophisticated mental
grammars.

The way forward is to identify who are the users at the interface we are
designing? If they are primarily the sophisticated kind who read and
write lambda expressions without missing a character, then I say the
proposed feature pays for itself. If not then I say the cost to
readability is too high for too many users and the proposal should be
rejected.

Does anyone want to argue that most of our users are of the
sophisticated kind?

Jd



More information about the Es4-discuss mailing list