Why is Parsec's uncons explicitly inlined for Text but not ByteString?

Question

There's abstraction layer used by Parsec, type class Stream, it looks like this:

class (Monad m, ShowToken t) => Stream s m t | s -> t where
  uncons :: s -> m (Maybe (t, s))

instance (Monad m, ShowToken t) => Stream [t] m t where
  uncons []     = return Nothing
  uncons (t:ts) = return $ Just (t, ts)
  {-# INLINE uncons #-}

instance Monad m => Stream CL.ByteString m Char where
  uncons = return . CL.uncons

instance Monad m => Stream C.ByteString m Char where
  uncons = return . C.uncons

instance Monad m => Stream T.Text m Char where
  uncons = return . T.uncons
  {-# INLINE uncons #-}

instance Monad m => Stream TL.Text m Char where
  uncons = return . TL.uncons
  {-# INLINE uncons #-}

I wonder if inlining is a good idea here, then why uncons in ByteString's instance of Stream is not inlined?

Should all these functions be inlined or none of them, or Text and ByteString are so different that we should inline one and shouldn't inline the other?

Answer 1

I guess there is no real reason. Probably no-one paid attention, benchmarked and showed that there's benefit for or against {-# INLINE #-}.

When Stream Text instances was added in a commit from 2011 it came with {-# INLINE #-} pragma.

On the other hand, Stream ByteString was touched last time in Feb 2008, with the previous commit being Initial import from Jan 2008. It didn't have any INLINE pragmas

So if you think that there's a reason to have or not to have {-# INLINE #-} pragmas on those instances, make benchmarks proving your case. I'm not aware there are any. It might make sense to inline <*> and >>= too, of ParsecT.

Related: I recently added few inline pragmas to lucid, because benchmarks clearly show they make difference; but OTOH you shouldn't sprinkle them to everything.