4 ms·

Hah. I'm highly skeptical. But I suppose if anyone could do it, it'd be him. I would certainly learn something. :-) I've tried optimizing Haskell code myself b

Hah. I'm highly skeptical. But I suppose if anyone could do it, it'd be him. I would certainly learn something. :-) I've tried optimizing Haskell code myself before. It did not go well. It was an implementation of the Viterbi algorithm actually. We ported it to Standard ML and C and measured performance. mlton did quite well at least. We published a paper about the process of writing Viterbi in Haskell in ICFP a few years back: https://dl.acm.org/doi/pdf/10.1145/2364527.2364560?casa_token=19aYVUM_DGsAAAAA:OpdVjP1Q33EsnlQjk-969AGQN0maJarkEa78xjjsJGWT1ytxMrnNuHdgEkGWAFa3aIj4Hi7BTPEixQ https://dl.acm.org/doi/pdf/10.1145/2364527.2364560?casa_toke... Unfortunately, the performance aspect of it was only a small part, and we didn't talk about the C or mlton ports in the paper.

eru 6y ago
Very interesting! I suspect you could make a very Haskell-like language that's also really fast, but you'd have to base it on linear types from the ground up, and make everything total by default. (Hide non-total parts behind some type 'tag' like we do with IO in current Haskell (and have something like unsafePerformPartial when you know your code is total, but can't convince the compiler).) That way the compiler can be much more aggressive about making things strict.