[m-rev.] for review: type_spec and typeclass constraints

[Simon Taylor]

On 20-Aug-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> This is for review by Simon.
> 
> Estimated hours taken: 5
> Branches: main
> 
> When specializing the type of a pred/func with class constraints on it,
> make sure any constraints which become ground are removed from the
> specialized version.  The presence of ground constraints was causing
> dictionaries to be passed around unnecessarily, and these cases were not
> always caught by unused arg elimination.

> This change means that the compiler will have to prove the constraints
> are satisfied using instance declarations visible at the point of the
> pragma type_spec, instead of requiring the caller to supply a proof.

Is there any reason why this is necessary other than the minor
efficiency gain? As far as I know the intention was that we would
allow declarations of the form `:- func f(float) = int <= foo(float)'.

>From Fergus's review of type specialization on mercury-developers 
in September 1998:
> > +
> > +             % A constraint says nothing if the types are all ground.
> > +             list__member(Type, Types),
> > +             \+ term__is_ground(Type)
>
> This is not always true.  Constraints on ground types can make sense
> if the instance declaration is visible in the caller but not in the
> callee.
>
> For example, if you have an abstract type `adt' declared in the
> interface of one module
> 
>         :- module foo.
>         :- interface
>         :- class c where [...].
>         :- type adt.
> 
>         :- implementation.
>         :- instance c(adt) where ...
> 
>         foo:p :-
>                 bar:q.
> 
> then in a different module you could have
> 
>         :- module bar.
>         :- interface.
>         :- import_module foo.
>         :- pred q <= c(int).
>         q :- ...
> 
> and here the ground constraint `c(int)' makes sense, since the instance
> declaration isn't visible inside `bar', it's only visible from the caller
> in the implementation of module `foo'.

But I see that David Overton has recently committed the following change,
which disallows cases like this:
> date: 2002/07/26 06:33:11;  author: dmo;  state: Exp;  lines: +18 -9
> 
> Estimated hours taken: 25
> Branches: main
> 
> Allow constraints on pred/func, instance and typeclass declarations to
> constraint arbitrary types rather than just type variables.  The only
> restriction is that each constraint must contain at least one type
> variable and that all type variables in the constraint must also occur
> somewhere else in the declaration.
> 
> compiler/prog_io_typeclass.m:
>         When parsing class constraints (on pred/func, instance and
>         typeclass declarations) remove the restriction that the
>         arguments must all be variables.  Instead, ensure that at least
>         one argument contains at least one variable.

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