That hash symbol

Brendan Eich brendan at
Fri Mar 25 23:33:54 PDT 2011

On Mar 25, 2011, at 8:45 PM, David Foley wrote:

> My response was simply this : assuming normative scope in conversational tone, that I would welcome is a venue where end users (engineers and architects as well as scripters) could contribute to the developer experience of using JavaScript without incurring the wrath

"wrath"? I may have failed to add a smiley, but c'mon. No wrath here.

> of it's fathers, which appear to be more focused on the interpreter of the language rather than the thrust of it's use cases (which almost always appear to bottom out on library abstractions to solve the issues).

What do you mean? What library abstractions, and what issues? Please be specific.

Remember, I'm the one pushing for new syntax more than many others involved in TC39:

> I really would have hoped that rather than assuming an asses POV that this list would assume the best without requirement of over-qualification.

Skipping, I don't know how to read this and I really don't want to guess ("asses POV" meaning "ass's POV"? Who said anything about "ass" here? Yeesh.)

> Like it or not, JavaScript is the glue of the web. This language space has been embroiled in vendor politics

There is no "vendor politics" in this thread, though.

> since day one- end users need an effective forum to describe their requirements- that is what I was espousing. Clear enough? 

No, you have not made any requirement clear. Let's take your first post today:

> Implicit functions?
> globalMethod(argument)
> {
>     // implementation
> };
> AnObject.prototype.method(value)
> {
>     // whatevs
> };

Dropping function as the leading keyword makes these examples ambiguous, due to automatic semicolon insertion as Mike Samuel pointed out.

Sure, losing the heaviness of eight-letter 'function' is a goal, and we've discussed it often:

The wiki has a strawman on it:

This is not going forward as-is, and the plan is to write a new strawman, but the goal of shorter function syntax is getting attention.

We spent time yesterday at the TC39 meeting not only on shorter syntax but exactly how to support better |this| handling for several distinct use-cases: inner functions that want the outer |this|, callbacks that want a certain |this|, and object methods that want the receiver when called as methods of a given (receiver) object (else possibly a default such as the outer function's |this|).

Anyway, there's more to do than fix syntax, but the syntax has to be unambiguous. That's the first requirement, before we can go further.

Kevin Smith started this thread by objecting to #, and that's fair. It's a bit chicken-scratchy. If we can find a better introductory keyword or formal parameter bracketing form, I'm game. I don't think <>-bracketing is it, not only due to E4X (who cares, right?) but mainly because that breaks symmetry with call expression, which uses ()-bracketing.

CoffeeScript uses () for formal parameter bracketing (where there are formal parameters; parameter-less functions start with -> or =>), but allows call expressions to elide the ( and ) where there is no ambiguity -- no ambiguity according to CoffeeScript's complex, evolving rules for disambiguation.

I had the chance to talk to Jeremy Ashkenas about this recently, and he does not recommend trying to graft these rules onto JS and standardize them. I agree.

So a leading character instead of 'function' still seems like the cleanest solution. Ideas other characters than '#' are welcome, since so long as they are not used in the language already (either as punctuators, operators, or identifier characters), they can't introduce ambiguity.

> You do yourself a disservice by assuming idiocracy.

I did not assume anything.

(Good movie, though -- Mike Judge is great!)


More information about the es-discuss mailing list