On 2008 Aug 24, at 1:06, Gwern Branwen wrote:
On 2008.08.23 15:48:10 -0400, "Brandon S. Allbery KF8NH" <allbery@ece.cmu.edu
scribbled 0.5K characters: On 2008 Aug 23, at 15:46, Gwern Branwen wrote:
I've actually long wondered about this: why don't more functions use Nat where it'd make sense? It can't be because Nat is hard to define - I'd swear I've seen many definitions of Nat (if not dozens when you count all the type-level exercises which include one).
Because naive definitions are dog-slow and fast definitions are anything but easy to use? While I am but a mediocre Haskell programmer at best, I can't say I find that a satisfying explanation. When I read the GHC & fusion papers (among many many other fine papers relating to Haskell), I am impressed at the optimizations the authors managed to eek out despite the difficult conditions they labor under. With that in mind, I find it hard to accept that there is no approach which is fast and easy to use - no theorems or rewrite rules or library which
There are fast ones that are easy to use; they use Template Haskell, which isn't H98. As for why: it's not so much that its hard to optimize, it's that Haskell doesn't lend itself *conveniently* to type-level programming (which this is), so you end up resorting to TH or having rather ugly types all over the place. (Optimizing the naive case... you'd have to ask the GHC folks, but I suspect while they could optimize for it, it'd be a sufficiently narrow optimization that they'd want to see enough use to justify it.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH