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

[Mark Brown]

On 20-Aug-2002, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> 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?

Not requiring the caller to construct and pass a dictionary can surely
be a significant efficiency gain, can't it?  I would have thought that
the main reason someone would want to specialize a predicate with
typeclass constraints on it would be to avoid the need to pass a
dictionary to it.

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

I agree that this may be desirable in some cases, and that users should be
allowed to write ground constraints if they want to (I'm happy to make this
change too if others agree).  But in the case that the ground constraint is
not explicitly present but comes about because of a type_spec request, I
think it is highly likely that the programmer is trying to avoid the need
for a caller to provide a dictionary at run time.  Requiring the
typeclass instance to be visible to the callee is, IMHO, a relatively small
price to pay to achieve this.

Cheers,
Mark.

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