THE FOLD / CO-OP / THE SYNC / THE LET POLYMORPHISM
THE LET POLYMORPHISM
what is left once nothing could still change
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
In most languages
LIT verified live on the same inferencer. let id = \x.x in pair (id 1) (id true) types cleanly — 0 errors, result pair[int,bool]. Turn generalisation off and the identical program has 1 error. Rewrite it as (\id. ...) (\x.x), which evaluates identically, and it also has 1 error. The
let x = v in e means the same as applying a function to v. In a typed language it does not, and the difference is the reason polymorphism is usable at all.LIT verified live on the same inferencer. let id = \x.x in pair (id 1) (id true) types cleanly — 0 errors, result pair[int,bool]. Turn generalisation off and the identical program has 1 error. Rewrite it as (\id. ...) (\x.x), which evaluates identically, and it also has 1 error. The
let is not sugar.2 HOW IT WAS WEAVED · AI + HUMAN
Let-generalisation is what makes Hindley-Milner practical; a lambda-bound variable is monomorphic because it may still be constrained by the argument that has not arrived yet.
AVAN (AI) ran three versions rather than two. The third — the same program written as an application — is the one that makes the claim precise: this is not about
AVAN (AI) ran three versions rather than two. The third — the same program written as an application — is the one that makes the claim precise: this is not about
let being special syntax, it is about the type checker knowing the definition is finished.3 ONE DIMENSION
One program, three ways, two of them rejected.
4 TWO DIMENSIONS · INTERACTIVE
Toggle generalisation and re-infer.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: one definition, two uses.
AVAN’s addition (the inverse-companion): the forward reading is that
let generalises and a lambda cannot. The inverse is that the lambda is right and the let is taking a liberty. A lambda-bound name might still be constrained by an argument nobody has supplied; refusing to generalise it is simply not guessing. Read backwards, let gets to generalise only because the definition is already complete and there is nothing left to learn about it — polymorphism is not a power the type system has, it is what is left over once the checker has run out of things that could still change.LIT let id = \x.x in pair (id 1) (id true) types cleanly with 0 errors as pair[int,bool], while turning generalisation off gives the identical program 1 error, and rewriting it as (\id. ...) (\x.x) - which evaluates identically - also gives 1 error, so the let is not sugar for a lambda
FIG Let-generalisation is what makes Hindley-Milner practical; a lambda-bound variable is monomorphic because it may still be constrained by the argument that has not arrived yet. AVAN ran three versions rather than two. The third - the same program written as an application - makes the claim precise: this is not about let being special syntax, it is about the checker knowing the definition is finished.
FIG Let-generalisation is what makes Hindley-Milner practical; a lambda-bound variable is monomorphic because it may still be constrained by the argument that has not arrived yet. AVAN ran three versions rather than two. The third - the same program written as an application - makes the claim precise: this is not about let being special syntax, it is about the checker knowing the definition is finished.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of THE SYNC · David Lee Wise (ROOT0), with AVAN