tomwhoiscontrary

import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.SynchronousQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicReference;
import java.util.function.Consumer;

KiaraGrouwstra

// NOTE: code now moved to https://github.com/tycho01/typical
// older revision left here, but it no longer runs well in TS Playground

export type Obj<T> = { [k: string]: T };
export type NumObj<T> = { [k: number]: T };
// export type List = ArrayLike; // no unapplied generic types :(
export type List<T> = ArrayLike<T>;
// progress: https://github.com/Microsoft/TypeScript/issues/16392

export function force<T, V extends T>() {}

OlivierBlanvillain

Revisiting Tagless Final Interpreters

Tageless Final interpreters are an alternative to the traditional Algebraic Data Type (and generalized ADT) based implementation of the interpreter pattern. This document presents the Tageless Final approach with Scala, and shows how Dotty with it's recently added implicits functions makes the approach even more appealing. All examples are direct translations of their Haskell version presented in the Typed Tagless Final Interpreters: Lecture Notes (section 2).

The interpreter pattern has recently received a lot of attention in the Scala community. A lot of efforts have been invested in trying to address the biggest shortcomings of ADT/GADT based solutions: extensibility. One can first look at cats' Inject typeclass for an implementation of [Data Type à la Carte](http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesA

densh

Scoped Implicit Lifetimes

All things considered, our experience in Scala Native has shown that resource management in Scala is way harder than it should be. This gist presents a simple design pattern that makes it resource management absolutely hassle-free: scoped implicit lifetimes.

The main idea behind it is to encode resource lifetimes through a concept of an implicit scope. Scopes are necessary to acquire resources. They are responsible for disposal of the resources once the evaluation exits the

garybernhardt

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

gcanti

export default class Eff<EA: Object, A> {
  run: () => A;
  constructor(run: () => A) {
    this.run = run
  }
  map<B>(f: (_: A) => B): Eff<EA, B> {
    return new Eff(() => f(this.run()))
  }
  chain<EB: Object, B>(f: (_: A) => Eff<EB, B>): Eff<EA & EB, B> {
    return Eff.join(this.map(f))

cube-drone

Automation for the People

Long ago, the first time I read "The Pragmatic Programmer", I read some advice that really stuck with me.

"Don't Use Manual Procedures".

This in the chapter on Ubiquitous Automation. To summarize, they want you to automate all the things.

The trouble was that I hadn't much of an idea how to actually go

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:

nh2

I believe the following is the best way to work with Nagle's algorithm / TCP_NODELAY / TCP_CORK.

It is described in this RedHat manual and the verdict is:

• Set TCP_NODELAY = 1, always.
• If you can batch data for sending by creating a buffer manually, or using writev(), prefer that.
• If you cannot (e.g. "when using different libraries that provides abstractions for layers" from the above manual):
  • Set TCP_CORK = 1, then write the data, then set TCP_CORK = 0.
• This builds a packet in kernel space and then flushes it out.