Haskell“hackage”是否与两个具有相同名称的不同类型的签名重叠？

Question

在探索图书馆时，我看到了以下代码。

https://hackage.haskell.org/package/text-2.0.2/docs/src/Data.Text.Internal.Lazy.Fusion.html#unstreamChunks

看

unstreamChunks

.

此代码将 Char 流捆绑成块并将其作为文本返回。它在此过程中创建和使用可变数组。

我认为奇怪的是

inner

的类型签名，即

inner :: MArray s -> Int -> s -> Int -> ST s Text

。 （将鼠标悬停在

inner

上，如果需要，可以查看类型签名）。

所以，（表示

s

和

MArray s

状态的类型

ST s Text

）和（表示

s

中状态的类型

Stream

）与“s”相同。 （第三个参数类型

s

来自

Stream next s length

。）

unstreamChunks

使用

runST

。这意味着

s

中的

ST s Text

与

s -> (s, Text)

相同，应该覆盖

RealWorld

。导致

runST :: (forall s. ST s a) -> a

并因此将

s -> (s, Text)

应用于

s

= RealWorld.

但是，

s -> Step s Char

中的

Stream Char

取决于具体应用中的具体类型

[Char]

。 我将在下面向您展示一个示例。

https://hackage.haskell.org/package/text-2.0.2/docs/src/Data.Text.Lazy.html#pack https://hackage.haskell.org/package/text-2.0.2/docs/src/Data.Text.Internal.Fusion.Common.html#streamList

pack = unstream . streamList . map safe

.

s -> Step s Char

来自

Stream Char

是

   next [] = Done
   next (x : xs) = Yield x XS

这完全取决于具体类型

[Char]

并且不会为

RealWorld

工作，或者它不会为

runST

进行类型检查。

我不知道它是如何工作的！！但效果很好。 所以，我认为来自

s

的两个不同类型的参数

inner

是不一样的。

Stream Char

和

State s

没有任何关系。 没有组合两个不同

s

类型值的代码。

inner

的类型签名甚至不是 Haskell 代码。这只是黑客的预览。

所以，我得出结论，hackage 的自动生成的类型签名不会改变原始类型参数名称，即使它重叠。

我想确认我的猜测是否正确。

此外，如果我错了并且这两种类型实际上是相同的，如果您能解释为什么代码运行良好，我将不胜感激。