Please view the deleted tweet list in our main archive.
#replace "<PAT TOKEN>" with your github PAT token, tested with "Update ALL user data" PAT token. | |
curl -q https://rms-support-letter.github.io/ | grep "href" | grep "github.com" | grep -v "\/\[" | awk -F "https://github.com/" '{ print $2 }' | awk -F "\"\>" '{ print $1 }' | sed 's/\///g' | sed '/^$/d' | xargs -I USER curl -i -X PUT -H "Authorization: token <pat token here>" -H "Accept: application/vnd.github.v3+json" https://api.github.com/user/blocks/USER |
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.
Let's quote the Scala spec for As Seen From (ASF) rules numbered for an easier reference:
This document is about Task
, an alternative for Scalaz's Task
or Scala's Future
.
Note this is work in progress and this document suffered multiple modifications already:
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
import shapeless._ | |
import ops.record.{ Selector, Updater } | |
import record.{ FieldType, field } | |
trait PathLens[T, P] { | |
type Elem | |
def get(t : T) : Elem | |
def set(t : T)(e : Elem) : T | |
} |
case class Foo[T](x: T) { | |
def map[B](f: T => B) = Foo(f(x)) | |
} | |
object OldWay { | |
def combineLatest[T1, T2](e1: Foo[T1], e2: Foo[T2]): Foo[(T1, T2)] = Foo((e1.x, e2.x)) | |
def combineLatest[T1, T2, T3](e1: Foo[T1], e2: Foo[T2], e3: Foo[T3]): Foo[(T1, T2, T3)] = | |
combineLatest(combineLatest(e1, e2), e3) map { |
import shapeless._ | |
import record._ | |
import syntax.singleton._ | |
object ScaldingPoC extends App { | |
// map, flatMap | |
val birds = | |
List( | |
"name" ->> "Swallow (European, unladen)" :: "speed" ->> 23 :: "weightLb" ->> 0.2 :: "heightFt" ->> 0.65 :: HNil, |
def ackermann(m: Int, n: Int): Int = { | |
(m, n) match { | |
case (0, _) ⇒ n + 1 | |
case (m, 0) if m > 0 ⇒ ackermann(m - 1, 1) | |
case (m, n) if m > 0 && n > 0 ⇒ ackermann(m - 1, ackermann(m, n - 1)) | |
} | |
} | |
import scalaz._, Scalaz._, Free.{suspend ⇒ _, _}, Trampoline._ | |
def ackermannTramp(m: Int, n: Int): Trampoline[Int] = { |
scala> import shapeless._; import SingletonTypes._; import Record._ | |
import shapeless._ | |
import SingletonTypes._ | |
import Record._ | |
scala> val r = ("foo" ->> 23) :: ("bar" ->> true) :: ("baz" ->> 2.0) :: HNil | |
r: (String("foo"), Int) :: (String("bar"), Boolean) :: (String("baz"), Double) :: HNil = | |
(foo,23) :: (bar,true) :: (baz,2.0) :: HNil | |
scala> r.head // r is an HList of pairs of singleton-typed Strings and values ... |