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

Question

There's Parsec 使用的抽象层，类型类 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 #-} 有利或不利.

当Stream Text实例已添加到 a commit from 2011
它附带 {-# INLINE #-}语用。

另一方面，Stream ByteString was touched last time in Feb 2008 ,
之前的提交是从 2008 年 1 月开始的初始导入。它没有任何 INLINE语用

因此，如果您认为拥有或不拥有 {-# INLINE #-} 是有原因的语用
在这些情况下，进行基准测试来证明您的情况。我不知道有
任何。内联 <*> 可能有意义和 >>=也是，ParsecT .

相关:我最近向 lucid 添加了一些内联编译指示，因为基准测试很清楚
表明他们有所作为；但是OTOH，您不应该将它们洒在所有东西上。