[Haskell-cafe] Strange type behavior in GHCi 6.4.2

Bulat Ziganshin bulat.ziganshin at gmail.com
Mon Jan 1 05:38:23 EST 2007

Hello Kirsten,

Sunday, December 31, 2006, 7:47:18 PM, you wrote:

>> this don't say anything place. and these rules have their own source: it's
>> hard to optimize using your path. but when program optimization is just
>> adding a few options/pragmas to the program, it' becomes cheap enough to
>> change these rules. didn't you thought about it?

> In my experience, adding pragmas and toying with options without
> insight into what they do is not "cheap", because it takes up the
> programmer's time, and time is more important than anything else.

using pragmas is much cheaper than profiling/reading low level code

> Every minute spent typing in pragmas is a minute lost that could have

it's a great loss :)

> been spent thinking about how to write your code more elegantly, and
> in my experience -- and again, maybe it's just that I'm slow -- adding
> pragmas doesn't help. When it comes to inlining and specializing, GHC
> tends to be smarter than I am. (Once more, maybe it's just that I'm
> slow.) I'd rather focus my energies on doing the things GHC can't
> (usually) do, like replacing an O(n^2) algorithm with an O(log n)
> algorithm.

in a minute? :)

i don't agree with your arguments. if you want your program to become
faster you should use various techniques. what i proposed is fastest one. i
don't see meaning in opposing algorithm optimization to other techniques

my own optimization experience was experimenting with variants of source
code and once i understood which variants of code can't be inlined at all i
just use inline pragma for all critical functions. i've learned how ghc
generates STG code once and for all, and don't think that i need to see
STG anymore

Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com

More information about the Haskell-Cafe mailing list