[mercury-users] unification and polymorphism

[Peter David ROSS]

On 05-Aug-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 05-Aug-1998, Andrew Bromage <bromage at cs.mu.OZ.AU> wrote:
> > G'day all.
> > 
> > tom.howland at us.pwcglobal.com wrote:
> > 
> > > > I can understand the difference between (2) and (3): it is the cost of
> > > > polymorphism, right ? A bit higher than I expected I must say.
> > > 
> > > I would have guessed polymorphism would be resolved at compile time.
> > 
> > What I think you meant is not _resolution_ of polymorphism, but
> > _specialisation_.  That is, if you know what a certain polymorphic
> > type variable is bound to, create a specialised predicate with the
> > variable bound in the hope of efficiency gains.
> > 
> > The trouble here is that it's unclear if the gain that you get by
> > specialisation is outweighed by the loss in code bloat (and hence
> > increased code page faults), extra compilation time and so on.  For
> > this reason, list unifications are specialised only on mode, not on
> > type, and even then only if the unification doesn't basically down to
> > a mode like "'='(in, in) is semidet".
> 
> I think it would be nice if there was a compiler option that
> if enabled caused the compiler to specialize unifications of
> polymorphic data types if the type was known.  The compiler has
> all the necessary information to do this specialization, the
> only reason that it is not done is that no one has implemented
> it yet.
> 
I am working on it at the moment.  

To begin with it will be implemented as a pragma, similar to the one
below.

ie. :- pragma type_spec(map__lookup/3, [K - (int:int)]).

Pete.
-- 
----
 +----------------------------------------------------------------------+
 | Peter Ross      M Sci/Eng Melbourne Uni                              |
 | petdr at cs.mu.oz.au  WWW: www.cs.mu.oz.au/~petdr/ ph: +61 3 9344 9158  |
 +----------------------------------------------------------------------+