Remove internal dependency on Cats/Scalaz

[andyscott]

The core of Iota depends on Cats/Scalaz and requires some nasty tricks to get cross compilation to work. I'd like build out my own FP layer for internal use only so that the internal implementation is simplified.

Initially, the external modules would stay the same: there'd be no binary changes for the public API. We'd still conditionally build a iota for Cats and iotaz for Scalaz. I'd target this for v0.5.0.

A second (optional) step would be to remove the conditional building and just have a an iotamodule with a iota-cats and iota-scalaz extension modules. This is pretty easy to do once the iota internals are self supporting. A decision on is needed before I'd consider a v1.0.0 release.

cc @raulraja @peterneyens @fommil any thoughts?

[fommil]

I'd quite like it if there was tighter scalaz integration to be honest, e.g. if the relationship between a type and its generic repr was an Isomorphism and we could add those to the companion with a compiler plugin. But that's secondary to making your life easier.

[andyscott]

The public API can maintain full integration with Cats and Scalaz via the cross compilation trick that's currently being used. My main concern is that maintaining the internal macros is tricky. If we reimplemented the the fundamentals (Applicative, Monad, Validated, etc) for private use internally it might make maintenance a lot easier.

👍 to full a continued tight integration with Scalaz

[fommil]

btw, said Isomorphism could be provided by a scalaz compiler plugin, so iotaz doesn't even have to do that stuff. I think it's generally useful to have it anyway.

[peterneyens]

It is probably at least worth investigating what we would need.

• I imagine Functor, Applicative, Monad and Traverse ?
• If we had a stack overflow using scalaz traverse that would probably entail we would need some sort of trampolined data type as well I guess?
• I remember that at some point you saw some use for Cofree / EnvT. I don't think we are using them at them moment?

[andyscott]

@peterneyens yep:

• Functor, Applicative, Monad, Traverse, and some kind of ValidatedNel data type
• The stack overflow can happen in both Cats and Scalaz variations. It's several magnitudes easier to trigger in Scalaz due to more calls on the stack in Scalaz itself when calling .map and .traverse.
• Cofree / EnvT can definitely be removed.