首先,我明白了如何 iteratees的,不够好,我大概可以写一个简单的和越野车实现无再参考任何现有的.
我真正想知道的是为什么人们似乎发现它们如此迷人,或者在什么情况下它们的好处证明了它们的复杂性.将它们与懒惰的I/O进行比较有一个非常明显的好处,但这对我来说似乎非常像一个稻草人.我从来没有对懒惰的I/O感到舒服,除了偶尔hGetContents或者readFile大多数非常简单的程序之外我都避免使用它.
在实际场景中,我通常使用传统的I/O接口和适合任务的控件抽象.在那种情况下,我只是没有看到迭代者的好处,或者他们是一个适当的控制抽象的任务.大多数时候,他们看起来更像是不必要的复杂性,甚至是适得其反的控制倒置.
我已经阅读了很多关于它们的文章和使用它们的资料,但还没有找到一个令人信服的例子,实际上让我想到了"哦,是的,我也曾在那里使用它们".也许我只是没有读过正确的.或许还有一个尚未设计的界面,比我见过的任何一个都简单,这会使他们感觉不像瑞士军用链锯.
我只是患有非发明的综合症或者我的不安是否有充分根据？或者它可能完全不同于其他东西？
(GHC)Haskell是否有可能定义一个存在量化的新类型？我理解如果涉及类型类,则无法在字典传递实现中完成,但对于我的目的,不需要类型类.我真正想要定义的是:
newtype Key t where Key :: t a -> Key t
但GHC似乎并不喜欢它.目前我正在使用data Key t where Key :: !(t a) -> Key t.有没有办法(也许只是使用-funbox-strict-fields？)来定义一个与上面的newtype版本具有相同语义和开销的类型？我的理解是,即使有严格的字段取消装箱,仍然会有一个额外的标签字,尽管我可能完全错了.
这不是导致我出现明显性能问题的原因.让我感到惊讶的是,不允许使用newtype.我是一个天生好奇的人,所以我不禁想知道我的版本是否被编译成相同的表示,或者是否可以定义任何等效类型.