This is my latest version. Based on Don's tweaks.
{-# INLINE sequ #-}
sequ :: (b -> a) -> PU a -> (a -> PU b) -> PU b
sequ a b c | a `seq` b `seq` c `seq` False = undefined
sequ f pa k = PU fn1 fn2 fn3
where
{-# INLINE fn1 #-}
fn1 ptr b =
case f b of
a -> case k a of
pb -> do ptr' <- appP pa ptr a
appP pb ptr' b
{-# INLINE fn2 #-}
fn2 ptr = do (a, ptr') <- appU pa ptr
case k a of pb -> appU pb ptr'
{-# INLINE fn3 #-}
fn3 b = case f b of
a -> case k a of
pb -> do sz1 <- appS pa a
sz2 <- appS pb b
return $! sz1 + sz2
On Jan 4, 2006, at 4:18 PM, Bulat Ziganshin wrote:
are you tried to inline it? and all other pickling combinators
the problem is what when you write
put (Cmd a b) = do putWord16 a; putWord32 b
and inline putWord16/putWord32, you can be sure that you will get
sequencing for free. but what is a pickling combinators? it's a
high-order functions, which combines drivers for simple types like
Word16 to final driver which can read entire Command. the principial
question - will this final driver be interpreted, i.e. executed as a
large number of enclosed calls to pickler combination functions, or it
will be compiled, i.e. executed as simple sequence of getByte calls,
which then builds the final value. in first case your program will
spend all its time in these combinator funtions calls, so you will not
have much effect from using Ptrs in elementary picklers
--
http://wagerlabs.com/
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
