faiface

pub trait Proc: 'static {
    type Then<P: Proc>: Proc;
    type Dual: Proc;

    fn extend(this: Self) -> Self::Then<Noop>;
    fn map<P: Proc, Q: Proc>(this: Self::Then<P>, f: impl 'static + FnOnce(P) -> Q) -> Self::Then<Q>;
    fn apply<P: Proc>(src: Self::Dual, dst: Self::Then<P>) -> P;

    fn then_assc<P: Proc, Q: Proc>(this: Self::Then<P::Then<Q>>) -> <Self::Then<P> as Proc>::Then<Q>;
    fn dual_dist<P: Proc>(this: <Self::Dual as Proc>::Then<P::Dual>) -> <Self::Then<P> as Proc>::Dual;

faiface

use std::collections::HashMap;

#[derive(Default, Debug)]
struct Dir {
    name_and_parent: Option<(String, Box<Dir>)>,
    files: HashMap<String, usize>,
    subdirs: HashMap<String, Box<Dir>>,
    total_size: usize,
}

faiface

(events Left Right Up Down Tick)

(define interpolate
  (lambda (dynamic)
    (begin [^] (value (@ dynamic))
      (or
        (after [Tick] (@ dynamic))
        (after [^]    value)))))

(define direction

faiface

// I have to create a custom type because the undesired behavior
// only occurs if I use a custom type for the parsing result. If
// I tried with something like bool, I get my custom error returned
// back just as I want it. Very strange.
pub enum MyUnit { Only }

// Now this parser returns "found end of input" if the input is not
// equal to "only". But a custom error is generated and wanted to be
// returned instead.
pub fn example() -> impl Parser<char, MyUnit, Error = Simple<char>> {

faiface

use std::collections::{BTreeMap, BTreeSet};


#[derive(Debug, Clone)]
struct DFA<State, Action> {
    initial: State,
    accepting: BTreeSet<State>,
    transition: BTreeMap<State, BTreeMap<Action, State>>,
}

faiface

use std::collections::{BTreeMap, BTreeSet};


#[derive(Debug)]
struct DFA<State, Action> {
    initial: State,
    accepting: BTreeSet<State>,
    transition: BTreeMap<State, BTreeMap<Action, State>>,
}

faiface

from fractions import Fraction
from copy import deepcopy

def places():
    for r in range(1, 8+1):
        for c in range(1, 8+1):
            yield (r, c)

def neighbors(b1, b2):
    r1, c1 = b1

faiface

Go 2 generics counterproposal: giving up restricting types

"I want to make a generic function which works on any type that satisfies these and these constraints."

When we think about generics, this is the sort of problem that pops up into our minds. The critical part is restricting the set of types our function intends to work on. Trying to solve this problem of restriction has led people to what I call reasons why we hesitate to have generics in Go.

C++ templates with horrific error messages, or even it's new concepts, Java's T extends Comparable<T>, Rust's generic traits, Haskell's type classes, and sadly even contracts from the [original generics proposal by the Go Team](https://go.googlesource.com/proposal/+/master/desig

faiface

record Rat =
    nom : Int,
    den : Int,

func gcd : Int -> Int -> Int =
    \a \b
    if (zero? b) a;
    gcd b (a % b)

func norm : Rat -> Rat =

faiface

Problem: the "context" package

More than a year ago, I wrote a blog post titled Context Should Go Away For Go 2 which received a fair amount of support and response. In said blog post, I described reasons why the "context" package is a bad idea because it's too infectious.

As explained in the blog post, the reason why "context" spreads so much and in such an unhealthy fashion is because it solves the problem of cancellation of long-running procedures.

I promised to follow the blog post (which only complained about the problem) with a solution. Considering the recent progress around Go 2, I decided it's the right time to do the follow up now. So, here it is!

Solution: bake cancellation into Go 2