On Sun, Mar 11, 2018 at 2:36 PM, Peter Jaszkowiak <p.jasz...@gmail.com> 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
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
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:
> // `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
> ['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.
es-discuss mailing list