talebzeghmi

import scala.language.higherKinds
import scala.reflect.ClassTag
import scala.language.implicitConversions

trait Data[D[_]] extends Serializable {

  def map[A, B: ClassTag](d: D[A])(f: A => B): D[B]

  def flatMap[A, B: ClassTag](d: D[A])(f: A => Iterable[B]): D[B]

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

rponte

# The command finds the most recent tag that is reachable from a commit.
# If the tag points to the commit, then only the tag is shown.
# Otherwise, it suffixes the tag name with the number of additional commits on top of the tagged object 
# and the abbreviated object name of the most recent commit.
git describe

# With --abbrev set to 0, the command can be used to find the closest tagname without any suffix:
git describe --abbrev=0

# other examples

fancellu

// Just run this inside the spark shell, no more chatty logs

import org.apache.log4j.Logger
import org.apache.log4j.Level

Logger.getLogger("org").setLevel(Level.OFF)
Logger.getLogger("akka").setLevel(Level.OFF)

manjuraj

//
// Apply extends the Functor Typeclass by adding a method `ap` which
// is similar to `map` from Functor in that it takes a functor that
// that has a function in it and another functor and extracts that
// function from the first functor and then maps it over the second
// one
//
// Alternatively, you can say `ap` lets you apply a function in a
// context to a value in a context
//

manjuraj

//
// Validation[E, A] represents either:
// - Success[A]
// - Failure[E]
//
// Isomporphic to scala.Either[E, A] and scalaz.\/[E, A]
//
// Unlike \/[E, A], Validation is not a Monad, but an Applicative
// Functor. So if you want to use it as a Monad you can convert back
// and forth using the `validation` and `disjunction` method

manjuraj

//
// Disjunction - aka Scalaz Either
// \/[A, B] is an alternative to Either[A, B]
// -\/ is Left  (usually represents failure by convention)
// \/- is Right (usually represents success by convention)
// Left or Right - which side of the Disjunction does the "-" appear?
//
// Prefer infix notation to express Disjunction Type v: String \/ Double
//
// References

betehess

> runMain ammonite.repl.Repl
[info] Running ammonite.repl.Repl
Loading Ammonite Repl...

@ load.ivy("com.chuusai" %% "shapeless" % "2.1.0")

@ import shapeless._
import shapeless._

@ 1 :: "lol" :: List(1, 2, 3) :: HNil

travisbrown

import scala.language.experimental.macros
import scala.reflect.macros.whitebox

class FreeMacros(val c: whitebox.Context) {
  import c.universe._

  def smartName(name: String): String = (
    name.toList match {
      case h :: t => h.toLower :: t
      case Nil => Nil

manjuraj

//
// Foldable
// - fold a data structure
// - usually, fold F[A] given a Monoid[A]
//

trait Foldable[F[_]]  { self =>
  def foldRight[A, B](fa: F[A], z: => B)(f: (A, => B) => B): B

  def foldLeft[A, B](fa: F[A], z: B)(f: (B, A) => B): B = {