[mercury-users] unification and polymorphism

[Fergus Henderson]

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.

Whether or not is should be enabled by default is another question;
as you mention, there is a space/time trade-off here, and ideally
the choice of whether or not to enable it on a case-by-case basis
could be controlled be profiler feedback.  However, the first step
should be a simple compiler option.

--
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.