[m-rev.] for review; typeclass decl introduces namespace

[Fergus Henderson]

On 30-Oct-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> 
> Typeclass declarations now introduce a new namespace.  For example the
> method, f, in typeclass, tc, in module, mod, has the fully qualified
> name mod__tc__f instead of mod__f.  This allows typeclasses defined
> at the same scope to have methods with the same name.
...
> Index: compiler/prog_io_typeclass.m
> @@ -625,12 +625,13 @@
>  		% instance declaration for, but we don't necessarily
>  		% know what module that is at this point, since the
>  		% class name hasn't been fully qualified yet.
> -		% So here we give the special module name ""
> -		% as the default, which means that there is no default.
> +		% So here we give the only part of the module name that
> +		% we do know which is the unqualified instance name.
>  		% (If the module qualifiers in the clauses don't match
>  		% the module name of the class, we will pick that up later,
>  		% in check_typeclass.m.)
> -		DefaultModuleName = unqualified(""),
> +		unqualify_name(InstanceName, UnqualifiedInstanceName),
> +		DefaultModuleName = unqualified(UnqualifiedInstanceName),
>  		parse_item(DefaultModuleName, VarSet, MethodTerm, Result0),

I don't think that is correct.

In particular, I think that will lead to an error for

	:- module foo.
	:- interface.
	:- typeclass tc(T) where [
		func foo__tc__bar(T) = int
	].

since `foo__tc' won't match `tc'.

> +++ doc/reference_manual.texi	30 Oct 2001 15:13:25 -0000
> @@ -3825,6 +3825,12 @@
>  There must not be more than one type class declaration with the
>  same name and arity in the same module.
>  
> +The @code{typeclass} declaration introduces a new namespace.
> +The new namespace is the typeclass name.
> +This allows distinct typeclasses to use methods with the same names.
> +For example the fully qualified name for the method @code{f/1} defined
> +in typeclass @code{tc} in the module @code{mod} is @code{mod__tc__f/1}.

I think this is insufficiently precise.
For instance, you introduce the notion of "namespace"
without defining what that means.
Also the part which follows "This allows" is already allowed in some cases
currently, so it's not something which is newly allowed by this change.
And isn't "/1" the arity of the method, not its name?

The wording here also contradicts the wording in other parts of the
language reference manual:

 | There must only be one predicate with a given name and arity in each
 | module, and only one function with a given name and arity in each
 | module.

> diff -N tests/hard_coded/typeclasses/overloaded_methods.m
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ tests/hard_coded/typeclasses/overloaded_methods.m	30 Oct 2001 15:13:25 -0000
> @@ -0,0 +1,36 @@
> +:- module overloaded_methods.
> +
> +:- interface.
> +
> +:- import_module io.
> +
> +:- pred main(io__state::di, io__state::uo) is det.
> +
> +:- implementation.
> +
> +main -->
> +	{ overloaded_methods__tc1__p("string", X) },
> +	io__write_int(X),
> +	io__nl,
> +	{ overloaded_methods__tc2__p("string", Y) },
> +	io__write_int(Y),
> +	io__nl.
> +
> +:- typeclass tc1(T) where [
> +	pred p(string::in, T::out) is det
> +].
> +
> +:- typeclass tc2(T) where [
> +	pred p(string::in, T::out) is det
> +].
> +
> +:- instance tc1(int) where [
> +	(p(_, 1))
> +].
> +:- instance tc2(int) where [
> +	pred(p/2) is i2
> +].

I think this change needs more test cases.

Here you test

	- calling via a fully qualified method name
	- defining the type class with an unqualified method name
	- defining the instance with an unqualified method name

We should also test

	- calling an unqualified method name
	- calling a partially qualified method name

	- defining the type class with a fully qualified method name
	- defining the type class with a partially qualified method name

	- defining the instance with a fully qualified method name
	- defining the instance with a partially qualified method name

Also, currently you test these things for

	- methods with the same name and argument types,
	  in typeclasses with different names

but I think these things should also be tested for

	- methods with the same name and different argument types,
	  in typeclasses with different names

	- methods with the same name and different argument types,
	  in typeclasses with the same name but different arity

Also you should test what happens if you have a submodule and
a typeclass with the same name.

I'm not sure what the intended semantics are in some of these cases.
Some of these cases might be illegal, in which case the test should go
in tests/invalid.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- Prof. Donald E. Knuth
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------