在传播过程中IO是否应该内联运行？

Question

我正试图用Idris写一个玻璃钢库。此库设计为在单个线程环境中运行。未来实现Monad和Align。我想用以下简化类型签名来实现函数：

createFutureResolveLater : (Future a, a -> IO ()) -- later time

createFutureResolveNow : a -> IO (Future a) -- current time

pure : a -> Future a -- before everything

align : Future a -> Future a -> Future (These a b) -- min of two times

join : Future (Future a)) -> Future a -- max of two times

exeEvent : Future (IO a) -> IO (Future a) -- ??

simultaneous : Future a -> Future b -> Future Bool -- min of two times

subFuture : Future a -> (a -> IO ()) -> IO ()

在我看来是显而易见的

simultaneous a a, simultaneous a (fmap f a), etc.

应该是一个决意为真的未来。

在……里面

do
    oe <- exeEvent ie
    let s = simultaneous oe ie
    ...

我们是否应该下定决心去实现呢？

在反应性香蕉中，s是假的。见mapEventIO in http://hackage.haskell.org/package/reactive-banana-1.2.1.0/docs/Reactive-Banana-Frameworks.html

在反射中，s也很可能是假的。见performEvent in https://daig.github.io/reflex/Reflex-PerformEvent-Class.html

为什么这些库作者选择s为假？

Answer 1

想弄清楚你在问什么。我认为你想知道如何解释IO的行动需要时间，不是吗？因为如果IO动作是瞬时的，这将不是一个问题。尽管我仍然有一个问题，那就是IO操作块是在将来发生之前还是异步调度？

如果这是一个非阻塞调用，我会说它应该等到IO操作完成。(我还会称它为schedFuture或其他类似的名称，以便清楚地表明它不阻塞。)否则，您可能在过去的情况下，Future的时间，但价值仍然是不可用的，这可能会搞乱逻辑的函数合并事件，等等。

如果这是阻塞呼叫，我会提供

waitFuture :: Future a -> IO a

让用户处理剩下的部分(例如，如果他们想保留时间，他们可以在最初的将来使用fmap (const x)，如果他们想在操作完成时使用now :: IO (Future ())，等等)。如果你能给他们起个好名字的话，为他们提供组合子可能是值得的，否则他们就会很容易，我就会去玩。

我还发现，让这样的系统区分“道德瞬间”的IO行为和可能阻止的行为是很有帮助的。我认为这与javascript对异步和常规堆栈调用的区分是并行的。有很多像这样的模糊问题，相应的明显答案往往取决于这种区别。