Review Functors

[eparejatobes]

Similar to #56.

• [x] can we add functor composition syntax? Yes
• [x] should the bound in F[X <: Source#Objects] be F[Category.is[Source]#Objects]? I think so No need to We are using functor#SourceObjects instead
• [x] it looks like Functor.is[_] should be left undefined type is[Fnctr <: Functor] >: ... <: ... if we want syntax for composition. Review this. Solved Added a weaker inferIs[Fn <: Functor] >: is[Fn] <: is[Fn] alias.

[eparejatobes]

Note to self: I think I should go back to not having upper-bounds containing projections; if you need <: X#Y where X <: Buh use Buh.is[X]#Y instead, and give it a name. Example:

// inside functor
type SourceObjects = Category.is[Source]#Objects
type TargetObjects = Category.is[Target]#Objects
// now the type constructor
type F[X <: SourceObjects] <: TargetObjects

[eparejatobes]

Re https://github.com/ohnosequences/stuff/pull/57#issuecomment-337589581:

There's no need for the Category.is there. We do need names like SourceObjects, but the is for a type variable Fn <: Functor would bound them to be Fn#SourceObjects. Then, if we need to do something with that, we have a value Category.is[Source], for which the projection #Objects will match is[Fn]#SourceObjects = Fn#SourceObjects = Source#Objects.

[eparejatobes]

A note for future optimizers: you cannot make FunctorSyntax a value class; type inference fails (yes, is a bug).

[eparejatobes]

LGTM