My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.

Thursday, March 08, 2012

I Heard You Like To Write Less

Update apparently this proposal is being considered in es-discuss ... not the implicit return so far but the "redundant" function keyword.
This is last draft from Brendan Eich:

function Identifier ( FormalParameterList_opt ) { FunctionBody }
Identifier ( FormalParameterList_opt ) [no LineTerminator here] { FunctionBody }

Identifier_opt ( FormalParameterList_opt ) [no LineTerminator here] { FunctionBody }
Identifier_opt ( FormalParameterList_opt ) => InitialValue

I'm @qconlondon waiting for the next talk so I decided to take a couple of minutes to blog about this little experiment.
In ES-Discuss developers are still talking about function keyword, if it's needed or not.

I believe the fact CoffeeScript has no explicit function is one of the major reasons devs have been attracted so I made it even simpler.

Just Drop The Function

With current ES 3, 5, or 5.1 syntax I can't really see problems or ambiguity removing that keyword but if you find a case that could fail please let me know.
Of course if we use a keyword we should be able to understand the difference, i.e. with for, if, or others, and this simple test page is just an experiment: you write some code, you "functionize" it, and if the code does not run it's showed highlighted in red.
The RegExp is quite simple and straight forward and parsing time should never be a problem even for big projects.
The return is implicit, a bit Ruby style, but of course you can chose to return in the middle of a function.
Thing is, the very last statement will be returned and you can play with results.

I wonder if anyone would use such syntax on daily JavaScript coding. The parser needs improvements in any case so just think about it and let me know. Cheers


Anonymous said...

eval("h = () { alert('hello'); }");

Adrien Risser said...

I like that!

I tested the "reverse functionize" you provided me on twitter, on a few hundred lines of code it still reads perfectly.
If anyone wants it, written WebReflection style:
unFunctionize(code) {
code.replace(/\b(?:function|return)\b/g, "");

For the "return" part, if I remember correctly my C programming 101, C language does exactly the same if return is omitted.
It can lead to surprises in "if" syntaxes function calls though.

Anonymous said...

Nice work Andrea.
I can see the value of dropping the function keyword in compressed code but for development I think the use of the keyword greatly enhances readability

riffraff said...

seems that the implicit return breaks down when using statements, e.g.

(x) {if (x==1){return 1}}

But yeah, it would be nice if it worked in the general case.

Andrea Giammarchi said...

riffraf ... what about (x) {x==1 ? 1 : null} ? But I agree this concept should not change the way developers code

Andrea Giammarchi said...

eval won't work as well as it doesn't if you don't parse runtime, as example, CoffeeScript syntax

Peter van der Zee said...

I'm against dropping the function keyword (at least not without it being replaced by something that's equally recognizable as "look here, I'm creating a new function now!").

I don't mind making the return implicit, but would still like to have the option to do so explicitly. I guess the return keyword is not going away anyways because that would break a lot of code (early returns).

The main reason I don't like this shorter notation bullshit is that it makes code far less readable while the proposed gain (less typing) is still an argument I can't grok.

You type function faster than you speak it. You can't tell me that really bothers you in your every day coding. I won't believe it.

Andrea Giammarchi said...

I basically agree with you but a about the return, as it is implicit in Ruby, with the possibility to return in the middle with explicit one, I think could make sense.

As you can see in the example page, the coolest part is for inline, single operation, shortcut where at least there, arr.filter((a){a x < NUM could be one of these

Peter van der Zee said...

Yeah I agree, it totally makes sense for lambda expressions. I actually got swayed to the `{|a,b| log(a,b); })` syntax with the Ruby vs JS post (