Replace hanlders on localized parts of the computation.

[vic]

In fx-rs our Effect Row is totally customizable, we even have lenses to perform operations on the effect context (Context Adaptation). This talk is about subtituting a handler for specific subparts of the computation, for us handlers are provided via the context, so given a current context type we can replace some part of it while keeping the very same structure .

I believe it is totally possible using fx-rs, perhaps we even have some test that does this. And we should invest some time at implementing smoe demo for it. Particularly because the talk mentions how this can be an alternative to typeclasses.

Also in an experimental branch (somehwere in vic's jj repo) our handlers had tags, and we were able to provide a handler via a tag from far away (far meaning, when the context type has grown, but tags were used to "route" or "locate" specific handlers)

https://www.youtube.com/watch?v=LDlnri5r4AE

[vic]

For us, our Fx::adapt is what makes Context Adaptation possible, and I believe we dont need "paths" or "tags" for replacing an specific part (say replace an specific handler for just part of the computation). We have lenses, and I believe it is a much better alternative than using "paths" to indicate where to replace, also our context row (this is the term commonly used in literature) is different in fx-rs. In other systems like Kyo or Zio, they have an special structure that maintains the effect row (early zio used to have Has) and Kyo uses Scala's union types. They are basically a typed set of abilities. However in our fx-rs kernel (See previous link) we impose no restriction on the structure of the context S of Fx<S, V>. Meaning that S can be an actual rust struct modeled by the user for their particular domain. In this struct we could have two fields of the same ability type, but used for different purposes (as proposed in the talk linked above) and we in fx-rs can use lenses to replace just one of those fields with a different ability. Instead of "tags" or "paths" the application code uses these different fields from the context, (presenter answered to a question about these "paths" nearly the end of the talk and said "you have to have a way to differentiate them " for being able to replace any of them independently, in our case they are just two fields, having lenses pointing to them even if deeply nested inside the structure, and being able to replace them on scope. I should continue investigating this for our paper and include demos of this.