promise-race/all take just promise list

[conao3]

promise-race が単に promise のリストを受け取れるようにしました。

(promise-chain (promise-race (vector (do-something-async 2 "2 seccods")
                                     (do-something-async 1 "1 second")
                                     (do-something-async 3 "3 secconds")))
  (then (lambda (result)
          (message "result: %s" result))))

(promise-chain (promise-race (do-something-async 2 "2 seccods")
                             (do-something-async 1 "1 second")
                             (do-something-async 3 "3 secconds"))
  (then (lambda (result)
          (message "result: %s" result))))

[chuntaro]

1からLisp用のAPIとして実装していたら、間違いなく(&rest args)でしょうけど、promise-allはvectorでないと内部の処理が効率悪くなるので、vectorの引数を受け取るのは仕方ないというか…
(promise-raceは引数は何でもいいのですが、直行性の為にvectorになってます)
(&rest values)だとvectorを渡せるように見えないので、もう少し検討させてください。

(&optional value-or-vector &rest rest-values) の方がまだ分かりやすか？他のライブラリで似た様な事をしてないか調べてみます。

[conao3]

lsp-modeでの採用も見えているようですし、ここらへんの利便さは重要かなぁと思っています。
後方互換を落とす変更をどれだけ許容頂けるのか分かりませんが、vectorで受け取る機能を落として可変長引数のみで受け取るだけにすると外部に公開するAPIとしてはとても分かりやすいと思います。

また、promise-allですが、複数のpromiseを渡すとして普段の利用ではせいぜい5個くらいまでではないかなと思っています。
featherで採用したときはpromise-allに100個オーダーのpackage-installを入れることを検討しましたが、それは100並列でMELPAにアクセスするということで、 promise-concurrentの採用となりました。この場合、promise-allに渡る引数の数はworkerの数だけ(CPUスレッドの数だけ。一般的には8くらいでしょうか。)となります。

私個人の意見としましてはElispで標準的に扱う数においては、vectorを積極的に使うより単にlistを使う方がアクセス方法の一貫性という意味で利便性が勝ると思っています。
例えば先程の長さ8のvectorを扱う場合と長さ8のlistを扱う場合で何%性能が落ちるのでしょうか。
そしてそれはemacs-promiseを使う最も大きな利点である、「UIをブロックしない、簡単な並列処理の記述」を提供するために絶対に回避せねばならない性能低下なのでしょうか。