milessabin

// An ADT+shapeless as a drop-in replacement for a standard Scala Enumeration.
//
// First the unsafe standard Scala Enumeration ...
//
object ScalaEnumDemo extends App {
  // Example from scala.Enumeration scaladoc. Terse ...
  object WeekDay extends Enumeration {
    type WeekDay = Value
    val Mon, Tue, Wed, Thu, Fri, Sat, Sun = Value
  }

raichoo

{-# LANGUAGE PatternSynonyms #-}
module Polynomial where

import Prelude hiding (Maybe(..))

class Bifunctor f where
  bimap :: (a -> b) -> (c -> d) -> f a c -> f b d

instance Bifunctor (,) where
  bimap f g (x, y) = (f x, g y)

jroper

import scalaz.Reader

case class User(id: Int, name: String)
case class Interest(name: String)

trait Database

trait Attempt1 {
  // How every explanation of Reader monad I've seen/read goes:

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

oxbowlakes

scala> val it = Traversable(1); it foreach (i => println(s"$i and ${it.isEmpty}"))
1 and false

scala> val it = Iterator(1); it foreach (i => println(s"$i and ${it.isEmpty}"))
1 and true

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:
 */

travisbrown

// src/main/java/j/bar/Bar.java
package j.bar;

abstract class Foo {
  public abstract String value();
}

public class Bar {
  public static Foo makeFoo() {
    return new Foo() {

puffnfresh

sealed trait Caster[A, B]
case object CastTo extends Caster[Unit, Unit]
case class Ignored[A, B]() extends Caster[A, B]

def cast[A, B]: A =:= B =
  (Ignored(): Caster[A, B]) match {
    case CastTo | _ => implicitly[B =:= Unit]
  }

cast[String, Int]: String =:= Int

djspiewak

import shims.{Permute2, Permute3}
import scalaz._

object Scratch {

  trait Functor[F[_]] {
    def map[A, B](fa: F[A])(f: A => B): F[B]
  }

  object Functor {

milessabin

miles@frege:~$ ./shapeless.sh 
Loading...
Welcome to the Ammonite Repl 0.5.2
(Scala 2.11.7 Java 1.8.0_51)
@ val l = 23 :: "foo" :: true :: HNil
l: Int :: String :: Boolean :: HNil = ::(23, ::("foo", ::(true, HNil)))
@