> 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 <monn...@iro.umontreal.ca> wrote: >> 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 > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
