Max Bolingbroke wrote: > On 15 February 2011 16:45, Roman Leshchinskiy <r...@cse.unsw.edu.au> wrote: > >> Only if foo has an INLINE pragma. Otherwise, GHC uses whatever RHS is >> available when it wants to inline. > > Ah, I see! Well yes, in that case my workaround is indeed broken in > the way you describe, and there is no way to repair it because in my > proposal you wouldn't be able to write an INLINE pragma on the actual > default method definition.
There is an alternative, actually. When compiling a module with a function that doesn't have an INLINE pragma, GHC uses its optimised rhs for inlining in every stage and then records its unfolding for use in other modules if it is small enough to be inlined. This has some unfortunate (IMO) implications. Consider the following code: {-# INLINE [1] f #-} f = <big> g = f h = g Will <big> be inlined into h? This depends on the module that h is defined in. If it's in the same module as g, then g will most likely be inlined into h in phase 2, i.e., before f has been inlined into g. Then, f will be inlined into both g and h in phase 1. However, after f is inlined into g, g's rhs becomes too big for inlining. So if h is defined in a different module, g won't be inlined into it. We could just as well say that a function's rhs should be recorded forever as soon as it becomes small enough to be considered for inlining. So GHC could notice that g is very small in phase 2 and basically add an INLINABLE pragma to it at that point, regardless of what happens to its rhs afterwards. This would ensure that inlining isn't affected by splitting things into modules and would probably also make your proposal work. But it would also result in a lot more inlining compared to now. Roman _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe