博士

やっほー、ロボ子！今日はRustでモナドが実現されたってニュースを見つけたのじゃ！

ロボ子

博士、こんにちは。Rustでモナドですか！それはすごいですね。Haskellほどではないとのことですが、一体どういうことでしょうか？

博士

ふむ、どうやらトレイト実装の型制約が問題みたいじゃな。型推論のために、ちょっと冗長なガイダンスが必要になるらしいぞ。

ロボ子

なるほど。具体的には、どんなものが提供されているんですか？

博士

Functor、Applicative、Monadのtraitはもちろん、Bifunctorとかcontravariant functor、profunctorまであるみたいじゃぞ！Haskell風のdo記法のための`run!`マクロもあるらしい。

ロボ子

すごいですね！FunctorとBifunctorのDeriveマクロまであるとは。SemigroupとMonoidも提供されているんですね。

博士

そうそう！標準のFutureとIOモナドをラップするEffectモナドとか、FoldableとTraversable、RingとAlgebraまであるらしいぞ！

ロボ子

まるで全部入りのようですね！でも、なぜこのような試みがなされたんでしょうか？

博士

どうやら、実現可能かどうかの確認と、複雑な型シグネチャのshitpostが目的らしいぞ！

ロボ子

ええっ、最後の目的はちょっと意外です…！でも、Rustの能力が試される良い機会ですね。

博士

そうじゃな。generic associated types(GAT)のおかげで、高階型のサブセットを表現できるようになったのは大きいぞ。Functor階層の抽象化を実装できるようになったのは進歩じゃ。

ロボ子

確かにそうですね。でも、言語には制限があるとのことですが、具体的にはどんな制約があるんでしょうか？

博士

トレイト実装時に、トレイト自体が指定するよりも厳しい制約を要求できないのが問題みたいじゃ。例えば、HashSetなどの型引数に制約がある型では、Functorを実装できないらしい。

ロボ子

それは厳しいですね。制約をターゲット型に引き継ぐ方法がないというのは、設計上の大きな課題ですね。

博士

GATは高階型ではないから、Bindの実装例で言うと、2つのBindを合成する関数では、型がBindを実装することを保証するために、トレイト境界を追加して明確化する必要があるみたいじゃ。

ロボ子

なるほど。GATは規約に従う必要がないから、型チェッカーが結果の型を推論できない場合もあるんですね。高階型よりも多くの労力がかかるのは大変ですね。

博士

結論としては、RustはまだFunctor階層の準備ができていないみたいじゃな。基本的な抽象化は制約の種類があればうまくいくみたいじゃが。

ロボ子

残念ですが、Rustの型チェッカーが改善されれば、問題の一部は軽減できるかもしれないですね。今回のクレートは演習として、または新しい言語機能へのガイドとして考慮すべきとのことですね。

博士

そうじゃな。所有権と可変参照の区別はAPI設計の問題で、Applyはboxed関数に対してのみ実装可能みたいじゃ。Rustには制約の種類と高階型が必要じゃ！

ロボ子

今回のニュースは、Rustの型システムの奥深さを改めて感じさせてくれるものでしたね。勉強になりました！

博士

ロボ子、最後に一つ。もしRustが本当にモナドを理解したら、きっとこう言うじゃろうな…「所有権？そんなもの、Monadのbindで解決だ！」…って、ちょっと無理があったかのじゃ？