Infix operators for monadic functions in Swift

I really like SwiftCheck's syntax more then Fox. And this removes a metric fuckload of overhead, since it becomes the only dependency.

Right now, this is pointed at master, because I need a new release of SwiftCheck that doesn't conflict with the operators we define.

See https://github.com/typelift/SwiftCheck/issues/100 for more info.

This pull request adds new Applicative *>, <*, and Alternative <|> operators, which are needed feature in https://github.com/tryswift/TryParsec/pull/11 and all other functional libraries :sparkles: (See also: #65)

By the way, Argo is currently using the same <|> operator in Alternative.swift#L13 with precedence 140, but this causes continuous monadic operations not working nicely. For example, m1 *> m2 <|> m3 *> m4 doesn't work and must use parenthesis to work around like (m1 *> m2) <|> (m3 *> m4), which is very cumbersome. Since Haskell uses lower precedence for <|>, I have dropped it down to precedence 120 (or, precedence 125 might be a better choice as discussed in https://github.com/tryswift/TryParsec/pull/11).

I also added comments about Haskell's infix operator precedences for comparison with Runes :eyes:

Greetings.

Presently, I'm implementing Runes like so in my app:

import Argo
import Runes

public struct Product {
    public let name: String
    public let price: NSDecimalNumber
    public let code: String
    public let balanceIncrease: Double?
    public let discount: NSDecimalNumber?

    public init(name: String, price: NSDecimalNumber, code: String, balanceIncrease: Double?, discount: NSDecimalNumber?) {
        self.name = name
        self.price = price
        self.code = code
        self.balanceIncrease = balanceIncrease
        self.discount = discount
    }
}

extension Product: Decodable {
    private static func create(name: String)(price: NSDecimalNumber)(code: String)(balanceIncrease: Double?)(discount: NSDecimalNumber?) -> Product {
        return Product(name: name, price: price, code: code, balanceIncrease: balanceIncrease, discount: discount)
    }

    public static func decode(json: JSON) -> Decoded<Product> {
        return Product.create
            <^> json <| "name"
            <*> json <| "price"
            <*> json <| "code"
            <*> json <|? "balance_increase"
            <*> json <|? "discount"
    }
}

extension Product: Equatable { }
public func ==(lhs: Product, rhs: Product) -> Bool {
    return lhs.name == rhs.name && lhs.price == rhs.price && lhs.code == rhs.code && lhs.balanceIncrease == rhs.balanceIncrease
}

extension Product: CustomStringConvertible {
    public var description: String {
        return "Product <name: \(self.name), price: \(self.price), code: \(code), balanceIncrease: \(balanceIncrease)>"
    }
}

But in extension Product: Decodable I am making use of curried functions to achieve what I need. Apparently curried syntax is being removed, so going forward, would you have any suggestions on how I would achieve similar results without function currying?

This includes a few things. Some minor (formatting, SwiftCheck update), some larger (Extension API across all targets, updates for newest version of Swift 3)

Don't know how I feel about these precedence groups, tbh. I don't think I feel super great about them. Our tests are also completely broken, since it's apparently impossible to resolve the differences between how we're choosing to define these operators and how SwiftCheck defines them. No idea what to do about this.

Fixes #59 Fixes #78

Monadic composition

Here's how I'm using this with Result and RAC:

request(.GET, "/myendpoint")
  .flatMap(.Concat, transform: SignalProducer.init • (parseJSON >-> decodeSomething))

Basically, this really helps to avoid explicit closures everywhere, which I value for both readability and the avoidance of capturing strong references to self.

The composition operator

In the example above I'm using • as the composition operator (which can be typed on US keyboards with Opt-8). I threw this into the specs for this PR, because I think it really helps their clarity.

I'd love your feedback on:

• Whether you agree about the improvement to the specs
• What you think about adding this to the public API of Runes in a subsequent commit

Swift will happily coerce functions of the type A -> B into functions of the type A -> B?. That means that using flatMap with a function that doesn't return an optional will compile. But then at runtime, you will run into weird behaviour that you don't expect, or worse, Swift will segfault.

In order to prevent these problems from happening in the future, we're going to throw errors ourselves if flatMap is used incorrectly with a message letting the user know that the type of the function isn't correct. Using a default (but ultimately unused) implementation of map will push people in the right direction if they go digging.

Credit to @mattrubin for the idea: https://github.com/thoughtbot/Argo/issues/34#issuecomment-70166588

Notes regarding <*>: It doesn't seem possible to create a generic type constraint over a sequence of A -> B, so this version uses [A -> B] as a workaround (which is no problem when combined with <^>, which returns an Array). i.e., Swift borks at this:

func <*> <F: SequenceType, S: SequenceType, A, B where F.Generator.Element == A -> B, S.Generator.Element == A> (fs: F, source: S) -> [B] {
                                                                              ^^^^^^ NOPE

I didn't think too hard about style, naming, etc., that's all up for grabs! Just keen to know if you're into this idea.

Rebased against your master branch. Built all schemes of Runes from a dependent library (Argo) to test, and that was successful.

I recognize this will require developers to use Xcode 7.1, so just let me know if you've got different ideas about where this might want to go.

Looks like Apple fixed the automatic coercion of T -> U into T -> U? that was causing us issues with flatMap. Since the compiler no longer allows this, we don't need to guard against it manually.

It seems SwiftCheck has been introduced since v4.2.2, and it is affecting end users to always pull its unnecessary repository via Swift Package Manager:

$ cd my-project-using-runes/
$ swift build
Updating https://github.com/thoughtbot/Runes.git
Fetching [email protected]:typelift/SwiftCheck.git
...

I have tried both Xcode 10 (Swift 5.0) and Xcode 11 Beta (Swift 5.1), but result was the same. It's probably due to Swift Package Manager still not able to handle test dependencies nicely.

I think there needs some workaround e.g. https://github.com/pointfreeco/swift-snapshot-testing/issues/201 . What do you think?

In Sources/Runes/Optional/Optional+Alternative.swift:14 an @autclosure block is passed as an argument. This is forbidden in Swift 5.

From Swift 5 release notes:

In Swift 5 mode, @autoclosure parameters can no longer be forwarded to @autoclosure arguments in another function call. Instead, you must explicitly call the function value with parentheses: (); the call itself is wrapped inside an implicit closure, guaranteeing the same behavior as in Swift 4 mode. (SR-5719) (37321597)

Is there any solution for this?

I'd like to be able to automate the release of this lib, so that we don't forget to do things like add tags, release to CocoaPods, etc. We should script this.