travisbrown

/**
* Type-level Tower of Hanoi
* by Travis Brown
*
* Note: not optimal, and probably won't work for some valid inputs.
* Tested with Scala 2.9.2 and Shapeless 1.2.3.
*/

import shapeless._, Nat._

michaelfeathers

def complexity filename
  File.read(filename).lines.grep(/^([ \t]*)/) { $1 }.map(&:length).reduce(0, :+)
end

filenames = `git log --name-only | grep \.rb$`.lines \
                                              .map(&:strip) \
                                              .reject { |fn| fn.include? "_spec" } \
                                              .reject { |fn| fn.include? "vendor" }

runarorama

sealed trait Interact[A]

case class Ask(prompt: String)
  extends Interact[String]

case class Tell(msg: String)
  extends Interact[Unit]

trait Monad[M[_]] {
  def pure[A](a: A): M[A]

djspiewak

Introduction to scalaz-stream

Every application ever written can be viewed as some sort of transformation on data. Data can come from different sources, such as a network or a file or user input or the Large Hadron Collider. It can come from many sources all at once to be merged and aggregated in interesting ways, and it can be produced into many different output sinks, such as a network or files or graphical user interfaces. You might produce your output all at once, as a big data dump at the end of the world (right before your program shuts down), or you might produce it more incrementally. Every application fits into this model.

The scalaz-stream project is an attempt to make it easy to construct, test and scale programs that fit within this model (which is to say, everything). It does this by providing an abstraction around a "stream" of data, which is really just this notion of some number of data being sequentially pulled out of some unspecified data source. On top of this abstraction, sca

etorreborre

The Category Theoretic Understanding of Universal Algebra: Lawvere Theories andMonads: 
  - http://www.pps.univ-paris-diderot.fr/~mellies/mpri/mpri-ens/articles/hyland-power-lawvere-theories-and-monads.pdf
  - interesting for the historical part on how both concepts were developed 
  
Just do it: simple monadic equational reasoning
  - http://www.cs.ox.ac.uk/jeremy.gibbons/publications/mr.pdf
  - laws for effects

Lawvere theories made a bit easier
  - http://blog.sigfpe.com/2012/02/lawvere-theories-made-bit-easier.html

djspiewak

// let's imagine you have an algebra that has a constructor like the following
sealed trait Algebra[A]
case class Ext[E, A](e: E, f: E => A) extends Algebra[A]

/*
 * Not at all an uncommon pattern!  Basically, this is going to show up any time you're
 * doing GADTs or GADT-like things, or any sort of type-aligned sequence (in any form).
 * The problem is that the pattern matcher affixes types in a linear fashion, and thus
 * will not unify the solution to E between the two parameters.  For example:
 */

davegurnell

Introduction / Motivation
Curriculum---what you teach
 - How to present Scala (OO, functional)
 - Design patterns
Pedagogy---how you teach it
Technology to support teaching
Examples to motivate different students
Who Can Support It / Develop It
Why Invest in Learning Scala?

cranst0n

package freedom

import java.awt.{ Color, Graphics2D }
import java.awt.image.BufferedImage

import cats.data.Coproduct
import cats.free.{ Free, Inject }
import cats.{ ~>, Id }

pathikrit

trait NotSubTypeOf[A, B] // encoding to capture A is not a subtype of B
// Note: We can use infix notation to write `A NotSubTypeOf B` instead of `NotSubTypeOf[A, B]`

// evidence for any two arbitrary types A and B, A is not a subtype of B
implicit def isSub[A, B]: A NotSubTypeOf B = null

// define ambigous implicits to trigger compile error in case A is a subtype of B (or A =:= B)
implicit def iSubAmbig1[A, B >: A]: A NotSubTypeOf B = null
implicit def iSubAmbig2[A, B >: A]: A NotSubTypeOf B = null

gkossakowski

Scala's "type T in class C as seen from a prefix type S" with examples

Introduction

Recently, I found myself in need to precisely understand Scala's core typechecking rules. I was particulary interested in understanding rules responsible for typechecking signatures of members defined in classes (and all types derived from them). Scala Language Specification (SLS) contains definition of the rules but lacks any examples. The definition of the rules uses mutual recursion and nested switch-like constructs that make it hard to follow. I've written down examples together with explanation how specific set of rules (grouped thematically) is applied. These notes helped me gain confidence that I fully understand Scala's core typechecking algorithm.

As Seen From

Let's quote the Scala spec for As Seen From (ASF) rules numbered for an easier reference: