2533: Generic functions that take integral arguments should work the same way as their prelude counterparts

[Brandon S. Allbery KF8NH]

On 2008 Aug 24, at 1:06, Gwern Branwen wrote:
> On 2008.08.23 15:48:10 -0400, "Brandon S. Allbery KF8NH" <allbery at 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 at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH