[m-dev.] diff: disable post_typecheck for class methods

[Fergus Henderson]

On 06-Jul-1999, David Glen JEFFERY <dgj at cs.mu.OZ.AU> wrote:
> 
> compiler/purity.m:
> 	Do not check for unbound type variables in the body of a class
> 	method. The class method body is not filled in until all semantic
> 	analysis is done, so performing the check will produce spurious
> 	warning messages in the case where there is an existentially
> 	quantified tvar on the class method.

I think this log message is wrong.  The class method body is filled in
when polymorphism is run, isn't it?

It _used_ to be the case that this didn't happen until all semantic
analysis was done, because polymorphism wasn't invoked until after
semantic analysis.  But that's not true anymore.  Polymorphism 
(and expansion of class method modies) now happens before mode analysis.

The spurious warning is occurring not because the class method body
is not filled in -- it is -- but because the head_type_params field
in the pred_info is never filled in properly for existentially
quantified type class methods.

Your change to skip the post_typecheck pass for typeclass methods is OK,
because there's no need to run the post_typecheck pass on type class methods.
Indeed, your change probably improves performance a bit.

However, your change doesn't really address the root cause of the problem,
which is that the value of the head_type_params field is invalid for
existentially typed type class methods.  If any other part of the compiler
other than post_typecheck.m looks at that field, then that part might
well have a similar problem for existentially typed type class methods.

I did a quick grep, and it looks like currently higher_order.m is the
only other module (other than hlds_out.m) which examines that field.
But at first glance it looks to me like higher_order.m will have a bug
of this kind.  Also, we might well add other passes which use that
field at some point in the future.

Here's a test case which might be able to exercise that bug in higher_order.m.
Currently it gets a software error in inlining, but that might be due to
the type variable being bound to `void'.

	:- module typeclass_exist_method_2.
	:- interface.
	:- import_module io.
	:- pred main(io__state::di, io__state::uo) is det.
	:- implementation.
	:- import_module require.

	:- typeclass toto(T) where
	  [
	  ].

	:- instance toto(float) where [].
	:- instance toto(character) where [].

	:- some [V] (pred gen_toto_float(V) => toto(V)).
	:- mode gen_toto_float(out) is det.
	gen_toto_float(42.0).

	:- some [V] (pred gen_toto_char(V) => toto(V)).
	:- mode gen_toto_char(out) is det.
	gen_toto_char('?').

	:- typeclass toto2(T) where
	  [
	      some[V] (pred gen_toto(T::in, V::out) is det => toto(V))
	  ].

	:- instance toto2(int) where [
		pred(gen_toto/2) is int_gen_toto
	].

	:- some [V] (pred int_gen_toto(int, V) => toto(V)).
	:- mode int_gen_toto(in, out) is det.
	int_gen_toto(X, Y) :-
		( compare(=, X, X) ->
			gen_toto_float(Y)
		;
			error("oops")
		).
		
	main -->
		{ gen_toto(42, Y) },
		write(Y), nl.

	:- end_module typeclass_exist_method_2.

This one should go in the hard_coded directory rather than the valid
directory.  I think we should definitely test that we generate correct
code for examples like these, because the probability of generating incorrect
code seems quite high!

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------