[m-rev.] for review: use typeclass constraints to help resolve overloading

[David Jeffery]

> On 21-Jan-2002, David Jeffery <dgj at miscrit.be> wrote:
> > > There really ought to be some change to the language reference manual
> > > to document what you are trying to implement.
> >
> > Does there really need to be a change to the reference manual?
>
> Need is a strong word.
> Does there *need* to be?  No.  *Should* there be?  Yes.
>
> > I think this is really just a bug fix.
>
> If that was the case, and the semantics were properly documented, then
> you ought to be able to point me to the part of the reference manual
> which the current implementation violates.
>
> I think you will have difficulty ;-)

Indeed, but this is because the reference manual isn't precise enough about
how overloading works.

This change brings the situation closer to "what you'd expect" given the
reference manual. Yes, the reference manual needs to be fixed, but I
don't think that it's fair to ask Pete to do that fix as part of this
change.
It's not as if he's changing the documented behaviour; he's really just
making the existing, poorly-documented behaviour more regular and
consistent.

The existing situation is that overloading is unambiguous if:
    - there is a single way of assigning types to variables and of assigning
      module qualifiers to any unqualified predicate, function and
constructor
      names that results in a type correct program, as long as the chosen
      assignment of types to variables uniquely determines the assignment
      of module qualifiers without checking the satisfaction of type class
      constraints.
After this change, overloading will be unambiguous if:
    - there is a single way of assigning types to variables and of assigning
      module qualifiers to any unqualified predicate, function and
constructor
      names that results in a type correct program.

Of course, I'm being sneaky here... the magic part is "that results in a
type
correct program". This implicitly says that all the type class constraints
in
the program are satisfied. (The problem with the reference manual as it
stands is that it isn't quite so abstract... it explicitly says that
        The type assigned to each predicate argument must match the type
        specified in one of the `:- pred' declarations for that predicate
which was the same thing as "must be type correct" at the time that
passage was written, but our definition of type correctness now includes
satisfaction of type class constraints.)

Let me just conclude with a couple of short examples to make sure we're
on the same wavelength...

The compiler will currently accept the following program as unambiguous:
---------------------------------------------
...
:- import_module a,b.
:- pred p(T) .
p(X) :-
    p1(X, Y),
    p2(Y).

...
:- module a.
:- pred p1(T, string) <= c(T).
:- pred p2(string).

...
:- module b.
:- pred p1(T, float).
:- pred p2(float).
...
---------------------------------------------
The program is accepted because the 'p1' being referred to in the
body of 'p' has to be b__p1... it can't be a__p1 because there's a
type class constraint that can't be satisfied. It *does* use the type class
constraint to resolve overloading.

However, the compiler would currently reject the following program
(by throwing a software error):
---------------------------------------------
...
:- import_module a,b.
:- pred p(T) .
p(X) :-
    p1(X, Y),
    p2(Y).

...
:- module a.
:- pred p1(T, float) <= c(T).

...
:- module b.
:- pred p1(T, float).
:- pred p2(float).
...
---------------------------------------------
...even though the 'p1' referred to in the body of 'p' cannot
be a__p1 (because of that same type class constraint). After you
make the type assignment { X -> T, Y -> float), the compiler
just checks if that type assignment is a match (ignoring constraints)
for any of the 'p1' definitions. It finds two that match, and aborts.

HTH.


dgj

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------