> 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
