[MLton] Install problem

Stephen Weeks MLton@mlton.org
Tue, 4 Nov 2003 09:51:00 -0800


> I'm trying to figure out the "unresolved bugs" from
> http://www.mlton.org/user-guide/Unresolved_bugs.html even I still do
> not know much about ML. :) I ran the command as: mlton -verbose 3
> error.sml and I thought the type error happened in the fun checkType
> (ty: Type.t): unit in mlton/xml/type-check.fun (around line 33).

You must have compiled with -type-check true then.  Yes, it looks like
that is where the error would be detected.  Before continuing, I
should point out that once MLton has a proper front end, the error
will be reported in the front end and not at some later pass.

> I tried to print something to see what's in the 'scope', but I don't
> know how and what to print. :P

Knowing what's in scope is always challenging when reading a new (big)
piece of code in an unfamiliar language.  It would be wonderful to
have better SML development tools that would tell you that (and jump
to definitions, ...).  In any case, I would think that a print
statement inside the var field would show something

		   var = fn a => if !(tyvarInScope a)
				    then ()
				 else (print "tyvar case\n"
                                       ; Type.error ("tyvar not in scope",
						     Tyvar.layout a))

> (I also traced into the lib/mlton/basic/property-list.fun and added
> a print function for fun get and set, I thought it was used in the
> type-check. but when I re-compiled and ran the command again. it
> seems that neither of the two functions are called in this case.)

Property lists are definitely used.  The problem is that there is some
vestigal code in property-list.fun.  If you look at property.fun, you
will see that it defines its own "get" and "set" in terms of the "add"
and "peek" provided by property-list.fun.  I've checked in a fix to
our CVS that eliminates the vestigal code.

> I'm familiar with C++, and I found there are many different between
> ML and C++. Such as in C++, if you want to call a structure's
> function directly, the function has to be static, or you have to
> define a instance of the structure first. But in ML, I chould call a
> structure's function directly. Isn't it?

Right.  Structures in SML are completely static, compile-time
entities.  In fact, a very early pass of MLton eliminates them
entirely.

> So I wonder in which conditions one is better than another? and
> could we combine them together?

Personally, I find the more static style of SML easier to think about.
However, I do program in a somewhat object-oriented style in SML in
that each structure corresponds to a C++ class, and defines a single
type t, where each operation on that type takes the object as its
first argument.  The difference in SML is that when applying a
function (method) I have to write the structure (class) name instead
of it being inferred from the object.  So I write "Foo.f (a, b, c)"
instead of "a->f (b, c)".