Const functions with joining is ready for discussion

Chris Marrin cmarrin at apple.com
Mon Sep 6 10:18:42 PDT 2010


On Sep 6, 2010, at 7:47 AM, Mark S. Miller wrote:

> On Mon, Sep 6, 2010 at 8:14 AM, Chris Marrin <cmarrin at apple.com> wrote:
> 
> On Sep 5, 2010, at 7:19 AM, Mark S. Miller wrote:
> 
>> At the last EcmaScript meeting, I proposed the "const function" notation seen at <http://wiki.ecmascript.org/doku.php?id=strawman:const_functions>.
>> 
>> Someone -- my apologies, I forget who -- suggested that const functions would make the old never-implemented ES3 joining optimization safe. (If you don't know what that is, don't worry about it. The new explanation is self contained.) I have now enhanced that strawman page with a promotion rule for const functions that provides this optimization benefit is a predictable manner.
>> 
>> Opinions?
> 
> Forgive my outsider comment. I was not at the meeting where this was proposed, so this may have been discussed. But it seems like using 'const' in place of 'function' may be syntactically valid but it's confusing to read. It seems like 'const function', while more wordy, would be more clear, as in:
> 
> 	const function foo(a) {return a(foo);}
> 
> Omitting the 'function' keyword is going to make many instances of this look like a function call rather than a function declaration. Does that cause parsing problems or something?
> 
> 
> This was raised at the meeting without resolution. As I said then, if necessary to get consensus, I am willing to agree to "const function". That said, I don't like its verbosity. Of all things that need to by syntactically lightweight, function expressions are the most pressing. That's why we keep trying to find a shorter syntax. (I still like "#" FWIW)
> 
> If we accept const function, frankly, for the sake of readability, I would probably continue to write
> 
>     list.filter(function(e) { return e % 2 === 0; })
> 
> rather than
> 
>     list.filter(const function(e) { return e % 2 === 0; })
> 
> unless I knew that the loss of efficiency, security, or simplicity actually matters in this individual case. After all, as Sussman & Abelson say (paraphrasing from memory): "Programs should be written primarily for people to read and only secondarily for machines to execute." I do see how 
> 
>     list.filter(const(e) { return e % 2 === 0; })
> 
> can seem confusing at first. But even for a reader who doesn't know that "const" is a keyword, the code above still wouldn't be a valid function call because of the immediately following body. I've been using this shorter syntax on slides and have never seen anyone confuse it with a function call.

Right, but that's a machine readability argument. People aren't parsers, so the fact that a statement can't be a valid function call is lost on some (especially people like me :-). When I see the word 'function', I know a function is coming. If I see 'const function' I'm going to know it's a const function. If I just see const, I expect it to be a variable declaration. If I see 'const foo' I will continue to think a variable declaration is coming. It's only when I see the opening paren that I know this is actually a const function declaration. If I see 'const function foo' I can tell much more quickly that this is a const function and my brain can switch.

I have to say that Object literals give me fits. I can look at a brace for several seconds before realizing that it's the start of an Object literal and not the start of a new block. This is especially true when you pass both a function and an Object literal as parameters! I've always wished Object literals could have been a bit less concise and a bit more readable. 

It would be nice if we could err on the side of readability here.

-----
~Chris
cmarrin at apple.com






More information about the es-discuss mailing list