问题标签 [unsafe-perform-io]

In this pseudocode block:

Is it safe to use unsafeIOToSTM? The docs say:

• The STM implementation will often run transactions multiple times, so you need to be prepared for this if your IO has any side effects.

  Basically, if a transaction fails it is because some other thread wroteValueToLocalStorage and when the transaction is retried it will return the stored value instead of fetching from the database again.

• The STM implementation will abort transactions that are known to be invalid and need to be restarted. This may happen in the middle of unsafeIOToSTM, so make sure you don't acquire any resources that need releasing (exception handlers are ignored when aborting the transaction). That includes doing any IO using Handles, for example. Getting this wrong will probably lead to random deadlocks.

  This worries me the most. Logically, if fetchValueFromDatabase doesn't open a new connection (i.e. an existing connection is used) everything should be fine. Are there other pitfalls I am missing?

• The transaction may have seen an inconsistent view of memory when the IO runs. Invariants that you expect to be true throughout your program may not be true inside a transaction, due to the way transactions are implemented. Normally this wouldn't be visible to the programmer, but using unsafeIOToSTM can expose it.

  key is a single value, no invariants to break.

为什么accursedUnutterablePerformIO（又名inlinePerformIO）实施

并不是

?

我有

unsafePerformIO这对我来说似乎是合法的使用。但我很想知道如何避免它！已经有这种用途的模式了吗？

我在 Haskell 图书馆的限制区闲逛，发现了这两个邪恶的咒语：

然而，实际差异似乎只是在runRW#和之间($ realWorld#)。我对他们在做什么有一些基本的了解，但我没有得到使用一个而不是另一个的真正后果。有人可以解释一下有什么区别吗？

所以今天我突然想到我可以表演一个小把戏。

这是一个奇怪的小函数，它接受一个（可能未计算的）类型值a，将其计算为 WHNF，然后将error/转换undefined为Nothing. 它确实有效。我可以在 Prelude 部分函数上使用它，比如toEnum和head。

这似乎是 Prelude 的许多部分函数问题的包罗万象。而且，至少在我对它的原始测试中，它似乎工作得很好。然而我还没有看到它在任何地方使用过，而且我看到很多人抱怨 Prelude 有部分功能。我总是很警惕，并通过unsafePerformIOIO将错误分解以检测它只是危险信号。

所以我的问题是：我在这里没有看到什么基本问题？这实际上是合理的使用unsafePerformIO吗？运行起来是否过于昂贵（我没有对它进行性能基准测试）？是否存在一些奇怪的语义错误（seq可能涉及 ）使其无法用于生产？

我正在尝试做这样的事情：

基本上，这是一个迭代列表的计算，将每个元素映射到其他元素，并在过程中使用内部私有状态。具体的ini, upd, 和fin我想到的来自 C 库，但它们保证“表现良好”，因为它们只是分配新状态，执行唯一副作用是修改状态的计算，然后解除分配状态. 我相信，这意味着我可以安全地放在unsafePerformIO前面并获得一个纯函数：

现在我想做同样的事情，但使用conduit（或者，实际上，任何其他流媒体库）。但是，由于计算本质上是无效的，我希望我的管道是纯的：

甚至更好：

（我怀疑后者可能没有意义，因为看起来这个技巧对简单列表很有效，只是因为元素是纯的。）

理想情况下，我想对用户完全隐藏计算需要一个状态并进行外部调用的事实，并且只是假装它只是类似于 a scanl（或者mapAccum，正如conduit它所称的那样）。

这可能吗？如何使用conduit（或其他流媒体库）执行此操作？

假设我有一个外部函数：

该函数是纯函数，因此我想将其表示为 Haskell 中的纯函数：

（这里我使用allocfrom memory。）

unsafePerformIO我的理解是和之间的唯一区别unsafeDupablePerformIO是后者中的 IO 操作可以在不进行任何清理的情况下静默终止。

在我上面的例子中，基本上发生了两个 IO 操作： 1. 内存分配；2.外呼。我不关心2，因为它是纯粹的，但是我担心内存。

如果计算被静默中断，是否可以保证以这种方式分配的内存不会泄漏？如果外部功能还需要我必须分配/清理的临时存储并且我用于alloca此目的，那么它仍然可以安全使用unsafeDupablePerformIO吗？

人们普遍认为这unsafePerformIO不是类型安全的。这通常通过使用它来实现来演示unsafeCoerce：

正如我几年前所展示的，这种实现不是线程安全的。一个线程可以写入盒子，然后另一个线程可以在第一个线程可以读取之前再次写入盒子。哎呀！如何解决这个问题？

是否可以使用 unsafeCoerce （或其他一些不安全的功能）来“弥补”例如类型的 Typeable 约束？即，将类型从 a 更改forall v. v为存在forall v. Typeable v => v？

我的情况是，我有一些数据类型/函数可以处理所有类型a，但确实需要调用typeOf和/或调用toDyn它们。结果不会破坏参数性，但不可能说服类型检查器。

准确地说，我需要将某些类型转换为Dynamic然后再转换回来。然而，目前的要求Typeable阻止了诸如Functor,Applicative等类型类的实现。

（我知道存在另一种称为“约束归一化深度嵌入”的技术，以允许需要约束的类型仍然实现这些类型的类型。但是，这种技术不适用于包含循环的数据类型，因为降低操作将无限循环。）

那么有没有办法说服类型检查员在这里信任我呢？即使它很不安全？