Short Functions

Isaac Schlueter i at
Sun May 22 12:18:39 PDT 2011

On Sat, May 21, 2011 at 23:07, Sami Samhuri <sami at> wrote:
> The semantics have shortcomings though and introducing new syntax to save a
> few keystrokes is frivolous.

Cutting out many kilobytes of code from JavaScript programs by
streamlining the single-most commonly-used idiom is hardly frivolous.
In fact, I'd argue that it should be one of the main goals of this
list and of TC-39.

Adding new semantics to the language seems frivolous to me, if doing
so does not solve problems we actually have today.  Lambda-blocks, as
proposed currently, adds considerable surface area to the language
without providing any real value.

The complications have not been very well explored, and are not
trivial, in my opinion.

I am also unconvinced by the "looks like a block" argument.  The body
of a es-current function also "looks like a block", and no one seems
to have a problem with it.  Shall we say that "return" in a while loop
should be a break, because its body "looks like a function body"?

// 1: a current function
x = (x) {
    return x * x

// 2: a lambda-block
x ={ |x|
    return x * x

// 3: a current block
for (i in x) {
    return x[i] * x[i]

Who's to say that the lambda-block[2] "looks like a block[3]" any more
than the regular function[1]?  It's extra syntax above and beyond a
current block in either case, and in fact, because it can be wrapped
in parens (since it's an expression), it behaves in the language
*much* more like a function than like a block.

The fact that {||}-style blocks can be passed and assigned to
variables makes it remarkably more complicated to reason about them if
their return/break/continue semantics are different from existing
functions.  Because of the fact that they are expressions which can be
manipulated, they are more akin to functions than to blocks.

The examples from Claus and Allen fill me with trepidation.  Please
don't do this awful thing.  It is the problem with Ruby.  We don't
need to invent new versions of "for" and "while" in every program.
JavaScript's minimal semantic surface is a strength, not a

At the very least, the implications of this semantic change need much
much more exploration than the other short-function proposals.  I
realize that it's exciting, but the best footguns typically are.


More information about the es-discuss mailing list