Note that in my experience working on SML/NJ's optimizer (using wrapper+inlining), such an approach to code transformation doesn't care about types at all, and indeed most/all of what tacc-hs09.pdf presents is mostly unrelated to whether the language is typed: e.g. the uncurrying of the zipWith higher-order argument is performed by the inliner (when inlining the various wrappers) without paying any attention to types. So types do not enable the optimization of higher-order functions: it's the wrapper+inlining strategy that enables it. Admittedly, the use of a statically typed intermediate language makes it easier to catch bugs in such optimization phases.
In the Strict Core language, laziness and the arity of a function is
part of its type, so in that sense it cares about the type. For the
uncurrying of zipWith, arity-information is of course very important.
But you are right that apart from laziness, arity, and position of the
function arrows, the base types aren't all that interesting. If all
Int and Char types were replaced with (), most transformations would
still work.
The only transformation that actively uses type information is the
deep unboxing transformation. It uses information about the shape of
the data type to create a more optimal worker function.
Sum types aren't explored in depth in the paper, and I haven't done so
yet either in my work on UHC, but my hope is that those can also be
optimized using the typed representation.
- Tom Lokhorst
P.S. I'm interested in learning more about Flint, can you recommend
any further reading?
On 17 October 2010 20:23, Stefan Monnier
That said, I've been told that UHC's core language uses the ideas from Strict Core, and they have/had a student at Utretch (Tom Lokhorst) who was working on implementing optimisations like arity raising and deep unboxing for the language.
Many/most implementations of ML-ish languages use a similar approach. E.g. SML/NJ's Flint internal language is fairly similar to Strict Core (except for the lack of memoization of zero-arg functions, since that's not very often useful in the context of a strict language like SML) and uses the same kind of wrapper+inlinling to perform most of its optimizations.
Note that in my experience working on SML/NJ's optimizer (using wrapper+inlining), such an approach to code transformation doesn't care about types at all, and indeed most/all of what tacc-hs09.pdf presents is mostly unrelated to whether the language is typed: e.g. the uncurrying of the zipWith higher-order argument is performed by the inliner (when inlining the various wrappers) without paying any attention to types. So types do not enable the optimization of higher-order functions: it's the wrapper+inlining strategy that enables it. Admittedly, the use of a statically typed intermediate language makes it easier to catch bugs in such optimization phases.
Stefan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe