A relaxed chat room about all things Scala. Beginner questions welcome. http://scala-lang.org/conduct/ applies
what's the conventional one? All I know is that all the ones I found had the wrong kind
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
whereas
FFunctor (or FunctorK in cats) is (* -> *) -> *
@mdedetrich agree to disagree :)
The benefit to complexity ratio of final tagless is excellent imho. But to each their own, no big deal
heh, well so long as it works... then who cares about the name
And how's the kid?
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)
from your description scalatags is final tagless btw, it's just a matter of seeing what I mean
ok let's use the classical example of literals and addition
when asked to implement it, 98% percent of people will go for something like (with either pattern matching or OO dispatch, it doesn't matter)
sealed trait Op
case class Lit(i : Int) extends Op
case class Add(a: Op, b: Op) extends Op
programs are then datatypes of type
Op
Add(Lit(1), Add(Lit(2), Lit(3))
so there is a separation between interpreter and language
note some of the consequences:
- you need to deal with recursion
- you create an intermediate structure
- hard to compose multiple language since datatypes aren't open (and if they were you'd lose exhaustiveness), so you need to rely on coproduct injections
- and so on
well
you need an interpreter for Lits, and an interpreter for Adds
and then you need a way of representing the result
let's say the result is
A for now
you need
def lit(i: Int): A
def add(a: A, b: A): A
so, these are the interpreters for your language, how does the actual language look like?
well, we can say that the interpreter is the language (this is the same idea behind church encodings)
trait Op {
def lit(i: Int): A
def add(a: A, b: A): A
}
but what is
A?
well that's the second idea: you just use a type param
trait Op[A] {
def lit(i : Int): A
def add(a: A, b: A): A
}