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

Ideas on generics in Go

As we all know, Go 2 is on its way and despite the hesitations, it's clear that without generics, it would end up being a disappointment. And although we are still gathering real-life use-cases, or experience reports, there's nothing bad about starting to think about how generics in Go could look like. I've come up with a few ideas which I'd love to share. So, here we go!

What's already achievable?

Now, Go 1 has no generics, but has interfaces. Interfaces (sometime accompanied by reflection)

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

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

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 =