MLton.size bug

[Stephen Weeks]

> > One thing we have to do is to figure why the hash table size is zero in the
> > compiler -v3 output.  I'm not sure whether it's for the same reason as your
> > example above or some other funny interaction with the useless analysis.  If the 
> > former, then we may need to rethink size altogether.
> 
> I believe that it because of the remove-useless pass.  I tried the
> following program:
...
> So, by the time the useless analysis is run, we've already forced the
> MLton_size call to return 0.

Makes sense.  The only thing I see to do for now is to treat the call to size
as if it destructs  -- i.e. treat size like poly equal in remove-unused.

BTW, I noticed a flaw in my other proposed bug fix from yesterday for
remove-unused.

> It should be a simple fix to add the
> constructor argument type to the conInfo field and have decon recur on this
> type. 

You will have to memoize the types that have been called by MLton_equal, just as
is done in poly-equal.