00:00:00 --- log: started haskell/02.03.08 01:06:49 --- join: ChoJin (~ask@cha213245038031.chello.fr) joined #haskell 03:22:59 --- quit: ChoJin ("bye !!!") 03:53:43 * clausen is reading okasaki's book (purely functional data structures)... good book :) 04:10:31 --- quit: xbill ("Leaving") 06:06:42 --- nick: Logan_ -> LoganH 06:21:52 --- join: pesco (~pesco@pD90044E6.dip.t-dialin.net) joined #haskell 06:49:28 --- join: jacoboy (jacoboy@61.190.104.70) joined #haskell 06:49:34 --- part: jacoboy left #haskell 06:56:10 I'm having a performance problem. 06:56:38 I had a function which worked well. 06:56:58 Now, I made it polymorphic and I run out of stack space. 06:57:11 Might the function not be tail-recursive any more? 07:58:40 polymorphic using a type class? 07:59:01 This is the type declaration: 07:59:19 crc :: (Bits a, Integral a) => [Byte] -> a -> a 07:59:59 Before I had used this: 08:00:22 crc32 :: [Byte] -> Word32 -> Word32 08:01:05 Also, after giving GHC a SPECIALIZE pragma for Word32, it works as before. 08:01:49 However I'm wondering why the polymorphic function behaves differently. 08:03:39 type classes work by passing around a dictionary at runtime 08:03:51 but that shouldn't affect the tail-recursiveness 08:04:02 Please elaborate about that dictionary. 08:04:33 when you declare a type class you say what functions things in that type class must implement, right 08:04:34 ? 08:04:47 Right. 08:05:10 those functions are packaged up in a dictionary for that type and passed as a parameter to other functions that use the type class 08:05:14 s/other// 08:05:21 Ah. 08:06:03 So by giving a constraint on crc, It gets passed a function dictionary for classes Bits and Integral? 08:06:41 yeah 08:06:58 but I don't see why it'd affect tail-recursiveness 08:07:05 Me neither. 08:07:26 However, I'm just _suspecting_ the function not to tail-recurse any more. 08:07:53 But a stack overflow certainly looks like it. Or what else could eat up a few megs of stack space? 08:09:00 the trouble is GHC does weird stuff to optimise programs, which could be quite fragile 08:09:06 Is there an easy way to determine whether the function is tail-recursive? 08:09:07 in that a random change might stop an optimisation applying 08:09:10 nafaik 08:09:16 :/ 08:09:43 Do you think another compiler might do better? 08:10:40 I doubt it 08:10:48 I see. 08:11:00 a simpler compiler would be more predictable by not optimising it in either case :-) 08:11:08 Heheh 08:17:09 Are you using optimisation with GHC? 08:18:22 Yes. 12:14:37 --- quit: LoganH (Read error: 110 (Connection timed out)) 12:17:09 --- join: ChoJin (~ask@cha213245038031.chello.fr) joined #haskell 13:12:05 --- join: LoganH (~logan@up112.blacksburg.ntc-com.net) joined #haskell 13:38:20 --- join: GalaK (~james@pc1-leic3-0-cust167.not.cable.ntl.com) joined #haskell 13:41:32 --- part: GalaK left #haskell 13:41:37 --- join: GalaK (~james@pc1-leic3-0-cust167.not.cable.ntl.com) joined #haskell 13:44:12 --- part: GalaK left #haskell 14:35:59 --- join: GalaK (~james@pc1-leic3-0-cust167.not.cable.ntl.com) joined #haskell 14:46:15 --- quit: GalaK ("Leaving") 14:48:08 --- quit: pesco (Remote closed the connection) 14:53:49 --- quit: dennisb (Read error: 113 (No route to host)) 17:08:36 --- quit: ChoJin ("bye !!!") 18:49:38 --- join: xbill (wli@DOMINIA.MIT.EDU) joined #haskell 19:46:00 --- join: nrp (~nrp@dl-nas8-poa-C8B087DE.p001.terra.com.br) joined #haskell 19:46:41 --- part: nrp left #haskell 19:47:17 --- quit: clausen (Read error: 110 (Connection timed out)) 23:19:14 --- join: clausen (~andrew@c17997.eburwd3.vic.optusnet.com.au) joined #haskell 23:43:26 --- quit: clausen (Read error: 104 (Connection reset by peer)) 23:44:53 --- join: clausen (~andrew@c17997.eburwd3.vic.optusnet.com.au) joined #haskell 23:59:59 --- log: ended haskell/02.03.08