Re: Cost of Overloading vs. HOFs

[switching to haskell-cafe]
thanks for the explanation, John. doesn't the list cases mentioned in the
definition of (+) below assume whole program, in order to know all Num
instances?
On 5/4/07, John Meacham
On Fri, May 04, 2007 at 05:06:10PM -0700, Conal Elliott wrote:
Cool. You know which types to consider because jhc is a whole-program compiler?
Yes. though, i have since redone the back end so there is no technical reason for it to be whole program any more, you can just benefit from more optimizations that way. The old backend required global knowledge to compile at all.
Given the whole program, why not monomorphize, and inline away all of the dictionaries?
Well that is the thing, there are no dictionaries at all, the only extra arguments passed in are the types so,
f :: forall a . (Foo a, Baz a, Bar a Int, Bred a) => a -> a
still is only passed the single hidden argument of 'a' since a case on it will determine what method to use.
(+) a x y = case a of Int -> plusInt x y Float -> plusFloat x y
and so forth. a here is a type, of kind '*'.
since the method lookup is done explicitly via the case statement, it can be optimized via standard transformations in nice ways.
John
- Conal
On 5/4/07, John Meacham
wrote: On Fri, May 04, 2007 at 03:07:41PM -0700, Conal Elliott wrote:
Does anyone know what became of Dictionary-free Overloading by
Partial
Evaluation http://web.cecs.pdx.edu/%7Empj/pubs/pepm94.html? Is it impractical for some reason?
jhc also uses a dictionary free approach, doing a case directly on the type parameter.
The nice thing about this is that _all_ methods can be determined by a single case evaluation, because finding out the right instance for any method will determine the right instance for all other methods too for a given type. The standard case-of-known-value optimization takes care of later scrutinizations (method lookups) on the same type.
John
-- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Fri, May 04, 2007 at 07:20:03PM -0700, Conal Elliott wrote:
[switching to haskell-cafe]
thanks for the explanation, John. doesn't the list cases mentioned in the definition of (+) below assume whole program, in order to know all Num instances?
Yes it does in the current implementation, but the type class implementation is relatively separate from the rest of jhc, so it could be modified in various ways. my current thinking for separate compilation is to allow separate compilation, but have a special pass at the end right before linking that goes through and assigns a unique discriminator to each type, so it would sort of be a built in extensible data type. it can actually be done without a special linker by just placing each descriptor in a special section and using their offset from the beginning of the section as its unique id. FWIW, I would _love_ some standard way to create closed classes in haskell'. it would greatly facilitate this sort of optimization without resorting to much trickery. My current thinking is something like allowing 'class closed Foo' in export lists, which exports the class name except won't let you create new instances for it (via that import). I know the standard trick using a 'Fail' superclass, but having the compiler recognize that special case feels very unclean. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (2)
-
Conal Elliott
-
John Meacham