http://www.assembla.com/wiki/show/tincal

It is not a working compiler and a lot of things are missing. I haven’t settled on how to encode product and sum types which in turn determines how “value deconstructors” will be implemented. Those in turn are necessary for pattern matching.

At the moment, it is a personal project that I work on from time to time. Don’t know how far I’ll get.

I see what you’re saying.

Though in actual fact, the missed call to prune was in ‘occursintype’ which is used in a couple of places, notably ‘fresh’ (which creates new type variables from generic ones if necessary), not just in ‘unify’.

The way the algorithm works, the assignment to ‘instance’ should never be performed on anything other than an unbound type variable. So your setter method could just assert(instance == null); instance = newValue;. The ‘Type’ class is already tightly bound to the type inference algorithm, so you might as well implement ‘unify’ and ‘prune’ (and possibly some other functions) as methods on Type, instead of exposing ‘instance’ at all.

Cheers,

–Andrew

> Line 271 of the Perl code implements unifies a type variable with its
> inferred value, so it’s quite essential :)

Absolutely agree, but… :-)

> You could wrap it in an setter method if you like (is that what you
> meant?), but that doesn’t change the behaviour of the algorithm.

Yes that’s what I meant. My real argument is that it’s dangerous *not* to wrap the assignment to a logic variable in a setter method.

In the standard(?) implementation of Logic Variables, they arrange themselves in chains. For instance assume some language with LVs:

# create an empty LV
declare A;
# result A->(empty)

# create another empty LV
declare B;
# result: B->(empty)

# unify A with B
A = B;
# result: A->B->(empty)

# unify A with 1
A = 1;
# result: A->B->1

The point then is that naive assignment directly to A here would not achieve the desired result, instead you would end up breaking the association of A and B giving

A->1
B->(empty)

The setter method must chain down the list from A to B until it finds a pointer to (empty) and assign there.

“Pruning” as I understand it is just that action of chaining down the list, but it is presented in the Perl algorithm at least as being a separate step from the assignment. So if as in the perl case it was forgotten, we get the bug you detected.

It’s been a while since I’ve looked at this, but I think I’m right in saying:

The core type inference algorithm certainly does not require a distinction between let and lamda. That is: you’re perfectly free to add in a rewrite step which transforms ‘let’ into ‘lambda’, and remove ‘let’ handling by the type inferencer completely. The included AST is just a little toy language to show off that the type inference works.

Line 271 of the Perl code implements unifies a type variable with its inferred value, so it’s quite essential :)

You could wrap it in an setter method if you like (is that what you meant?), but that doesn’t change the behaviour of the algorithm.

If more generally you mean that you’d rather have an implementation which only used immutable objects, and did not have the mutation which you point out on line 271… that too is possible. As Christian Klauser points out above, it’s trickier in a pure functional environment, but quite possible; you just have to maintain a map of type variables to their bound types. The Cardelli paper calls this the ‘set of assumptions’ (page 13). However, the Perl implementation, and my Scala implementation, mutate the type variable objects instead of maintaining a separate map.

Hope this helps!

–A

In the Perl from Nikita Borisov, I *think* the flaw is in the direct assignment to a logic variable instance:

$type1->{instance} = $type2;

on line 271 in the code I found. Assigning to a logic variable is best done only by a logic variable method that can protect its own integrity.

I’m also a bit disappointed having read the Cardelli paper (my maths is probably worse than yours) to find that the algorithm requires a distinction between let and lambda. I’m already firmly in the Scheme camp where “let x = y in z” gets rewritten to “fn (x) {z} (y)” (i.e. let is just lambda) before the AST is even built.

Still, thanks very much for your implementation, I was getting hung up on the Perl one, and any thoughts about this?

Great work!

I’m also trying to understand HM type inference from a pragmatic point of view.

I only know Scala theoretically, but I have strong skills in C#.

So Christian, are you also sharing your C# implementation?

Thanks,
Peter

Yeah, took me a while (and the act of debugging my own implementation) before I started to really understand it.

Cheers,

–A

I’ve been playing around with the idea of using type-inference myself for a while now but couldn’t make sense of Milner’s original paper, in particular I didn’t understand the unification step. (Even though it is actually quite simple in an impure environment)

I have since implemented my own version in C# (and yes, it is a pain to work without tuples, type inference, pattern matching and discriminated unions) and am now working “more advanced” features like pattern matching and case expressions.