CS2 Discussion: Features: Callback hell solution: backcalls

[celicoo]

Would be great if we had backcalls as livescript:

CS6:

item, index <- someArray.forEach
console.log item

ES6:

someArray.forEach(function(item, index) {
  console.log(item);
});

[mitar]

I do not like this. It goes against the CoffeeScript indentation semantics. Why would this:

item, index <- someArray.forEach
console.log item

Be clearer than:

someArray.forEach (item, index) ->
  console.log item

[edemaine]

I'm no expert, but I think the idea is to avoid deep nesting of callbacks. Instead of the current

$.get 'ajaxtest', (data) ->
  $('.result').html data
  $.get 'ajaxprocess', data, (processed) ->
    $('.result').append processed

you could write

data <- $.get 'ajaxtest'
$('.result').html data
processed <- $.get 'ajaxprocess', data
$('.result').append processed

(based on an example from LiveScript docs)

This seems neat, but I wonder about two things: how do you specify which argument to put the callback (LiveScript uses _ to specify this, which conflicts with Underscore and CS REPL...), and how do you deal with error callbacks? (I don't see what LiveScript does with error callbacks... maybe not a big deal?)

One other thing: the operator @celicoo is proposing is apparently <-! from LiveScript. There are also <-, <~, <--, <~~, which are all unindenting versions of the corresponding right-arrow operator...

[lydell]

jashkenas/coffeescript#2762

[DomVinyard]

I'm no expert, but I think the idea is to avoid deep nesting of callbacks

async/await

[edemaine]

@lydell Nice find. Presumably, any discussion should continue over there.

@DomVinyard I'm still learning Promises/async/await (I was corrupted too early by IcedCoffeeScript and now I can't figure it out). Can the example above be written cleanly with async/await? It definitely can with IcedCoffeeScript:

await $.get 'ajaxtest', defer data
$('.result').html data
await $.get 'ajaxprocess', data, defer processed
$('.result').append processed

Hopefully I'm not too biased toward IcedCoffeeScript which I already know, but to me this feels a lot more clear notationally, in particular which argument is the callback. Also you can do awesome things like await for ... defer which you couldn't do with <- as I understand it.

[celicoo]

@mitar The main idea of backcalls is to avoid callbacks hell, as the title (and @edemaine) suggest, i use Livescript and it is fantastic.

@DomVinyard I don't think it's necessary to compare backcall's benchmark to async/await to know that backcalls are definitely faster, once it doesn't generate any kind of code, it's just pure callbacks.

[mitar]

Hm, so if the idea is just to remove indentation level, maybe we could just have an operator for that? Like:

someArray.forEach (item, index) -> \
console.log item

[nilskp]

Any callback is trivially converted into a Promise.

To use @edemaine's example:

$.get 'ajaxtest', (data) ->
  $('.result').html data
  $.get 'ajaxprocess', data, (processed) ->
    $('.result').append processed

That could be rewritten into:

new Promise (cb) -> $.get 'ajaxtest', cb
.then (data) ->
  $('.result').html data
  new Promise (cb) -> $.get 'ajaxprocess', data, cb
.then (processed) ->
  $('.result').append processed

[mitar]

Any callback is trivially converted into a Promise.

Not if the first argument of the callback is an error.

[nilskp]

@mitar, why not? Can you give an example?

[mitar]

I mean, if you just blindly pass promise's resolve as a callback to an API, which passes an error as the first argument, then your promise will resolve with an error, and never reject correctly.

[nilskp]

Of course. Nothing should be done blindly. It has to match the method signature.

[mitar]

So, can you show the above example of converting to Promises with function calls which expect node.js style callbacks with errors as first arguments? Maybe then is clearer why backcalls are cleaner.

[nilskp]

I'm not familiar with node.js style callbacks. If you provide an example, I'll rewrite it to promises, and we can see if it's doable.