How do i interpret this long confusing sequence of code?

[Lai Boon Hui]

sealed trait Either[+E, +A] {

  def map[B](f:A=>B): Either[E,B] = this match {

    case Right(a) => Right(f(a))

    case Left(e) => Left(e)

  }

  def flatMap[EE >: E, B](f: A => Either[EE, B]): Either[EE, B] =

    this match {

      case Right(a) => f(a)

      case Left(e)  => Left(e)

    }

  def orElse[EE >: E, B >: A](b: => Either[EE,B]): Either[EE, B] =

    this match {

      case Right(a) => Right(a)

      case Left(e) => b

    }

  def map2[EE >: E, B, C](b: Either[EE,B])(f:(A,B)=>C): Either[EE,C] = 

    a flatMap (aa =>

    b map (bb =>

    f(aa, bb)))

}

case class Left[+E](value: E) extends Either[E, Nothing]

case class Right[+A](value: A) extends Either[Nothing, A]

Can someone explain to me how this long sequence of code can be broken down and understood ?

Thanks in advance.

[scala solist]

a flatMap (aa =>

   b map (bb =>

   f(aa, bb)))

it is simply a desugared code

for {
  aa <- a
  bb <- b
} yield f(aa,bb)

[Russ P.]

The "desugared" form is certainly far less readable to me, and I'll bet it is for most other programmers as well. In fact, if someone put the "desugared" form in production code, I'd say they should be reprimanded for wasting valuable code review time to decipher it.

While we're at it, can we find better terminology than "sugared" and "desugared." To me, those terms imply superficiality, and I don't think making code readable is ever superficial.

[Lanny Ripple]

Well Syntactic_sugar is exactly the term to use for this.  I'm not sure where superficiality crept in as part of the meaning.  As long as I've been hearing the term (early 80s maybe.  Definitely by '86 when I started my degree) it's just meant a simpler/easier syntax to aid some complex construction.

I'd hate for you to be reprimanded, Russ, for adding cognitive burden when discussing programming by having people decipher some new term.  :)

[Gabriel Claramunt]

Is just a matter of familiarity and the code style used in your organization. I like the desugared version because is explicit about what's been called, one advantage of the "for" version is that is similar to what one will write in imperative code, but the name can be deceiving  for newcomers as it doesn't really represent a loop

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Gabriel Claramunt

[Oliver Ruebenacker]

     Hello,

  Is "for" a loop? I would say, sometimes it is:

scala> for(i <- 1 to 10) { println(i) }
1
2
3
4
5
6
7
8
9
10

  and sometimes, it is not:

scala> for(i <- (1 to 10).par) { println(i) }
8
3
9
1
6
7
2
10
4
5

     Best, Oliver

Oliver Ruebenacker

Senior Software Engineer, Diabetes Portal, Broad Institute

[Russ Paielli]

When I hear the term "syntactic sugar," I think of children's breakfast cereals with a high sugar content. The sugar provides little or no nutritional value. It's just a superficial additive to get kids to eat the cereal (and pester their parents to buy it). By analogy, the term "syntactic sugar" implies to me a way to make code more palatable to simple-minded developers.

However, the jargon is not my main concern here. The main issue is readability. The "sugared" form is much simpler and clearer to me. But I am not primarily a software developer. I am an aeronautical engineer who writes software to develop, test, and document concepts and algorithms for air traffic control. The "document" part is key. If I use the "desugared" form, anyone reads my code will have to spend extra time and effort to figure out that one loop is simply distributing over the other or others. That distracts and occupies them unnecessarily, leaving them less time and mental capacity to understand the algorithms and concepts that the code implements.

In an ideal world, everyone would be a Scala expert and would be able to easily understand the "desugared" form, but the world is not ideal, and not everyone can be an expert at everything. If the "desugared" form is clear to you, then good for you. You may be a master software developer. But your code may not be as clear to other software developers as it could be, and that makes code maintenance more difficult. More importantly, your code may not be as clear as it could be to subject matter experts who need to understand the concepts behind the code.

--
You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/HYDInahSPyw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-user+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://RussP.us

[Lanny Ripple]

As with you I'm a big fan of sugar because it lowers the cognitive burden of thinking about code.  I find it easy to think of every DSL as this sweet stuff we're talking about and Scala is chocked full of extra spoonfuls.  Term of art is often confusing (or childish) but it's almost certainly got more staying power than we do.