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

[Simon Taylor]

On 20-Aug-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> 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.

The main reason for specialization is to optimize away lookups in
the dictionary. The cost of constructing and passing the dictionary
should be very small because dictionaries created when the types are
fully known at compile time should be placed in static data.
 
> > As far as I know the intention was that we would
> > allow declarations of the form `:- func f(float) = int <= foo(float)'.
 
> 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.

I'm not totally convinced that the reasons for allowing ground
class constraints in predicate declarations aren't equally valid
for type specialization procedures, and I'm also not convinced that
the speed-up is worth adding an inconsistency to the language.

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