You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 21, 2022. It is now read-only.
@js-choi since you suggested over on the pipeline operator proposal to leave feedback on your slides on this repo, but I don't see an issue for it, I thought I'd create one. Please let me know if you think this feedback belongs on a specific other issue, though.
One minor thought I had, specifically about the slides you linked: something that might make sense to add to the last page dealing with whether it competes with or complements the pipeline operator proposal. This might be more of a social benefit than an objective language benefit -i t could conceivably be a decent consolation to the decent number of people still wishing that F# syntax could be revived from the dead. This proposal plus the hack token is definitely no F# pipe operator, but the two combined do have some similar properties:
in that they can pass as many unary functions as they like, and they only have to type the dreaded ^ once. They have to also type Function.pipe, and wrap their list of unary functions in parentheses, which they wouldn't with F#, but crucially, they don't have to wrap the original expression ('foo' above) in parentheses. They also don't need to pay an ugly syntax tax on every unary function, which opens the door slightly more to purist functional data-last libraries like fp-ts.
It certainly won't totally satisfy everybody (or even anybody?), but as someone who badly wishes the committee had decided on F# rather than Hack, (but has accepted that they... didn't) - this makes me feel a little better. And maybe I'm not alone?
The text was updated successfully, but these errors were encountered:
Thank you for looking over the slides and leaving your feedback. It is indeed my hope that a pipe function can act as a bridge of convenience and fluency between sequences of unary functions and other APIs. I’ve modified my slide with an example based on your ideas.
@js-choi since you suggested over on the pipeline operator proposal to leave feedback on your slides on this repo, but I don't see an issue for it, I thought I'd create one. Please let me know if you think this feedback belongs on a specific other issue, though.
One minor thought I had, specifically about the slides you linked: something that might make sense to add to the last page dealing with whether it competes with or complements the pipeline operator proposal. This might be more of a social benefit than an objective language benefit -i t could conceivably be a decent consolation to the decent number of people still wishing that F# syntax could be revived from the dead. This proposal plus the hack token is definitely no F# pipe operator, but the two combined do have some similar properties:
Which arguably isn't so different from what the Fsharpies want:
in that they can pass as many unary functions as they like, and they only have to type the dreaded
^
once. They have to also typeFunction.pipe
, and wrap their list of unary functions in parentheses, which they wouldn't with F#, but crucially, they don't have to wrap the original expression ('foo'
above) in parentheses. They also don't need to pay an ugly syntax tax on every unary function, which opens the door slightly more to purist functional data-last libraries like fp-ts.It certainly won't totally satisfy everybody (or even anybody?), but as someone who badly wishes the committee had decided on F# rather than Hack, (but has accepted that they... didn't) - this makes me feel a little better. And maybe I'm not alone?
The text was updated successfully, but these errors were encountered: