-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add <^> and curried map() #86
Conversation
Hm, I’d forgotten I guess we could:
I’m not fond of the first one, and am unsure about the other two. Thoughts? |
There's a fourth option -- delete just the parser-only overload of |
Good point, @neilpa. |
I think the Here's some usage examples taken from the refactoring in this PR: // curried map()
anyOf(input) |> map(prepend(match))
map(prepend(match)) <| anyOf(input)
map(prepend(match))(anyOf(input))
anyOf(input) |> map { [match] + $0 }
// <^>
prepend(match) <^> anyOf(input)
// -->
anyOf(input) --> prepend(match) Ultimately I think that curried I'm partial to the Haskell style of
At the moment I'm kind of leaning towards sticking with Thoughts? |
Used Haskell's `<$>` and `>>=` as an example when choosing the precedence for `<^>` relative to `>>-`. The value is more or less arbitrary, but has higher precedence than `>>-`.
Looks great to me; what do you think, @neilpa? |
Awesome 🎉 Not sure if you want to update the mapping examples in the README here or separately. |
I'm happy to take a stab at the README here. |
🙇 thank you @sharplet! |
associativity left | ||
|
||
// Higher precedence than `>>-`. | ||
precedence 155 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One potential complication is that Runes doesn’t give a precedence for this operator, meaning it defaults to 100
.
I think if a file imports both Runes and Madness they can select which precedence they desire by explicitly redeclaring the operator, so I think that’s ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I did check Runes, and felt a little conflicted here. I should create an issue over there, because I think it would be helpful to standardise where possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌
I don’t think we need to hold up this PR on thoughtbot/Runes#30 but it’s good to have the conversation started.
Just noticed the branch name. I love it! |
So after doing some further investigation I've actually just updated thoughtbot/Runes#30 to more strictly follow Haskell's operator precedence. What do you think about doing the same here, i.e.: /// Flat map operator.
infix operator >>- {
associativity left
precedence 100
}
/// Map operator.
infix operator <^> {
associativity left
precedence 130
} |
If Runes goes for it, we’ll follow suit here 👍 |
I've just pushed some changes to the playground documentation, so they should all be working fine now. And the operator precedence stuff should also be finalised. Ok, so one list thing to go:
😌 |
Damn, you fixed the playgrounds! Thank you—I had given up on them til the 6.3 betas stabilized and then just forgot. |
Any objections to me merging this and picking up the readme later? |
⛵ |
🎉 |
Fixes #83.
I was mostly happy with this until I realised that this is the same thing as
-->
, and now there's three ways to do the same thing! As a result there's now both Reduction.swift and Map.swift, which seems a bit confusing given that-->
is also map.¯_(ツ)_/¯