ML_expand: attempt to use UNUSED tag!

[Tyson Dowd]

Oops, I'll try sending this to mercury-developers too.

On 29-Dec-1997, Fergus Henderson <fjh at cs.mu.oz.au> wrote:
> On 22-Dec-1997, Thomas Charles CONWAY <conway at cs.mu.oz.au>
> reported a bug with a test case similar to the following (paraphrased):
> 
> 	% module_1
> 	:- interface.
> 	:- type cqueue(T) == pair(list(T)).
> 
> 	% module_2
> 	:- import_module module_1.
> 	:- pred p(cqueue(int)::in, io__state::di, io__state::uo) is det.
> 	p(X) --> write(X).
> 
> The problem occurs when ML_expand() calls ML_create_type_info() to
> expand the equivalence type.  The problem is that when ML_create_type_info()
> is substituting out the values of the type parameters, it only looks at the
> top two levels of the type.  Thus it handles
> 
> 	:- type foo(T) == T.
> 
> or
> 	:- type bar(T) == baz(T).
> 
> fine, but for
> 
> 	:- type cqueue(T) == pair(list(T)).
> 
> the result of expanding the equivalence type `cqueue(int)' is
> `pair(list(T))' rather than `pair(list(int))'.
> `T' here is an unbound type parameter.
> 
> The obvious solution seems to be to do a deep traversal of the type.
> Tyson, could you please review this?

Yes, this seems to be the right solution. ML_expand is supposed to
return completely expanded type infos. The old code was returning
pseudo-typeinfos in some circumstances.

> 
> library/std_util.m:
> 	Fix a bug in make_type_info() and ML_create_type_info():
> 	when searching for type parameters to substituting with their
> 	corresponding values, they were only looking at the top level
> 	of the type.  To get correct results, it is necessary to
> 	traverse recursively through all levels of the type.
> 
> I think make_type_info() in runtime/mercury_type_info.c has the

Actually mercury_deep_copy.c

> same bug.  But the fix there is harder, due to the memory management
> issue; off-hand I don't see any simple and obvious way of solving it.
> Perhaps it needs to allocate the type_infos on a separate heap
> (organized using stack-like allocation).

I'm wondering if it's possible to not allocate new type_infos
in general, and just keep around the actual parameters. If
you need to do something with the type represented by just a variable 
(like copy it) you can get the type parameter. You should only need
to do a substitution when you find an equivalence, because that's the
only time the number of type parameters can increase or decrease
or change position. Most equivalences are already removed by
the compiler, unless they are abstract (and intermodule
optimization can remove them). So make_type_info would become
make_type_parameters. 

I haven't convinced myself this will work yet.

I'm going to have to think about this for a while. I've got a bunch
of other things to do as well, so it might have to wait a while.

The code you've changed looks ok.

-- 
       Tyson Dowd           # If I'm unusually agressive in this email, it's
                            # probably because USENET has been down here for
     trd at cs.mu.oz.au        # over a week, and I'm missing my usual dosage
http://www.cs.mu.oz.au/~trd # of flamewars. My apologies in advance.

-----End of forwarded message-----

-- 
       Tyson Dowd           # If I'm unusually agressive in this email, it's
                            # probably because USENET has been down here for
     trd at cs.mu.oz.au        # over a week, and I'm missing my usual dosage
http://www.cs.mu.oz.au/~trd # of flamewars. My apologies in advance.