let-in if do-expr is problematic?

# Herbert Vojčík (a month ago)

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.