Add <^> and curried map()

[sharplet]

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.

¯_(ツ)_/¯

[robrix]

Hm, I’d forgotten --> is literally map. I’m used to calling it “reduction” since that’s the term applied in the derivative parsing paper.

I guess we could:

• have multiple operators
• replace --> with <^>
• leave --> in peace

I’m not fond of the first one, and am unsure about the other two. Thoughts?

[neilpa]

There's a fourth option -- delete just the parser-only overload of --> which resolves #80. Then there's distinction between the reduction and mapping operators.

[robrix]

Good point, @neilpa.

[sharplet]

I think the --> operator is nice from a public API point of view. It has an interesting finality to it, that makes it feel natural for building your model objects. But it feels different to <^> because of the order of the arguments.

---

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 map() probably works best in conjuction with |> and trailing closures. In this case |> map {} is basically identical to --> and the difference probably amounts to a stylistic choice (or whether you're importing Prelude).

I'm partial to the Haskell style of <^>. I like how the example reads: "prepend match over any of input" (more or less).

--> is a different style, but I can see an argument for it being more intuitive. Also, we already have it!

---

At the moment I'm kind of leaning towards sticking with --> and map(), and removing <^> (even though I personally prefer it). Mainly because it ain't broke.

Thoughts?

[robrix]

Upon reflection, I like the spaceship operator, and I’d like to keep it in. What do you think about @neilpa’s suggestion re: resolving #80?

[sharplet]

@robrix Works for me.

I've pushed 254134a making that change, for your review (and @neilpa's). At this point I've chosen to replace --> with |> map wherever trailing closures are used, and with <^> where named functions are used.

[robrix]

Looks great to me; what do you think, @neilpa?

[neilpa]

Awesome :tada:

Not sure if you want to update the mapping examples in the README here or separately.

[sharplet]

I'm happy to take a stab at the README here.

[robrix]

:bow: thank you @sharplet!

[robrix]

Just noticed the branch name. I love it!

[sharplet]

So after doing some further investigation I've actually just updated https://github.com/thoughtbot/Runes/issues/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
}

[robrix]

If Runes goes for it, we’ll follow suit here :+1:

[sharplet]

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:

• [ ] README

:relieved:

[robrix]

Damn, you fixed the playgrounds! Thank you—I had given up on them til the 6.3 betas stabilized and then just forgot.

[robrix]

Any objections to me merging this and picking up the readme later?

[sharplet]

:sailboat:

[robrix]

:tada: