[m-dev.] nightly tests failed

Zoltan Somogyi zs at cs.mu.OZ.AU
Fri Feb 4 18:51:34 AEDT 2000

On 23-Jan-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> 	- extras/clpr/cfloat.m got compilation errors.
> 	  This is due to the change to runtime/mercury_type_info.h
> 	  that zs committed recently ("remove several obsolete macros").
> 	  Zoltan, could you please fix this one?

I just committed the updated fix to this.

> I can see three possible solutions:
> 	(1) Change the types that we give to type_info and type_class_info
> 	    variables so that they don't contain any type variables.
> 	    I think the reasons for including type variables in
> 	    the types of builtin:type_infos are mainly historical.
> 	    However, there are probably lots of places in the system
> 	    that depend on this now; changing this would be tricky.
> 	    Also, I seem to recall that there was some reason for
> 	    putting type variables in the types of type_class_infos,
> 	    although right now I can't remember what it was.
> 	    DJ, do you remember?
> 	(2) During code generation, don't include the type variables
> 	    from the types of type_info and type_class_info variables
> 	    in the set of variables to save.
> 	(3) During liveness computation, apply the process transitively,
> 	    so that the type variables in question are marked as live
> 	    at the points where the code generator will reference them.

I strongly prefer solution 1. The fact that types typeinfo, type_ctor_info,
typeclass_info and base_typeclass_info appear to have arity one but their
actual types are variable is causing lots of other problems. I think we
need to treat them as builtins, not as special-cased "user" defined types.
This should also get rid of the duplication involed in having two type_info
types and two type_ctor_info types, with one of each being defined in builtin.m
and std_util.m. The ones currently defined in std_util.m have arity zero,
and as far as I can see, serve no purpose except as sanitized versions
of the types in builtin.m (i.e. types that you can expose users to, which
is not true of the arity one versions).

mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au

More information about the developers mailing list