"ap" is backwards? about bow

[truizlop]

The definition of ap is done to keep consistency with the typeclass definition for Applicative, and the behavior of ap is not the same as in <*>. If we check the signature for both:

ap : (F<A>, F<(A) -> B>) -> F<B>
<*> : (F<A>, F<B>) -> F<(A) -> B>

<*> definition, and the usage you are proposing, is encoded in Bow as product in the Applicative typeclass, and the way you could be using it is:

Option<Int>.applicative().product(one, two).fix().map(add)

The syntax could be better but it is a matter of getting to the point where the language supports higher kinded types natively.

[stephencelis]

It may be a language barrier thing, but you have me a bit confused. You don't have <*> defined at all in Bow, so there's no signature to compare your ap with. You've also mentioned deprecating operators, so I assume <*> isn't being added?

In Haskell, ap is on the Monad typeclass and is defined with the exact same infix way as <*> (though with different type class constraints):

ap :: m (a -> b) -> m a -> m b
<*> :: f (a -> b) -> f a -> f b

So is it fair to assume that you want Bow's type classes to be consistent with Arrow's? That can definitely be a project prerogative, though porting over a language limitation is unfortunate.

[truizlop]

Sorry, I think I misunderstood it on my first read. You are right; in fact, in Cats for Scala this is reversed as well. Since your approach is more readable in Swift, we can refactor it for the sake of the usability. Our aim is to maximize compatibility with Arrow, of course, but in some cases like this, a more Swiftier approach is preferrable. I'll add this to my pipeline and perform the change in the next few days.

[truizlop]

@stephencelis please, take a look at the changes in #80, addressing the improvement you suggested here.

[truizlop]

#80 is merged and this will be in the next release.