Discuss
  • Callable values: trying to summarize

Callable values: trying to summarize

# Axel Rauschmayer (14 years ago)

== Arrow syntax ==

The nicest proposal I have seen has been written by David Herman: gist.github.com/2011902

== More traditional solution ==

  1. Short notation for non-TCP functions: use fn; enables one to abbreviate "function" as "fn" [1]. Optional, not sure if that’s a good idea: Implicit return of completion value and lexical this.

For example: use fn; arr.map(fn (x) { x * x });

  1. Block lambdas for TCP-adhering callable blocks with lexical this, which previously seemed like the main contender. As a TCP-adhering syntactic alternative to block lambdas, Allen mentioned the following on Twitter: do (args) { ... }

Open question: fn and function behaving differently seems like a bad idea, because then things are less consistent. But then you have to wonder if fn is really worth the trouble for only saving 6 characters.

[1] twitter.com/awbjs/status/178792012215091200

# François REMY (14 years ago)

I think it's a good summary of current state of the art. Personally, I'm all-in with "do(args){}" syntax because it's the syntax that best fit (my) intuition a well as the current ES syntax (both of a function and of a block). The arrow syntax is ackward and requires you to read upto the arrow to distinguish an argument list from a partenthized expression.

Also, I share your reasoning with "fn". It should just either be an alias for 'function' or either be different enough. Otherwhise, it should not exist (to avoid creating confusion). Yet, I still think it is a valuable proposal. Maybe some random idea that just fuzzed in my brain: What about having it working a bit like the Function constructor, done the right way?

var square = fn(x,x*x); // would desugar to function(x) { return x*x; }
'fn(' + <argument-list> + ',' + <expression-statement> +')'

We could even make it default in strict mode because the compiler can know at compile time if a variable named 'fn' is defined or not (in which case that variable would override the 'fn' constructor), or can't the compiler know that?

BTW, if we are still going to make 'fn' optionnal, I have one small question: wouldn't it better to allow functions without introductory keyword instead? If it's optionnal, it's up to the developer that uses it to make sure his code is compatible, which seems fine to me.

-----Message d'origine---

# Axel Rauschmayer (14 years ago)

BTW, if we are still going to make 'fn' optionnal, I have one small question: wouldn't it better to allow functions without introductory keyword instead? If it's optionnal, it's up to the developer that uses it to make sure his code is compatible, which seems fine to me.

With introductory keyword, things are easier to parse.

# François REMY (14 years ago)

Stunned to read that from someone asking for the arrow syntax, but yes, it’s right.

From: Axel Rauschmayer Sent: Sunday, March 11, 2012 2:46 PM To: François REMY Cc: es-discuss Subject: Re: Callable values: trying to summarize BTW, if we are still going to make 'fn' optionnal, I have one small question: wouldn't it better to allow functions without introductory keyword instead? If it's optionnal, it's up to the developer that uses it to make sure his code is compatible, which seems fine to me.

With introductory keyword, things are easier to parse.

# Axel Rauschmayer (14 years ago)

Not at all. If anything, I have a slight preference for the traditional solution.

# Claus Reinke (14 years ago)

The nicest proposal I have seen has been written by David Herman: gist.github.com/2011902

Commenting on the gist proposals:

G1. shorter function syntax: (..) -> {..} just sugar for function (..) {..}

This looks like a strawman, not solving the issues.

G2. lambdas: (..) => expr

expression-oriented (no statement blocks, no explicit returns),
implicit return, no 'this'

This looks like the familiar construct from FPLs. I'd like to have it (possibly with 'fn' prefix for easier parsing) but, on its own, it might not address all JS-specific concerns, which calls for a combination with statement block oriented construct.

G3. do expressions: do {..}

evaluate statement block for completion value, block with
implicit return,  decouples explicit from implicit returns

This looks deceptively simple, but the combination of G2 and block lambdas seems to be equivalent to the combination of G2 and do expressions:

do {..}     maps to     {||..}()
{|..| ..}     maps to     (..) => do {..}

That would mean that more or less the same pros and cons apply to both combinations.

Claus

# Allen Wirfs-Brock (14 years ago)

see gist.github.com/2015544 for my current thougthts

# Axel Rauschmayer (14 years ago)

+1

Great. Very JavaScript-y syntax, easy to parse. David’s do {} fits in nicely as an IIDE (immediately-invoked do expression). In fact, your proposal does indeed seem like a natural evolution of do {} (TCP, completion value semantics, etc.), rather like a “parameterized do”.

I like use fn, but it’s not yet clear to me how it interacts with modules (including, possibly, use module). I would prefer to have an “all inclusive” version of ES.next that includes use fn, on which to build ES.next.next. But I don’t know what that would mean for legacy code, so use fn might have to be an orthogonal feature.

# Brendan Eich (14 years ago)

Axel Rauschmayer wrote:

I like use fn, but it’s not yet clear to me how it interacts with modules (including, possibly, use module)

use module;

was withdrawn.

use fn;

is just a pragma to make fn short for function. You can still write 'function' out.

. I would prefer to have an “all inclusive” version of ES.next that includes use fn, on which to build ES.next.next. But I don’t know what that would mean for legacy code, so use fn might have to be an orthogonal feature.

It should be orhogonal.

Remember, 1JS means no version opt-in. New syntax opts into its semantics (new or not -- shorthands ok too).

# Axel Rauschmayer (14 years ago)

Makes sense. I keep thinking that this kind of decision should (optionally) be made globally, possibly along with specifying exceptions for directories with legacy code. Kind of like one can specify the Java versions in Eclipse on a per-project basis. Apart from a meta tag, the module loader is one place where one could configure such things, but it might be too dynamic.

As a long-term migration strategy towards "fn" instead of "function", some IDEs could optionally warn about it being used as a variable or function name. But with blocks and method shorthands, I don’t see myself using “regular” functions much, anyway.

# Aymeric Vitte (14 years ago)

I was not aware of this document when I wrote : esdiscuss/2012-March/021050

 Reading my post again, it's indeed not clear at all that I was

referring more to the syntax than block lamdas's principles and that this should behave as block lambdas, I got this answer : esdiscuss/2012-March/021055

 Then I thought that the "do" proposals were definitely over, but

it's not the case and I have too a preference for it.

 So, taking my examples 1 and 3 (what is the baseValue property in

your document ? Similar to my GetBase ??), how could we do that ? (or please someone, just crash the idea once for all so I don't think about it any longer)

 The "fn" carrot for strict mode looks to be a good idea.

Le 12/03/2012 04:48, Allen Wirfs-Brock a écrit :