なぜ、Maybeのことを「失敗しうる計算」だと考えないべき(あるいは、考えるべき)か by Kory

関数型まつり2025
公募セッション25分
公募セッション

なぜ、Maybeのことを「失敗しうる計算」だと考えないべき(あるいは、考えるべき)か

Kory__3 Kory Kory__3
6

対象とする聴衆のレベル

Intermediate。do式(Haskell)/for式(Scala)/qdo!マクロ(Rust)などを使って、エラーが起こりうる処理を書けることを想定します。

セッションのテーマ

  • 理論
  • 入門

セッションの概要

関数型プログラミングの初学者向けの説明では、しばしば、Maybe(Scala/Rust のOption)は「失敗しうる」ような「文脈」/「計算」であると説明されます。Scala で言うfor { a <- f1(); b <- func2(a) } yield bが、Rust で言う question mark operator による early-return(let a = f1()?; let b = f2(a)?; Ok(b))と同等である、という観察を提示されることによって、Maybeが「失敗しうる計算」を表しているという言説に納得している方も多いかもしれません。

しかし、これらの例をよく観察してみると、「失敗しうる」のは「Maybe aを計算する処理片」などであって、個々のMaybe値は「失敗しうる」という性質を持っていないように見えてきます。特に、個々のMaybe値というのはJust xNothingという具体的な値であり、これらが「計算」や「文脈」の概念を内包しているようには到底見えません。Maybeによるdo/forが「失敗しうる処理」を表現できていることには(先程の Scala/Rust の対比から)納得できるかもしれませんが、Maybeそのものが失敗/成功の概念を果たして内包しているでしょうか。

この講演は、この(しばしば見落とされている)ギャップに焦点をあてて、「失敗しうる計算」という現象を、多段階計算/メタプログラミング的な視点を導入することで整理することを試みます。特に、以下の点について詳しく見ます。

  • Maybeの個々の値は本当に成功/失敗の概念を持つが、それ自体は early-return 的な操作とはかけ離れていること
  • それでも普段は、Maybeのことを(ナイーブに)「失敗しうる計算」だと考えるべきだということ
  • では、この概念の切り分けがいつ役に立つのか