Monomorphize, was: Re: Proposal for generalized function partition in List-library
John Meacham
john@repetae.net
Fri, 18 May 2001 12:32:11 -0700
this is interesting, could someone give an example of how polymorphic
recursion would disallow specialization of a function?
i mean, it seems to me that even if you had recursion, you still have to
actually call the function at some point with some real type and at that
point you can decide whether to use the specialized version or not.
One of the main things i was hopeing was that the seperate 'generic' and
'concrete' functions in the Prelude could be dumped for just the generic
ones. the compiler should be able to optimize for the common cases of
Nums being Ints and whatnot. (with the help of some pragma annotations.)
-John
On Fri, May 18, 2001 at 10:32:54AM +0200, Josef Svenningsson wrote:
> John,
>
> On Thu, 17 May 2001, John Meacham wrote:
>
> [..]
> > namely that you don't necisarilly know all of the types of polymorphic
> > functions when they are in a module that is compiled seperately from the
> > rest of the program. the solution used by many C++ compilers is to
> > inline all polymorphic code in place (this is why templates are in
> > header files). there is no reason this won't work in haskell and give
> > back all of the speed benefits of base types everwhere (as it would in
> > this example) but has the unfortunate side effect of causing worst case
> > exponential code bloat as every function is re-written for every type
> > combination it is used with.
> >
> This is true in ML but not in Haskell. Haskell has polymorphic recursion
> which makes it impossible to predict statically at what types a function
> will be called. So trying to inline away polymorphism would lead to
> infinite unwindings.
>
> Cheers,
> /Josef
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@repetae.net
--------------------------------------------------------------