Unison中应用Remote.pure.run为何未消除Remote能力约束

问题复现代码 #

在Unison开发中遇到如下问题，初始编写代码如下：

runGeneration :
  ([BasePair] -> Float)
  -> ([EntityFitness] ->{Random} [EntityFitness])
  -> [EntityFitness]
  ->{Random, Remote} [EntityFitness]
runGeneration = iterateGenDefault 0.8 0.5

bar = Remote.pure.run 'runGeneration

UCM中展示的定义签名如下：

⍟ These new definitions are ok to `add`:

  bar : Either
          Failure
          (([BasePair] -> Float)
          -> ([EntityFitness] ->{Random} [EntityFitness])
          -> [EntityFitness]
          ->{g, Remote, Random} [EntityFitness])

⍟ These names already exist. You can `update` them to your new definition:

  runGeneration : ([BasePair] -> Float)
                  -> ([EntityFitness] ->{Random} [EntityFitness])
                  -> [EntityFitness]
                  ->{Remote, Random} [EntityFitness]

按能力处理器的运行逻辑，调用Remote.pure.run本应消除对应的Remote能力约束，但上述输出中bar的签名仍保留了Remote能力要求，最初猜测问题是能力要求放在了签名的错误位置。

对照验证测试 #

为排查问题做了两组对照测试：

测试1：Random能力处理器效果验证 #

使用Random能力的简单示例，应用处理器后Random能力要求被正常消除，代码如下：

randFooH : Nat ->{Random} Nat
randFooH max = Random.natIn 1 max

randFoo max = Random.splitmix 1234 '(randFooH max)

UCM输出签名符合预期，Random能力被成功消除：

⍟ These new definitions are ok to `add`:

  randFoo  : Nat -> Nat
  randFooH : Nat ->{Random} Nat

测试2：自包含Remote能力处理器效果验证 #

验证是否为Remote能力的特有问题，编写自包含的Remote逻辑示例，应用处理器后Remote能力被正常消除，代码如下：

forkHelloH:  '{Remote} Nat
forkHelloH = 'let
  use Nat +
  use Remote await forkAt here!
  t1 = forkAt here! '(1 + 1)
  t2 = forkAt here! '(2 + 2)
  await t1 + await t2

forkHello = Remote.pure.run forkHelloH

UCM输出签名符合预期，Remote能力被成功消除：

⍟ These new definitions are ok to `add`:

  forkHello  : Either Failure Nat
  forkHelloH : '{Remote} Nat

问题根因 #

最初尝试部分应用能力处理器是为了调试问题，Unison的通用最佳实践是尽可能延后应用能力处理器。本次问题的根本原因是实现的部分函数未做能力多态处理。

内容的提问来源于stack exchange，提问作者bbarker