[m-rev.] for review: use typeclass constraints to help resolve overloading
David Jeffery
dgj at miscrit.be
Tue Jan 22 02:25:38 AEDT 2002
----- Original Message -----
From: "Fergus Henderson" <fjh at cs.mu.OZ.AU>
To: <mercury-reviews at cs.mu.OZ.AU>
Sent: Monday, January 21, 2002 2:36 PM
Subject: Re: [m-rev.] for review: use typeclass constraints to help resolve
overloading
> On 21-Jan-2002, David Jeffery <dgj at miscrit.be> wrote:
> >
> > The bottom line is that all of this stuff should be done at the end of
> > typecheck, while all the information is still hanging around.
>
> I don't think that's *needed* -- we could easily record which
> constraints are produced in the body in the pred_info, like the way we
> record the unproven constraints, and then use that in post_typecheck.m.
That will work for now, but I don't think it's a good approach in the long
run.
Ultimately, we'll just keep on adding bits and pieces so that the later pass
can
reconstruct all the information that was calculated in the earlier pass.
Actually, now that I think about it, storing all the constraints produced in
the body wouldn't be enough... you would need to keep track of *where*
they are produced for situations such as:
...
:- import_module a,b.
:- pred p.
p :-
p1(X),
p2(X).
:- pred p2(T) <= c(T).
...
:- module a.
:- some [T] pred p1(T) => c(T).
...
:- module b.
:- some [T] pred p1(T).
In this example, the 'p1' referred to in 'p' has to be 'a__p1' because the
value
passed out must satisfy the 'c(T)' constraint at the call to p2.
Ack.
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
--------------------------------------------------------------------------
More information about the reviews
mailing list