生产者 - 消费者使用任务
所有我见过SML生产者 - 消费者的实现都被迫依靠ref S（为了保持“睡眠”的项目队列），所以我倾向于说“不”。
拥有多个线程必然需要不纯（非功能性）操作。纯函数式编程将您的应用程序视为功能评估。同时评估两个东西并在它们之间传递数据的概念在此框架中没有意义。
尽管可以并行地评估一个函数的多个部分，就像在Haskell的``par运算符中一样，这与生产者 - 消费者问题不同，因此我认为你不能解决它以功能的方式。
有很多方法可以解决这个问题;每个都有不同的缺点。
例如，“put”可能每次都产生一个新的线程。这样，你根本不需要缓冲区。如果有很多请求进来，你会产生大量的线程，直到你的CPU比在实际执行它们时更忙线程切换。但是，这只是将问题从代码移入操作系统：在某个时刻，您总是必须同步访问内存中的变量。操作系统必须维护一个线程列表，并且访问这个列表必须同步。
要么限制线程的数量（然后“put”必须能够读取变量，同时线程可能会同时终止并减少它 - >同步访问）。或者你可能会因为线程太多而冒充资源。
当“put”被调用并且消费者可以收听消息时，您可以发布消息。但这只是实现线程“等待”的一种复杂方式。而且你需要一种方法来确保只有一个消费者获得这个信息。同样，你需要一些同步的数据结构。
因此，最终，它不是真正的赋值，这是问题，而是并发访问单个变量，无论您如何尝试，对于产品使用者的任何实现，您都必须能够执行此操作（或整体将单线程）。
是的。检查功能反应式编程（FRP），这与Concurrent ML（Norman的建议）有关，但功能完全正常。 FRP的语义高度“同时”，同时具有简单，精确，确定性，功能性的语义模型（时间函数）。
编辑：我引用了“并发”在这里，因为我不意味着一贯的经营（面向实现的）并发的概念，这是必要和不确定性，从而阻碍了实用&可靠正确的推理。
我没有在问题中看到多个线程的概念。请注意，纯粹功能抽象的*实现*可以使用并发性。并发本身不需要显示语义/用户模型。另外，* lazy *函数式编程非常像并发。许多暂停计算（thunk）正在等待其他计算的需求（减少到弱头正常形式），在这一点上它们暂时活跃起来。尽管所有这些实现都是“并发”（协同式），但语义是纯粹而简单的，因此允许轻松，正确的推理。 – Conal 2009-08-06 17:27:30