’Fraid I can’t help; I don’t use Eclipse. Have you tried it from the command-line? Perhaps Eclipse is confused because it is written as a script (see line 304)…?

The code outputs the type of an expression, given an abstract syntax tree representing that expression. However, it does not parse string expressions to create the AST, if that’s what you’re asking. So you can’t run it on arbitrary expressions from the command-line, or anything like that.

Hope that helps,

–Andrew

http://www.smallshire.org.uk/sufficientlysmall/2010/04/11/a-hindley-milner-type-inference-implementation-in-python/

Thanks for providing a clean implementation in Scala for me to work from; it was much more comprehensible than the Modula-2 or Perl, even though I don’t know Scala and do know Perl.

I tried to run ur code using eclipse under windows. I got the following error

java.lang.NoClassDefFoundError: HindleyMilner

Can you help me regarding this issue. Besides does the code enables inputting an expression and getting its type as output.
Regards

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.

perl 5.10
dbi 1.609

It’s hilarious. It also fits the scene perfectly, as shot.

http://www.youtube.com/watch?v=kYfibSaDHrM

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