Conversation

Oh neat! I'm currently making a dependently typed data description language at - the intension is to describe existing binary data formats, but that is a big challenge, hehe. Trying to chip away at it. I really like the sound of this!
1
5
> we got bogged down in the type checker. haaaa! The struggle! I'm implementing it directly in Rust, but it often feels cumbersome and slow. I do wonder if I would have been better served making more prototypes.
2
1
yeah the challenge is basically that most of the people who understand dependent type checkers are mathematicians rather than programmers. so all the explanations of it are, um, abstract.
3
4
and there’s so tragically little holistic discussion of how e.g. unification fits into a bidirectional typechecker, and why you might want it to, and how much of a pain in the ass the lang can be to use without it, and how nightmarish a thing it is to self-teach
2
6
Agreed. Fortunately we understand unification, but there's really no on-ramp for anyone from a computer science background to learn about it easily.
1
1
I got blind-sided by understanding first-order unification, and not really understanding the distinction until it was too late. I’ve lost three languages to this problem thus far.
2
4
What should I be on the lookout for to avoid this fate? And what is the distinction that you missed - was it between first order unification and higher order unification?
1
So e.g.: const : a -> b -> a const a _ = a is implicitly quantifying over the types a and b. writing {…} for implicit bits, and ? for the bits we don’t know syntactically, we get: const : {a : ?} -> {b : ?} -> a -> b -> a const {_} {_} a _ = a
1
10
similarly, when we use const, we might write: f : a -> [b] -> [a] f x ys = map (const x) ys even assuming map is specialized to lists, there are *lots* more implicit/unknown bits here: f : {a : ?} -> {b : ?} -> a -> [b] -> [a] f {a} {b} x ys = map {?} {?} (const {?} {?} x) ys
1
3
Show replies