[m-rev.] for review: allow arbitrary types in class constraints

[David Jeffery]

Ralph said:
> 
> Would there be significant overhead in passing the typeinfo for T as
> well as the typeclassinfo for list(T)?

I suspect the performance impact isn't that huge, but it has never been
measured.

> It seems to me that
> 
> :- pred p(T, T) <= (c(list(T))).
> 
> is expanded by the compiler to something like
> 
> :- pred p(T, T) <= (typeinfo(T), c(list(T))).
> 
> Wouldn't that solve the problem?

Yes, it would.

But it's not what happens at the moment, so Dave's change is likely
to be broken.

There are a few ways to go about fixing it:
    - don't try to nest type-infos inside typeclass-infos
    - fix the type_info_locn type so that it can handle the new form of
      constraints
    - treat type-infos just like typeclass-infos... with something like
      a 'typeinfo/1' type class. In that case you could get rid of the
      type_info_locn altogether, and just record the location of the
      type_info like you record the 'proof' of any other constraint.

These are all too complicated to be included as part of this change,
though...

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