let-in if do-expr is problematic?

[Herbert Vojčík]

Darien Valentine wrote on 24. 8. 2018 10:41:
> Herby, for those like myself who aren’t familiar with “classical 
> let-in,” could you explain more about the objective? It’s not clear to 
> me from the brief example what advantages this would provide.

Basically just readability / concise code.

The case I wanted to come with is, with more code looking 
expression-based as compared to statement / curled-braced-body based, to 
which I used the example of arrow functions and their 
right-associativity, that is:

   store => next => action => /*impl*/,

one feel the need to avoid simple cases of breaking it like

   store => next => {
     const wrappedNext = wrapper(next);
     return action => /*impl using wrappedNext*/
   }

which break the process of scanning the => sequence.

It may be useful in other cases, similarly as, for example, the 
aformenetioned arrow functions proliferated (and in all due respect, it 
wasn't _only_ because of their this-handling, b/c most of them do not 
use this at all; but because they are more convenient to write / easier 
to read).

But otherwise

   let foo=bar, baz=quux, in /*impl*/

would be basically just a syntactic sugar for

   (() => {let foo=bar, baz=quux; return completionof /*impl*/}())

but would not necessarily optically break the

   store => next => let wrappedNext=wrapper(next), in action => /*impl*/

b/c "let ..., in ..." stays in expression context.

Herby

> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>