I agree. Also, in particular, Scala's partial application syntax does tend to confuse newcomers, and can easily border on the same obfuscation level as point free style in Haskell for similar reasons (which is easier to understand, `owl = (.) . (.)` or `owl f g x y = f (g x y)`). Also, I'm not sure such syntax is actually necessary. If anything, curried operator functions like what Python has (the operator module), but hopefully more concise, would completely solve most of this, and could probably start as an easy trivial userland library. (Note that Lodash and Underscore both already provide some of these uncurried.)
On Mon, Sep 26, 2016, 06:59 Claude Pache <[email protected]> wrote: > Le 23 sept. 2016 à 20:35, Kenneth Powers <[email protected]> a écrit : > > As for resolving ambiguity, why not just do what Scala does > <http://stackoverflow.com/questions/19916169/scala-arguments-of-nested-lambdas-with-short-syntax/19917720>? > It would seem to me that nesting these functions would be a sign you need > to refactor anyway. > > > Concretely, when you write: > > ```js > listOfNumbers.map(Math.floor(@) + 1) > ``` > > what does it mean: > > ```js > _ => listOfNumbers.map(Math.floor(_) + 1) // (1) > listOfNumbers.map(_ => Math.floor(_) + 1) // (2) > listOfNumbers.map(Math.floor(_ => _) + 1) // (3) > ``` > > ? Although the most reasonable interpretation for a human would be (2), > because the parser is unable to read your mind or to make a qualitative > distinction between `listOfNumbers.map ` and `Math.floor` (both are just > functions), it will most probably misinterpret it as (3). > > That syntax looks like an attractive nuisance to me. > > —Claude > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
