Question

Parsec使用的

There's抽象层，类型为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的{{1}}实例中的Stream没有内联？

如果所有这些功能都被内联，或者没有，或Text和ByteString是如此不同，我们应该内联一个而不应该内联另一个？

Answer 1

我猜没有真正的理由。可能没有人注意，进行基准测试并表明有利于或反对{-# INLINE #-}。

在a commit from 2011中添加Stream Text个实例时它带有{-# INLINE #-} pragma。

另一方面，Stream ByteString was touched last time in Feb 2008，从2008年1月起，前一次提交是初始导入。它没有任何INLINE pragma

因此，如果您认为有或没有{-# INLINE #-} pragma的理由在这些情况下，制作基准来证明你的情况。我不知道有任何。内联<*>和>>= ParsecT也可能有意义。

相关：我最近添加了一些内联编译指示清晰，因为基准清楚表明他们有所作为;但是OTOH你不应该把它们撒在一切。

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

1 个答案: