Discuss
  • Arrow function declaration

Arrow function declaration

# Федор Неживой (9 years ago)

I'm looking for a champion for gyzerok/ecmascript

# Федор Неживой (9 years ago)

Link fix gyzerok/ecmascript-arrow-function-declaration

2015-10-20 11:40 GMT+06:00 Федор Неживой <gyzerok at gmail.com>:

# Bergi (9 years ago)

Федор Неживой schrieb:

I'm looking for a champion for gyzerok/ecmascript-arrow-function-declaration

Your proposal doesn't seem to solve the problem that you gave in your rationale. Let me paraphrase:

You've got curried functions, and you want to partially apply them declaratively without caring for order.

// does not work
const sumOfSquares = compose(sum, squares);
const sum = reduce((x, y) => x + y, 0);

const squares = map(x => x * x);

// would work because of hoisting:
function sumOfSquares(xs) { return compose(sum, squares)(xs); }
function sum(xs) { return reduce((x, y) => x + y, 0)(xs); }

function squares(xs) { return map(x => x * x); }

Now you are proposing some kind of "arrow declaration" that desugars to a function declaration. This makes no sense. The non-working code doesn't benefit of that in any way - there are no arrows function, only function calls.

What you are actually looking for seems to be a lazy initialisation of variables - the variable declaration is hoisted just as usual, but the initialiser would run when the variable is used the first time. The following would be what I'd envision to solve your problem:

// does work
lazy sumOfSquares = compose(sum, squares);
lazy sum = reduce((x, y) => x + y, 0);

lazy squares = map(x => x * x);

where lazy would work pretty much like a lazy val in Scala.

, Bergi

# Isiah Meadows (9 years ago)

The proposal is about more concise function definitions as well as lexical binding. The proposal would look a little more like this, if I understand correctly:

function sumOfSquares(list) => list.map(x => x * x).reduce((x, y) => x + y, 0)

// Or:
function sumOfSquares(list) => sum(squares(list))

function sum(list) => list.reduce((x, y) => x + y, 0)

function squares(list) => list.map(x => x * x)

It's not well phrased, but that, I believe, is the heart of the proposal. The common case of simple functions.

One more response inline:

On Mon, Oct 26, 2015 at 10:44 AM, Bergi <a.d.bergi at web.de> wrote:

Федор Неживой schrieb:

I'm looking for a champion for gyzerok/ecmascript-arrow-function-declaration

Your proposal doesn't seem to solve the problem that you gave in your rationale. Let me paraphrase:

You've got curried functions, and you want to partially apply them declaratively without caring for order.

// does not work
const sumOfSquares = compose(sum, squares);
const sum = reduce((x, y) => x + y, 0);
const squares = map(x => x * x);

// would work because of hoisting:
function sumOfSquares(xs) { return compose(sum, squares)(xs); }
function sum(xs) { return reduce((x, y) => x + y, 0)(xs); }
function squares(xs) { return map(x => x * x); }

Now you are proposing some kind of "arrow declaration" that desugars to a function declaration. This makes no sense. The non-working code doesn't benefit of that in any way - there are no arrows function, only function calls.

What you are actually looking for seems to be a lazy initialisation of variables - the variable declaration is hoisted just as usual, but the initialiser would run when the variable is used the first time. The following would be what I'd envision to solve your problem:

// does work
lazy sumOfSquares = compose(sum, squares);
lazy sum = reduce((x, y) => x + y, 0);
lazy squares = map(x => x * x);

where lazy would work pretty much like a lazy val in Scala.

-1 for me, for two reasons:

  1. It's inconsistent with the rest of the language, which doesn't hoist any other variable initializations, but only function definitions.
  2. It becomes non-obvious when functions are called, which can become quickly problematic when state is involved. And JS uses state much more frequently than most other functional languages (it's more OO than functional, to be honest).
# Федор Неживой (9 years ago)

Yes, Isiah is right about the soul of this proposal. Its a mostly a draft now, so yes this could be described better. If anyone can help me with the right description I would be happy to collaborate on this. This feature is not just one more sugar. I really miss it in every day development. Hope I am not alone.

# Isiah Meadows (9 years ago)

I would be inclined to agree.