Tweets automatically exported to html by my open tweet android app.
Oleg Nizhnik @ Wed Feb 27 07:59:41 2019
In ZIO you have single monomorphic Error and single monomoprhic Context.
It’s interesting enough that ZIO now can have arrow-like possibilities, still you can-not abstract over everything using the single parameter of the simplest kind.
Even in DOT.
Believe me. I’ve tried.
Oleg Nizhnik @ Wed Feb 27 07:52:09 2019
8. Tagless Final is not kind-specific. You may abstract over some profunctors P[_, _], transformers T[_[_],_] etc.
That means that the modelled language can have any types, not only the simple ones. Only your imagination limits you.
Oleg Nizhnik @ Wed Feb 27 07:48:20 2019
7. Some of most complex, or on the contrary most boring algebras may be generated via macros or long-chained implicits using contextual information.
Similar machinery for ZIO that could craft trait to mix-in to your super-handler may be very hard if even possible.
Oleg Nizhnik @ Wed Feb 27 07:40:32 2019
Using ZIO-only you can probably convert from ZIO to ZIO, via mappers of your context R or Error E in ZIO[R, E, A]
If you want something more interesting you will find again that Tagless Final is the unbeatable champion in the expression problem solving in scala world.
Oleg Nizhnik @ Wed Feb 27 07:37:33 2019
Example of such languages may be: applicative parser, STM or even some non-functor typed business rules language, loadable \ deserializable from config or database.
Don’t miss John’s video about free applicatives for tagged initial encoding variant
Oleg Nizhnik @ Wed Feb 27 07:33:40 2019
6. Using TF you can have multiple domain languages. Some of them may have synchnous or even sub-monadic composition features. And you easily can embed one language interpreter to another using pretty FunctorK machinery from library.
Oleg Nizhnik @ Wed Feb 27 07:12:37 2019
In ZIO reader context you can embed bunch of capabilities, but may not change bult in ZIO composition toolset. Which is powerful. Probably to powerful for the most of domains you’d like to model.
Oleg Nizhnik @ Wed Feb 27 07:08:44 2019
5. Real power of tagless final are recursive algebras. Monad and Bracket are just examples of such.
So you can model typed languages with any semantics like special form flow control like loops and conditionals.
TF is really green lantern ring for domain design.
Oleg Nizhnik @ Wed Feb 27 07:03:04 2019
Using only ZIO types you can not restrict ZIO capabilities. So you can not be sure if some parts of your code may actually have concurrent semantics, which can start new fibers or allocate any number of Refs of any type and …
Oleg Nizhnik @ Wed Feb 27 07:00:04 2019
4. Using tagless final you can require very specific things about your F. You may require only Monad or Race or particular ContextShift. So you can have fine tuned code and know exactly which parts of your code has only sequential composition and which may race conditions.
Oleg Nizhnik @ Wed Feb 27 06:55:14 2019
However DatabaseRead[Users] with DatabaseRead[Orders] can have only one implementation for any method.
So you urged to represent them as pair of different traits DatabaseReadUsers with DatabaseReadOrders .This limits your polymorphism and reusability and also very golangish.
Oleg Nizhnik @ Wed Feb 27 06:49:20 2019
3. Using TF you can have multiple parametrized algebras in your requirement context with different implementations, e.g. DatabaseRead[F, Users] and DatabaseRead[F, Orders]. These can and probably have different implementations.
Oleg Nizhnik @ Wed Feb 27 06:46:46 2019
So you doomed to push evel smalest effects to the top level with sugfested ZIO approach.
This may result in overall decrease of abstraction level of different parts of complex application.
Oleg Nizhnik @ Wed Feb 27 06:42:06 2019
Scala however has not record union/subtraction value level operations, so there is no possibility to “inject” new handler to your context for subsequent use with ZIO effect rotation.
Oleg Nizhnik @ Wed Feb 27 06:40:00 2019
So your application could have effect cascading from the most powerful to the most precise requirements
implicit0 via may be great support for the second approach
Oleg Nizhnik @ Wed Feb 27 06:38:27 2019
2. One effect/syntax could not be derived from others.
Using TF you can make dependent instances (HasUserState[F], Logging[F]) => Signup[F]
(MkRef[F], Metrics[F]) => F[UserCache[F]].
Oleg Nizhnik @ Wed Feb 27 05:19:04 2019
1.Effect handlers can’t be automatically applied. You must melt a big pack of mixins
new Handler1 with Handler2 with…
before you can start the calculation.
Oleg Nizhnik @ Wed Feb 27 05:05:38 2019
The new ZIO aproach is a great breakthrough for us and drop-in replacement for our own ReaderT.
Still it could not be full a replacement for our tagless final architecture.
Want to know more? One like – one thing tagless final can do that rotated effects in ZIO can’t.
Oleg Nizhnik @ Fri Feb 22 06:52:55 2019
@jdegoes It might be an answer not only to the “best IO” but also to the “principled [micro|nano] services framework” and even to the “language of differentiable computations” for the machine learning area
Oleg Nizhnik @ Fri Feb 22 06:52:00 2019
@jdegoes We must replace for/do with stronger multidimensional composition language. Second option for now is some macros/plugin able to compile scala subset to this abstract “generalized arrow” format.
Oleg Nizhnik @ Fri Feb 22 06:51:40 2019
@jdegoes For the last couple years I’m pretty sure that secret life after monadic tagless final is process algebras tagless final a-la monoidal categories.
It has best properties to describe concurrent and distributed computations
John Ⓐ De Goes @ Thu Feb 21 13:23:36 2019
What’s the secret to life after tagless-final?
How do we get testable, modular, functional effects in Scala that fully infer and are fast, concise, composable, and easy to teach?
Reply below for “None of the above”.