travisbrown

// Given the following ADT:

sealed trait Status
case object One extends Status
case object Two extends Status
case object Three extends Status

// They represent states. The natural progression, for this
// example, is : One -> Two -> Three

cvogt

scala> def foo = { val x = Map[Any,Any](() -> ()).mapValues(_ => ???); () }
foo: Unit

scala> foo

scala> def foo = { val x = Map[Any,Any](() -> ()).map(_ => ???); () }
foo: Unit

scala> foo
scala.NotImplementedError: an implementation is missing

djspiewak

Collections Redesign Proposal

I'm going to start off by motivating what I'm doing here. And I want to be clear that I'm not "dissing" the existing collections implementation or anything as unproductively negative as that. It was a really good experiment, it was a huge step forward given what we knew back in 2.8, but now it's time to learn from that experiment and do better. This proposal uses what I believe are the lessons we can learn about what worked, what didn't work, and what is and isn't important about collections in Scala.

This is going to start out sounding really negative and pervasively dismissive, but bear with me! There's a point to all my ranting. I want to be really clear about my motivations for the proposal being the way that it is.

Problems

Generic Interfaces

djspiewak

Explaining Miles's Magic

Miles Sabin recently opened a pull request fixing the infamous SI-2712. First off, this is remarkable and, if merged, will make everyone's life enormously easier. This is a bug that a lot of people hit often without even realizing it, and they just assume that either they did something wrong or the compiler is broken in some weird way. It is especially common for users of scalaz or cats.

But that's not what I wanted to write about. What I want to write about is the exact semantics of Miles's fix, because it does impose some very specific assumptions about the way that type constructors work, and understanding those assumptions is the key to getting the most of it his fix.

For starters, here is the sort of thing that SI-2712 affects:

def foo[F[_], A](fa: F[A]): String = fa.toString

dwijnand

package p

/** Decodes strings into Ts */
trait Decoder[T] {
  def decode(s: String): Either[String, T]
}

object Decoder {
  def apply[T](f: String => Either[String, T]): Decoder[T] =
    new Decoder[T] { def decode(s: String) = f(s) }

alexandru

import org.joda.time._
import monix.execution._
import monix.execution.Scheduler.Implicits.global
import java.util.concurrent.TimeUnit
import scala.util.control.NonFatal

def scheduleOncePerDay(time: LocalTime, now: DateTime = DateTime.now())(cb: () => Unit)
  (implicit s: Scheduler): Cancelable = {
    
  val nextTick = {

djspiewak

Thread Pools

Thread pools on the JVM should usually be divided into the following three categories:

1. CPU-bound
2. Blocking IO
3. Non-blocking IO polling

Each of these categories has a different optimal configuration and usage pattern.