scala/scala

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

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

Ghost

@ghost~5c2a2354d73408ce4fb3431e

@SystemFw oh, don't get me wrong, I think "final tagless" in Scala is the best way to build FP apps... nothing comes close. I just don't think the name is a benefit to the cause. To me it's "just" using higher kinded types.

Fabio Labella

@SystemFw

@fommil actually I take it back, the hmap operation has the same shape I linked mapK. But yeah you have the kind problem

Ghost

@ghost~5c2a2354d73408ce4fb3431e

yeah, I lost a few hours on that ...

Fabio Labella

@SystemFw

@fommil well, when yesterday I told my colleague "write this BigQuery dsl in final tagless instead, and when [business thing] happens we will be able to easily extend", no higher kinds were involved, and the name brought value :)

Ghost

@ghost~5c2a2354d73408ce4fb3431e

@SystemFw pro tip Data.Composition is an excellent resource for implementing FFunctor instances....

heh, well so long as it works... then who cares about the name

Fabio Labella

@SystemFw

:+1: I'll have a look

Peter Aaser

@PeterAaser

Hai @fommil , how's haskell treating you?

And how's the kid?

Ghost

@ghost~54f837fe15522ed4b3dcd6a3

@ipergenitsa Yes, makes sense. But in which cases is it usually useful to use t.Typename?

Li Haoyi

@lihaoyi

i don't quite grok what it means to say encoding languages as their interpreters. e.g. Scalatags uses parametrization over F[_] to render to either Strings, js.Elements, or React VDom snippets. You compose a bunch of methods that return F[T], it returns a bigger F[T], and it looks just like any example of finally tagless that i've ever seen. Is Scalatags then finally tagless?

(it's parametrized over F[_] because it has different sets of tags, e.g. the tags from scalatags.Text.TypedTag[T] or scalatags.JsDom.TypedTag[T], and each tag is typed with the value returned when you render it)

Where communities thrive

People

Repo info

Activity