aaronlevin

{-# LANGUAGE OverloadedStrings #-}

module Main where

import Network.Wai (pathInfo, Request, requestMethod, Response, responseLBS, ResponseReceived)
import Network.Wai.Handler.Warp (run)
import Network.HTTP.Types (status200, status401)

-- note: type Application = Request -> (Response -> IO ResponseReceived) -> IO ResponseReceived
application :: Request -> (Response -> IO ResponseReceived) -> IO ResponseReceived

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

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:

SethTisue

Scalawags #38: The Sound of Dotty

YouTube link: https://www.youtube.com/watch?v=e687bFp2FT4

Our guest is Martin Odersky, the creator of Scala. We invited him on specifically to discuss Dotty, a new compiler for Scala.

Your hosts this episode: Josh Suereth,

salomvary

import java.time.{Instant, ZonedDateTime}
import play.api.libs.json._
import scala.util.control.NonFatal


/**
 * PlayJson Basics
 */

// See type hierarchy (^H) of:

runarorama

trait λ {
  type α
}

trait Functor extends λ {
  type α <: λ

  def map[A,B](x: α { type α = A })(f: A => B): α { type α = B }
}

milessabin

object Demo {
  // A couple of type classes with type members ...
  trait Foo[T] {
    type A
  }

  object Foo {
    implicit val fooIS = new Foo[Int] { type A = String }
  }

xeno-by

// PROBLEM STATEMENT

// Let's build Proxy[T], an object that can capture calls to methods of an underlying object.
// We want the proxy to be type-safe, i.e. we need to verify that the names of the calls
// and the arguments that are passed to those calls are well-typed wrt the type of the proxee.

object Test extends App {
  trait Foo { /* ... */ }
  val proxy: Proxy[Foo] = ???
  proxy.bar()

negator

    
    
    /**
      The Play (2.3) json combinator library is arguably the best in the scala world. However it doesnt
      work with case classes with greater than 22 fields.
      The following gist leverages the shapeless 'Automatic Typeclass Derivation' facility to work around this
      limitation. Simply stick it in a common location in your code base, and use like so:
      Note: ** Requires Play 2.3 and shapeless 2.0.0  
      
  

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]