I think Jake is referring to my vector-space package.  He did the work of writing 171 INLINE pragmas, covering lots of methods and standalone function defs.  I'm simultaneously grateful for the effort and repelled by the added syntactic noise.  Also concerned about the impact of all these directives on other uses of vector-space.  If all this inlining is a uniform win, I'd rather ghc did it for me.  If the ghc implementers have reasons not to do so in general, then I'd expect that some of those reasons apply to vector-space (and many other libraries) as well.  It's not like I'm applying some kind of domain-specific understanding that ghc doesn't have access to.

I'm raising my concerns here in the hopes of stimulating some creative thinking and suggestions about addressing this sort of situation more generally.

  - Conal

On Sun, Mar 7, 2010 at 9:23 PM, Don Stewart <dons@galois.com> wrote:
jake.mcarthur:
> I've run into an issue with inlining that I'm not sure how to work
> around. I am instantiating some pre-existing type classes with
> Vector-based types. There already exist generic functions in modules I
> do not control that use this type class, and they are not tagged with
> the INLINE pragma. I am doubtful, but I figure it is worth at least
> asking: is there some practical workaround for this kind of situation
> that anybody knows about?
>

I don't know of a way, other than patching the library code.
If it makes a difference to you, it probably makes a difference to lots
of people.

-- Don
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe