Discord is now Scala’s main chat platform. Please join us at https://discord.com/invite/scala
@dsysme ever wondered whether nested ifs, nested if with "else error", nested loops and nested callbacks really have to be that ugly? well, if you split that up into a) the purely syntactic structure of the braces b) the specific effect (simple if, if ... else error, loop, callback), and c) the code in between where you do real stuff, you can simplify your code a lot: you can factor out the "specific effect" into a common interface, and then just reuse those. now guess how that interface is called...
("interface" in a very loose sense, you'd use one type per effect and a typeclass)
re: https://scala-lang.org/blog/2016/07/08/trait-method-performance.html#inlining
getting my feet wet with typeclass implicits. if I want the typeclass methods inlined, should I 1. add @inline to the trait virtual methods? 2. add @inline to typeclass instance methods? 3. add
getting my feet wet with typeclass implicits. if I want the typeclass methods inlined, should I 1. add @inline to the trait virtual methods? 2. add @inline to typeclass instance methods? 3. add
final to typeclass instance methods?
@SystemFw Currently reading FP in Scala. I also read most of Essential scala and part of FP simplified. I know most of the terms you mention here and frankly what frustrate me most is that most tutorials just drop on you tons on details before even giving you the motivation as to why and what is wrong with imperative style. By now I am starting to understand the motivation and what Monad is good for and I think this is where the explanation should start; in the why, not the what or how.
my point was more that one shouldn't conflate algebraic effects (representing computations as
F[A]) and monads
Monad is but one of the possible algebras we can introduce for them (albeit a powerful one)
I haven't read FP in Scala, but I can see my copy from where I'm sitting :) soon I hope
that's the mistake made in the third explanation in your list: everything said does not refer to monads, but to effects in general. (also, "impure things in a pure language" is wrong, everything is completely, 100% pure, monads or not).
The first explanation encoded monad as an interface and not a typeclass, and therefore it cannot have
The second explanation in the list is the least misleading, but it's too vague and probably only useful for those who already know the concept
The first explanation encoded monad as an interface and not a typeclass, and therefore it cannot have
unit, which means it can't be a monad (for both practical and theoretical reasons)The second explanation in the list is the least misleading, but it's too vague and probably only useful for those who already know the concept
@dsysme re. "motivation", did you read https://cdsmith.wordpress.com/2012/04/18/why-do-monads-matter/ ?
The "The Four Horsemen of the Catapocalypse" helped me alot understanding abit of the monad thing
like, there's three aspects here, which are related but independent
I loved the "Quick quiz: Do computer programmers use functions?" part
it helped me realise that we cannot apply the kind of algebra I remembered from school (applications, sets, groups, rings, fields) but needed an higher level of abstraction
and from there, objects, arrows are straightforward, then come the Functor... not saying it's trivial, but definitely helps :)
anyway, there's three aspects:
- what is referential transparency, and why it matters. This is key. It's the foundational principle of pure FP, where most of its advantages comes from, and everything else comes back to this.
- why do effects - representing computations with higher kinded types of shape
F[A](kind* -> *) - matter. This is the most neglected part, everyone's talking about "monads", in ways that generate lots of confusion. A good treatment of this helps you tremendously understanding the rest - why does Monad matter, as opposed to Functor, Applicative, Monoid, Arrow, and the other typeclasses. If you understand the first two points, explaining the extra power (and subsequent compositional limitations) that Monad has compared to other algebras is easy. The essence of what they give you.
also, we can apply the kind of algebra you refer to,
Monoid being an example
category theory can be useful to connect things, but it's not required to become an FP expert imho
it's not a bad explanation by any means
but I'm talking about things of shape
F[A] as a standalone entities, as well as their relationship with typeclasses/algebras, especially the fact that algebras describe part of their behaviour, but some things are specific to each concrete datatype <-- failure to understand this leads to the "how do I get this value out of IO" fallacy
the need is to have def isEffect(t: Type): Boolean = true if there is an Effect[t], at runtime
type class resolution is always compile time because that's how we resolve implicits, afaik
Nothing is stopping you to define a type class
Exists:trait Exists[A] { def apply(): Boolean }
object Exists extends Nope {
implicit def sure[A](implicit a: A): Exists[A] = new Exists[A] {
def apply() = true
}
}
trait Nope {
implicit def nope[A]: Exists[A] = new Exists[A] {
def apply() = false
}
}
then you can do
def isEffect[T](implicit isIt: Exists[Effect[T]]) = isIt()
they want it at runtime
it's the same
rho issue
when
rho only had Task
it's been asked by several people several times, and still no solution :(
this is for the implementation of swagger support in rho iirc (might be wrong here)
And that's actually the other way around: I have a value and I want to see if the typeclass resolves for its runtime type, which is of course impossible in general.
It's definitely a very very niche case