On Sun, Mar 11, 2018 at 2:36 PM, Peter Jaszkowiak <[email protected]> wrote: >> To clarify: The way that bare style and topic style are distinguished are >> not by the absence/presence of a topic reference. Bare style has a simple >> and strict syntax: any identifiers, separated by `.`s, optionally preceded >> by `new` or `await`. > > So `x['hello']` would not be valid? Seems pretty inconsistent. I think that > checking for the lexical topic token would be simpler and easier for > developers.
I strongly disagree - I thing JS's approach is a large improvement over the previous pipeline proposal, for two reasons. 1. As they already stated, it helps avoid accidental mis-types, like `x |> f()` when you meant `x |> f` - you get an early syntax error instead. 2. It *purposely prevents* point-free shenanigans, where you might type `x |> f()` on purpose, *intending* f() to resolve to a function that is then called with x. Instead you have to write `x |> f()(#)`, which has a much clearer intent, as it's written exactly how you'd call it if you wrote it out without the pipeline. More importantly, imo, it makes point-free stuff like `flip` or the like pointless (uh, no pun intended) - instead of doing abstract manipulations of the argument lists, you can just call the function normally, with # put where you want. >> Any pipeline body that does not fulfill that simple and strict syntax is >> in topic style. However, any pipeline body that is in topic style also must >> contain a topic reference, or else it is an early syntax error. `x |> f()` >> is in topic style; it is also an early syntax error, because it is a >> topic-style pipeline that does not use the topic reference. > > This seems to not support auto-currying functions. For instance, > **lodash/fp** has auto-currying functions which take an iteratee as the > first argument: > > ```js > // `lodash/fp/filter` is iteratee-first data-last: > // (iteratee, collection) > var compact = fp.filter(Boolean); > compact(['a', null, 'c']); > // ➜ ['a', 'c'] > ``` > > So someone might want to do something like the following to utilize this > behavior: > > ```js > ['a', null, 'c'] |> fs.filter(Boolean) > ``` This works just fine, you just need to explicitly call it like: ``` ['a', null, 'c'] |> fs.filter(Boolean)(#) ``` >> optionally preceded by `new` or `await` > > This seems very arbitrary and _not_ forwards-compatible. I agree with arbitrary, tho I think new/await ends up being reasonable. What part of it do you think isn't forwards-compatible? Afaict, we can definitely add new bare-style forms in the future, as attempts to use them today would be a syntax error. > By only allowing identifiers, you're requiring people to create unnecessary > intermittent variables. I propose that you allow any expression on the > right-hand side of the pipe operator, and decide whether it's in topic style > or bare style based on the inclusion of the lexical topic token. Your > argument that making it very restrictive reduced cognitive burden doesn't > make sense to me at all, as remembering what is and isn't allowed is more > difficult than just remembering "if it doesn't have the token, it will call > the function specified by the expression with the argument of the result of > the previous step in the pipeline". There is never a need to create intervening variables, you just need to use topic style. ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
