Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Anthony Michaelson
    @anthonymichaelson_gitlab
    RE: Bridges; is that library currently being utilized in any SBT plugins to watch source files and output to the desired target languages (typescript, elm, flow)?
    Harit Himanshu
    @hhimanshu

    Hello there, I am reading the build.sbt for Scala and looking at code like

    publishArtifact in (Compile, packageDoc)

    and

    packageOptions in Compile in packageSrc

    Do they both mean the same things as I read code? That is Compile:packageDoc::publishArtifact and Compile:packageSrc::packageOptions?

    Sachin Kukreja
    @sk364
    Hello.
    Can anyone help me to understand why there is a limit of 22 elements for a tuple?
    Abhishek Srivastava
    @abhishes_twitter
    nafg
    @nafg
    @sk364 the reason why is that each size tuple is hard coded as a case class in the standard library
    When you write (1, "2", true) it's really syntactic sugar for scala.Tuple3[Int, String, Boolean](1, "2", true)
    That's how scala implements tuples currently, but in the next major version tuples are instead done more like a singly-linked list at the type level (currently it's more analogous to a flat array)
    Sachin Kukreja
    @sk364
    Thanks. And that's awesome that it's getting dropped.
    Though, I am trying to understand why the number "22" is the limit?
    Noel Welsh
    @noelwelsh
    22 is just an arbitrary number that was considered big enough.
    More recent versions of Scala drop that limit IIRC.
    nafg
    @nafg
    I think you're thinking of case classes
    The tuple limit is only dropped in dotty
    Noel Welsh
    @noelwelsh
    Gotcha
    Sachin Kukreja
    @sk364
    I was just wondering, if there was some logical analysis behind choosing the number 22, which I am unable to see.
    I am guessing the architecture of the tuples is such that more than 22 elements is too much memory?
    Fabio Labella
    @SystemFw
    no, it's arbitrary
    the way tuples and functions are encoded are with a bunch traits, Tuple1, Tuple2... and so on
    謝宇恆
    @xieyuheng
    22 is the secret seed for the finial answer, 22 + 22 - 2 = 42
    Noel Welsh
    @noelwelsh
    :boom:
    Shouvik Roy
    @royshouvik
    Just wanted to drop by and thank the authors and everyone behind the Creative Scala book. I am really enjoying the book :clap:
    Visar Zejnullahu
    @visar
    Hi guys
    I'm doing Excercise 4.1.4.3 from Essential Scala
    case class Square(size: Double) extends Rectangular {
      val height: Double = size
      val width: Double = size
    }
    trait Rectangular extends Shape {
      def height: Double
      def width: Double
      val sides: Int = 4
      override val perimeter: Double = 2 * (height + width)
      override val area: Double = height * width
    }
    trait Shape {
      def sides: Int
      def perimeter: Double
      def area: Double
    }
    and in my Main I have this
     val square = Square(4)
    
      println(square.height)
      println(square.width)
      println(square.size)
      println(square.area)
      println(square.perimeter)
      println(square.sides)
    but I'm getting the following results
    4.0
    4.0
    4.0
    0.0
    0.0
    4
    I tried debugging
    Visar Zejnullahu
    @visar
    and I can see that perimeter and area are set to 0
    Any idea why?
    SuprF1y
    @SuprF1y

    perimeter and area should be defined with def as methods rather than as vals

      override def perimeter: Double = 2 * (height + width)
      override def area: Double = height * width

    Another way to do it is declare them lazy. Then they will only be initialised upon first use

     override lazy val perimeter: Double = 2 * (height + width)
     override lazy val area: Double = height * width

    Due to the immutability of the traits and classes, they will always be the correct value as neither height nor width will be subsequently updated.

    Marjan Mubarok
    @MarjanMubarok
    Hello, I plan on doing a presentation on the different ways Scala supports concurrency. Does anyone know of any good books on the topic?
    Charis Loveland
    @charislove
    Hi, here are some edits for the Atom install documentation. Thank you very much for the hard work on this! At https://www.creativescala.org/creative-scala.html#installing-terminal-software-and-a-text-editors, change "Install Scala support inside Atom: Settings > Install > language-scala" to the following: "Go to atom.io and download and install the Atom text editor. Open Atom and go to the Settings tab. Then click on "+ Install" and type "language-scala" and install."
    Noel Welsh
    @noelwelsh
    Thanks @charislove !
    georgreen
    @georgreen

    Works

    sealed trait Sum[+A, +B] {
      def flatMap[AA >: A, C](f: B => Sum[AA, C]): Sum[AA, C] =
        this match {
          case Failure(v) => Failure(v)
          case Success(v) => f(v)
        }
    }
    final case class Failure[A](value: A) extends Sum[A, Nothing]
    final case class Success[B](value: B) extends Sum[Nothing, B]

    Doesn't Work

    sealed trait Sum[+A, +B] {
      def flatMap[C](f: B => Sum[A, C]): Sum[A, C] =
        this match {
          case Failure(v) => Failure(v)
          case Success(v) => f(v)
        }
    }
    final case class Failure[A](value: A) extends Sum[A, Nothing]
    final case class Success[B](value: B) extends Sum[Nothing, B]

    I don't get it. If I take f: B => Sum[A, C] and construct it from trait Function1[-I, +O]{ def apply(i: I): O} it seems B is the contravariant argument while Sum[A, C] is the covariant term in this function. How does it end up that A is the contravariant term also, what does this mean 👇 ?

    "It is declared with type B => Sum[A, C] and thus a supertype is covariant in B and contravariant in A and C."

    I expected it to be B is the contraviant term, why? it's the argument to function f,meaning it's B that has to be type bounded not A and Sum[A, C] to be covariant why? it's the result type of f. But I'm clearly wrong, what I'm I missing here?

    I didn't really get the argument for contravariant terms in a function why supertypes?

    Source:

    "Back to flatMap, the function f is a parameter, and thus in a contravariant position. This means we accept supertypes of f. It is declared with type B => Sum[A, C] and thus a supertype is covariant in B and contravariant in A and C. B is declared as covariant, so that is fine. C is invariant, so that is fine as well. A on the other hand is covariant but in a contravariant position. Thus we have to apply the same solution we did for Box above."

    Excerpt From: Noel Welsh and Dave Gurnell. “Essential Scala”.

    Fabio Labella
    @SystemFw
    I don't really have time for a full explanation, but you can look up "negative and positive position"
    basically when you nest functions, things switch from positive to negative to positive to negative (and so does their variance)
    in this case: flatMap takes f that returns Sum
    georgreen
    @georgreen
    @SystemFw, thank you.
    Fabio Labella
    @SystemFw

    f: B => Sum[A, C] and construct it from trait Function1[-I, +O]{ def apply(i: I): O} it seems B is the contravariant argument while Sum[A, C] is the covariant term in this function

    Right, but now if you write flatMap you f is in turn in negative position, so all the variances switch

    anyway, I would fully agree it's very confusing
    this is tl;dr
    Positive position: the type variable is the result/output/range/codomain of the function
    Negative position: the type variable is the argument/input/domain of the function
    When a type variable appears in positive position, the data type is covariant with that variable. 
    When the variable appears in negative position, the data type is contravariant with that variable.
    so if you apply these rules and try to work the type of flatMap out, it should all fit
    in f, Sum is in positive position (return type)
    flatMap is a function that takes f, so all of f is in negative position, which makes B have positive position and Sum have negative position
    which makes it contravariant
    the least crap intuition is multiplying numbers by 1 and -1, they keep switching. Roughly speaking, functions of functions is the multiplication