为什么Parsec的uncons显式内联Text而不是ByteString？

Question

有被秒差距使用的抽象层,类型的类Stream,它看起来像这样:

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 #-}

我想知道内联是否是一个好主意,那么为什么uncons在ByteString这个例子中Stream没有内联？

如果所有这些功能被内联或没有人的,或Text与ByteString是如此不同,我们应内嵌一个不应该内联其他？

Answer 1

我想没有真正的原因。可能没有人关注、进行基准测试并表明支持或反对都有好处{-# INLINE #-}。

当在2011 年的提交Stream Text中添加实例时 ，它附带了pragma。{-# INLINE #-}

另一方面，Stream ByteString 上次触及是在 2008 年 2 月，之前的提交是2008 年 1 月的初始导入。它没有任何INLINE编译指示

因此，如果您认为有理由{-# INLINE #-}在这些实例上使用或不使用编译指示，请制定基准来证明您的情况。我不知道有什么。<*>inline 可能也有意义>>=，of 也可能有意义ParsecT。

相关：我最近在 lucid 中添加了一些内联编译指示，因为基准测试清楚地表明它们有所不同；但OTOH你不应该把它们撒在所有东西上。