Discuss
  • Const functions with joining is ready for discussion

Const functions with joining is ready for discussion

# Mark S. Miller (15 years ago)

At the last EcmaScript meeting, I proposed the "const function" notation seen at 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?

# Mark S. Miller (15 years ago)

I forgot to mention: This strawman is on the agenda for the upcoming EcmaScript meeting at the end of September.

# Mark S. Miller (15 years ago)

On Sun, Sep 5, 2010 at 7:19 AM, Mark S. Miller <erights at google.com> wrote:

At the last EcmaScript meeting, I proposed the "const function" notation seen at strawman:const_functions.

Someone -- my apologies, I forget who -- suggested that const functions would make the old never-implemented ES3 joining optimization safe.

It was Brendan. Thanks Brendan!

# Chris Marrin (15 years ago)

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 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?

~Chris cmarrin at apple.com

# Mark S. Miller (15 years ago)

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 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.

# Chris Marrin (15 years ago)

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 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

# Maciej Stachowiak (15 years ago)

On Sep 6, 2010, at 5:14 AM, Chris Marrin 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 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?

I like "const function" better as well. In the example above, foo() is "a constant function", not merely "a constant". Comparing to:

const function bar(a) {return a(foo);}

You wouldn't say, "bar is a function, but foo is a constant".

, Maciej

# Dean Landolt (15 years ago)

On Mon, Sep 6, 2010 at 5:40 PM, Maciej Stachowiak <mjs at apple.com> wrote:

On Sep 6, 2010, at 5:14 AM, Chris Marrin 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 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?

I like "const function" better as well. In the example above, foo() is "a constant function", not merely "a constant". Comparing to:

const function bar(a) {return a(foo);}

You wouldn't say, "bar is a function, but foo is a constant".

Plus (as pointed out by Mark) if function shortcut keyword lands this becomes more concise yet still just as clear: const #() {} ... or const ƒ() {} (I'm willing to pay the copy/paste or keyboard shortcut toll for the florin if just for the typographic elegance, but maybe that's just me). Either way, I can already see myself being tripped up by const () {}

# Kam Kasravi (15 years ago)

I tend to prefer 'const function' since it seems more consistent with other types of modifiers such as 'public' and 'private' covered in the classes as sugar strawman

Sent from my iPad

On Sep 6, 2010, at 7:47 AM, "Mark S. Miller" <erights at google.com> 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 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.

# Kevin Curtis (15 years ago)

If const functions and 'standard' functions are available to a developer - what on average will a developer likely use. Will a security conscious dev lean towards const functions?

If const functions are preferred then maybe the function shorthand notation - if it goes ahead - should map to const functions. Especially for anon functions - where the function keyword stands out as being rather verbose.

Or with hashes: ##(x) {...} // const function

# Peter van der Zee (15 years ago)

I really dislike the hash notation for this purpose. I have no problem with either const(){} or const function(){}. The verbosity of using const is well worth the legibility.

# Peter van der Zee (15 years ago)

Or rather, the legibility is well worth the verbosity of using const...