Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 19:57
    nevillelyh commented #8289
  • 19:47
    eed3si9n edited #8591
  • 19:28

    SethTisue on 2.13.x

    2.12: new Scala SHA 2.12: update expected-failure l… add akka-http-webgoat (#1017) and 1 more (compare)

  • 19:08

    SethTisue on 2.11.x

    sbt version bump (1.3.3->1.3.4)… 2.12: new Scala SHA 2.12: update expected-failure l… and 3 more (compare)

  • 19:04
    SethTisue commented #8545
  • 19:03
    som-snytt commented #11824
  • 18:54
    som-snytt labeled #11824
  • 18:54
    som-snytt commented #11824
  • 18:46
    som-snytt review_requested #8591
  • 18:46
    scala-jenkins milestoned #8591
  • 18:46
    som-snytt opened #8591
  • 18:38
    SethTisue milestoned #3237
  • 18:38
    SethTisue assigned #9386
  • 18:38
    SethTisue milestoned #9386
  • 15:21
    som-snytt commented #8590
  • 14:50
    lrytz commented #8588
  • 13:12

    lrytz on 2.13.x

    Avoid length of list Lint confusing by-name conversi… Lint by-name conversion of bloc… and 1 more (compare)

  • 13:12
    lrytz closed #8590
  • 13:12
    lrytz closed #9386
  • 13:12
    lrytz closed #3237
Sharon Shmorak
@dsysme
Hi everybody, I am a scala noobie fighting to understand functional programming and more specifically the concept of Monad. I am trying to keep records of all the explanations for what Monad is that I find on youtube lectures. [This is my very modest list so far ]
(https://docs.google.com/document/d/1jMlMFfaVBJEYr0mtzUl5RoIlBkeI_uoOYntIlUnry5M/edit?usp=sharing)
This is a link that allows editing, so everybody here are invited to contribute. I hope to make a video compilation from this list which I'll share here once done.
Fabio Labella
@SystemFw
@dsysme well, all three explanations in that list leave something to be desired imho (I could expand on why, but it'll likely only add more confusion). I would not obsess on monads from the start. I recommend studying FP from the ground up, which will lead you gently to the concept, and avoid the millions wrong explanations online. Have you read FP in Scala?
(Btw, if you think you are already at the point when you know the basics, I can help your understanding, either here or in a private message, but I do recommend learning things one by one, without Monad being the be-all end-all)
(in particular, higher order functions, typeclasses, simpler algebras like Monoid, higher kinded types, and something like Functor are prerequisites imho. That doesn't mean you need to learn them just to learn about monads, they are super useful in their own right!)
ritschwumm
@ritschwumm
@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)
Ryan Berckmans
@ryanberckmans
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 final to typeclass instance methods?
Sharon Shmorak
@dsysme
@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.
Ryan Berckmans
@ryanberckmans
using scala 2.12. Saw that a fix for inlining trait methods is now on by default in 2.12. scala/scala#4312
Fabio Labella
@SystemFw
@dsysme Yes, motivation is key. In particular understanding referential transparency and its consequences really is essential
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)
Ryan Berckmans
@ryanberckmans
I'd recommend http://haskellbook.com/
I haven't read FP in Scala, but I can see my copy from where I'm sitting :) soon I hope
Fabio Labella
@SystemFw
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 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
Arnaud Esteve
@aesteve
@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
Fabio Labella
@SystemFw
I'm talking about general motivation for FP, not just for Monads
like, there's three aspects here, which are related but independent
Arnaud Esteve
@aesteve
@SystemFw sorry Fabio, I was referring to @dsysme comment, especially the "most tutorials just drop on you tons on details before even giving you the motivation as to why"
Fabio Labella
@SystemFw
ah, sure :)
Arnaud Esteve
@aesteve
I enjoyed reading this article, for the monad part, yes, but also on "general motivation algebra stuff" (to be intentionnaly vague)
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 :)
Fabio Labella
@SystemFw
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
Arnaud Esteve
@aesteve
I agree :)
Arnaud Esteve
@aesteve
@SystemFw I think the "Four horsemen of the apocalypse" part of my link covers (or at least, gives motivation) about the "effects" part. Don't you think ?
Fabio Labella
@SystemFw
it does, but it's too hung up on kleisli arrows (since the kleisli category is its way of getting to monads)
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
ritschwumm
@ritschwumm
Saurabh Rawat
@eklavya
is it possible at runtime to determine if there is a type class instance for some type?
the need is to have def isEffect(t: Type): Boolean = true if there is an Effect[t], at runtime
Andi Miller
@andimiller
where would you get it from?
type class resolution is always compile time because that's how we resolve implicits, afaik
Georgi Krastev
@joroKr21
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()
Fabio Labella
@SystemFw
that's still at compile time though I think
they want it at runtime
it's the same rho issue
when rho only had Task
Andi Miller
@andimiller
rho should be able to do that at compile time
Fabio Labella
@SystemFw
you would take a type and tests at runtime if it was Task (with a TypeTag)
Andi Miller
@andimiller
I dunno why it'd need that
Fabio Labella
@SystemFw
now they need the same, but for a typeclass, and I'm not sure it's possible
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)
Georgi Krastev
@joroKr21
Well you could do it for a sealed trait with shapeless, but in general that's just a really weird thing to want