scala/scala

Discord is now Scala’s main chat platform. Please join us at https://discord.com/invite/scala

Fabio Labella

@SystemFw

@mdedetrich actually Haskeller were dealing with a problem that required final tagless, but it was a specific one, and then we found out about the broader benefits of the approach. Btw this problem is why Martin is (incorrectly, imho) still skeptical about final tagless: lifting monad transformers automatically. It's akin to thinking that the Web is useless because you have no need to create documents with links to share scientific articles at CERN: basically a fallacy that the reason something was created it's also the reason it still exists/is useful.

The same fallacy happens with IO and laziness.

Ghost

@ghost~5c2a2354d73408ce4fb3431e

I played with an encoding using ReaderT and a type level set to hold the algebras, but I found the mental overhead to be much higher than the boilerplate problem it was solving. I've learn to just accept a little bit of boilerplate in exchange for the explicit nature of the code.

Fabio Labella

@SystemFw

yeah, I'm not saying that these libs are necessarily better. Just that there is more to the technique that it meets the eye and "I don't see why this even deserves a name" it's pretty shortsighted if you actually delve a bit into it.

Ghost

@ghost~5c2a2354d73408ce4fb3431e

(and in the same line of thought, I am creating an Emacs plugin to convert import lists into explicit lists so I never have to guess where anything comes from)

Fabio Labella

@SystemFw

ah, I would like that plugin :)

Ghost

@ghost~5c2a2354d73408ce4fb3431e

you'll have to find it :wink:

Dale Wijnand

@dwijnand

btw @fommil was HFunctor what you were looking for, last week?

Ghost

@ghost~5c2a2354d73408ce4fb3431e

I am referring to Scala when I talk abotu "final tagless" not needing a name. I don't think it adds anything to the normal everyday usecases... but the abstraction maybe makes sense to the small group of people who are pushing the boundary. Make sense?

@dwijnand no! HFunctor has the wrong shape, I was aftfer FFunctor

and it doesn't have an official package, it's just been reinvented several times over. Named as "functor over functors"

it cats it is called FunctorK

Dale Wijnand

@dwijnand

how are HFunctor and FFunctor different?

Ghost

@ghost~5c2a2354d73408ce4fb3431e

you're going to make me translate this to Scaal, aren't you? :laughing:

Dale Wijnand

@dwijnand

well that's one way

but I'll take any way

Ghost

@ghost~5c2a2354d73408ce4fb3431e

trait FFunctor[A[_[_]]] {
  def ffmap[F[_], G[_]](af: A[F])(fk: F ~> G): A[G]
}

you know what ~> is?

Dale Wijnand

@dwijnand

yep

Ghost

@ghost~5c2a2354d73408ce4fb3431e

it's a natural transformation, so it's like F[a] => G[a]

Dale Wijnand

@dwijnand

no that's just FunctorK

Ghost

@ghost~5c2a2354d73408ce4fb3431e

whereas HFunctor is more like

Dale Wijnand

@dwijnand

This message was deleted

Matthew de Detrich

@mdedetrich

@SystemFw I actually am more with Martin on this one, I think that Monad Transformers are a terrible abstraction so I can see why he is skeptical

Ghost

@ghost~5c2a2354d73408ce4fb3431e

(I'm trying to translate https://hackage.haskell.org/package/fused-effects-0.1.2.1/docs/Control-Effect-Carrier.html#t:HFunctor )

Dale Wijnand

@dwijnand

Not http://hackage.haskell.org/package/category-extras-0.53.1/docs/Control-Functor-HigherOrder.html ?

Ghost

@ghost~5c2a2354d73408ce4fb3431e

trait HFunctor[H[_]] {
  def fmap_[M[_], A, B](f: A => B)(hma: H[M[A]]): H[M[B]]
}

maybe

Dale Wijnand

@dwijnand

alright, I get the gist

cool, thanks

Ghost

@ghost~5c2a2354d73408ce4fb3431e

so basically the kind of the A[_[_]] vs H[_] is the core thing here

Dale Wijnand

@dwijnand

mmhmm

Ghost

@ghost~5c2a2354d73408ce4fb3431e

because you can't cretae a HFunctor for some algebra like @SystemFw's MyDbAlg

it will have shape A[_[_]], e.g.

trait MyDbAlg[F[_]] { ... do stuff ...}

Fabio Labella

@SystemFw

I actually am more with Martin on this one, I think that Monad Transformers are a terrible abstraction so I can see why he is skeptical

@mdedetrich Thats' not what I meant: I meant that even though mtl style was born to solve a problem with transformers, it's very useful regardless, just like even though the Web was created to solve the problem of sharing scientific articles at CERN, it's now very useful regardless

Ghost

@ghost~5c2a2354d73408ce4fb3431e

hmm, I think HFunctor exists in scalaz as compose https://github.com/scalaz/scalaz/blob/series/7.3.x/core/src/main/scala/scalaz/Functor.scala#L62-L66

HFunctor would be useful if you have like a List[Option[Foo]] and you want to map Foo to Bar

Fabio Labella

@SystemFw

@fommil I don't think what you have above is HFunctor as commonly known

Ghost

@ghost~5c2a2354d73408ce4fb3431e

@SystemFw I just grabbed whatever came up first on Hoogle

what's the conventional one? All I know is that all the ones I found had the wrong kind

Fabio Labella

@SystemFw

mapK is the defining operation

mapT :: (Monad m, Monad n) => (forall a. m a -> n a) -> t m b -> t n b this is from the MFunctor lib (naming on this wildly varies)

like, the constraints might change

but taking a natural transformation as the mapping function is the key idea

Ghost

@ghost~5c2a2354d73408ce4fb3431e

I also looked into MFunctor, it's also a different kindedness

Fabio Labella

@SystemFw

t m b -> t n b

Ghost

@ghost~5c2a2354d73408ce4fb3431e

It is over (* -> *) -> * -> * if I recall

whereas FFunctor (or FunctorK in cats) is (* -> *) -> *

Matthew de Detrich

@mdedetrich

@SystemFw Sure thing, but then I would argue its overkill if you aren't solving that specific problem. You should use the simplest abstraction to solve your problem.

Fabio Labella

@SystemFw

@fommil ah, I see what you mean, that seems indeed to be Compose (Nested in cats) with a different kind, sorry

@mdedetrich agree to disagree :)

The benefit to complexity ratio of final tagless is excellent imho. But to each their own, no big deal

Where communities thrive

People

Repo info

Activity