OCaml Weekly News

OCaml 5 のエフェクトハンドラーは型付けされていません。コンパイラは、実行されたエフェクトが処理されているかどうかを検査しないため、ハンドラーが欠けていてもクリーンにコンパイルされ、実行時に Effect.Unhandled で失敗します。私たちはそのための静的チェッカーを構築してきており、特に最も弱いと思われる部分についてご意見をいただきたいと考えています。

何をするのか。 コンパイラ自身の .cmt ファイルを読み込み、関数ごとのエフェクトセットを推論し、コールグラフの不動点伝播によって伝搬させ、ハンドラーサイトで処理されたエフェクトを差し引き、プログラムのエントリーポイントまで未処理のまま到達できる perform をすべて報告します。発見された問題には、エントリーから perform までの責任パスと、生成された witness プログラムが付属します。witness プログラムを合成し、コンパイルして実行し、エフェクトが実際に外部境界に到達した場合にのみ、その発見を確認済みとして報告します。

どのようにテストされているか。 ランタイムをオラクルとした差分テスト：ジェネレーターがプログラムを生成し、チェッカーの予測と実際にコンパイルされたプログラムを実行した結果を比較します。1000 個の生成プログラムにわたって、偽陰性は 0 件です。分岐のないプログラム：600 件、偽陽性なし。分岐のあるプログラム：400 件、5.3% の偽陽性（条件分岐の両腕を結合することによる）。witness は意図的にクラッシュメッセージをパースしません。5.4 でテストプログラムのうち 2 つについてエフェクトのペイロードが表示されなくなりましたが、何も壊れなかったため、これは便利でした。

否定的な結果（この投稿の理由）。 チェッカーが実際に発生したクラッシュを検出することを示したかったため、ドキュメント化された Effect.Unhandled 問題を修正したコミットのコーパスを構築し、各親コミットを分析しました。6 件中 0 件しか検出できませんでした。原因は、バグが存在するモジュールが私たちの環境でコンパイルされなかったため、アナライザーにそのコードが渡されなかったことです。バッチランナーは、まさにこの理由から「スコープ外」と「見逃し」を別々に報告するようになりました。

次に、eio、eio_main、picos、domainslib、riot、moonpool、miou に依存するすべての opam パッケージにわたって実行しました。dev-repo で重複を除去した後、85 のリポジトリが対象となりました。そのうち 38 がビルドを十分に完了して分析でき、合計 3,881 モジュールが対象となりました。ツールは 31 件のエスケープを報告しましたが、そのすべてが私たち自身の偽陽性でした。 4 つの原因があり、それぞれ指摘したコードを読んで判明しました：

1. 私たちは「Eio. 以下の何かを呼び出す」を「Eio ランタイムを必要とする」としてモデル化しました。コンストラクターや vtable ビルダーでは誤りです：Eio.Flow.Pi.source、Eio.Stream.create、Eio.Condition.create、Eio.Buf_read.parse_string_exn。
2. そのクライアント使用モデルを eio 自身のソースに適用しましたが、これはカテゴリーエラーです。eio は Eio ランタイムを必要とせずに自身を定義できます。
3. アプリケーション演算子を透過的に処理しませんでした。let@ env = Eio_main.run in body は ( let@ ) Eio_main.run (fun env -> body) であり、演算子が不透明だとそのアプリケーションの先頭が Eio_main.run でないため、スケジューラー境界が消え、プログラム全体がランタイムなしで実行されているように見えました。修正方法は、値の説明から %apply と %revapply を読み込むことで、@@、|>、およびプロジェクト自身が定義する演算子もカバーできます。

4. 例外を名前で指定している場合にのみ Effect.Unhandled ガードを認識していました。picos はキャッチオールとして書いており、その理由も示しています：

   | exception _exn ->
       (* This should only happen when not running under a scheduler.
          However, we don't match on a specific exception, because it
          depends on the OCaml version. *)
   

   私たちも同じ観察を独立して記録しており、その後 5.4 でエフェクトのペイロードが表示されなくなるのを目撃しました。これは同じ問題の反対側からのものです。

原因 1 と 2 は修正され、双方向でリグレッションテスト済みです。原因 3 と 4 は診断済みですが未修正です：修正の試みがテストスイートを壊したため、赤いままリリースするのを避けるためにリバートし、docs/LIMITATIONS.md に問題を起こした forester と picos のソースとともに記録しました。25 件のエスケープが修正され、6 件が残って説明済みです。

このツールがサードパーティーのコードで報告したすべてのエスケープは、私たち自身の偽陽性でした。誰かのコードで実際のバグを発見したことはありません。 これを明言することが重要だと考えています。

もし教訓があるとすれば、おそらくこれです：実際のコードに初めて向けたチェッカーは、主にチェッカー自身を測定しており、違いを判断するための唯一の方法は、指摘したソースを読むことです。

ご批評をいただきたい点。

• ライブラリコントラクトの出力はあなたにとって有用ですか？picos に対しては以下を生成します：

  module Picos
    Picos.Trigger.await                may perform {Picos.Trigger.Await}
    Picos.Fiber.current                may perform {Picos.Fiber.Current}
    Picos.Fiber.spawn                  may perform {Picos.Fiber.Spawn}
    Picos.Fiber.yield                  may perform {Picos.Fiber.Yield}
    Picos.Fiber.Maybe.to_fiber_or_current may perform {Picos.Fiber.Current}
    Picos.Fiber.Maybe.or_current       may perform {Picos.Fiber.Current}
    Picos.Fiber.Maybe.current_if       may perform {Picos.Fiber.Current}
    Picos.Fiber.Maybe.current_and_check_if may perform {Picos.Fiber.Current, ...unknown}
  
  module Picos_std_event__Event
    Picos_std_event__Event.sync        may perform {Picos.Trigger.Await, ...unknown}
    Picos_std_event__Event.select      may perform {Picos.Trigger.Await, ...unknown}
  
  module Picos_std_structured__Run
    Picos_std_structured__Run.spawn    may perform {Picos.Fiber.Spawn, ...unknown}
  

  セット内の ...unknown は、その関数において .cmt がないものを呼び出しているためコントラクトが不完全であることを意味します。きれいなセットに丸めて見せるよりも、それを示す方が望ましいと考えています。

  「このライブラリが呼び出し元に処理を求めること」の機械チェック済みの記述が README や CI に含まれる価値はあるでしょうか？

• 私たちが見落としている形は何ですか？effc 分岐ボディ内で実行されるエフェクト、動的に構築されたハンドラーレコード、データ構造を通じてコールサイトに到達するクロージャー（0-CFA はまだなし）については把握しています。把握していないものを教えていただきたいです。
• スケジューラーモデル（つまり、どのエントリーポイントがどのファミリーのエフェクトのハンドラーをインストールするか）はデータであって分析ではなく、models/schedulers.conf に記載されています。eio のエントリーは特定の行に引用されています。riot、moonpool、miou のエントリーは推測であり、そのようにラベル付けされています。修正を大歓迎します。
• 実際に本番環境で Effect.Unhandled クラッシュに遭遇したことがある方はいますか？実際の例が不足しており、「発生したが原因はあなたの設計では見えないものだった」という情報も含め、どんな手がかりでも歓迎します。

OCaml 5.3 以降が必要です。Texp_match のエフェクトケースリストが 5.3 で初めて拡張されているためです。CI は 5.3 と 5.4 で実行されます。

リポジトリ：https://github.com/manishpaulish/unhandled

アプローチが間違っていると言っていただいて構いません。

皆さんへ、

mirage-crypto* バージョン 2.4.1（https://github.com/ocaml/opam-repository/pull/30568%EF%BC%89%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%93%E3%81%A8%E3%82%92%E5%96%9C%E3%82%93%E3%81%A7%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B%E3%81%97%E3%81%BE%E3%81%99%E3%80%827%E6%9C%88%E4%B8%8B%E6%97%AC%E3%81%AE 2.2.0 以来、一連のリリースが続いています。その背景には、いくつかの方が LLM を使って実装の問題点を発見し、私たちがそれを修正しているという経緯があります。今後もさらにリリースが続く可能性があります。各月のリリース数を制限するよう努めています。このパッケージのメンテナーである私も、できることの限界（時間的な意味で）に近づいています。このソフトウェアをお使いの方は、https://robur.coop/#contact または GitHub Sponsors 経由での寄付をご検討ください。さらに嬉しいのは、コードを読んで、プルリクエストが来たときにレビューし、コードのクリーンアップに貢献していただくことです（LLM が生成した改善案をそのまま提出するのではなく、慎重にレビューした上でお送りください）。特に、今や誰もがレッドチームにいる状況ですから。

mirage-crypto のパフォーマンスはチェックの追加により若干低下しましたが、私が使用するハードウェアで観測する限りわずかな差です。独自のベンチマーク（bench/speed.ml が利用可能）を実施し、改善案を提案していただければ幸いです。

変更内容は修正とクリーンアップから公開されたアドバイザリーまで多岐にわたります。明確な境界が常にあるわけではありません。完全なリストは CHANGES ファイルまたはコミット履歴で確認できます。全員が最新リリースに更新し、以前のリリースは使用しないことを強くお勧めします。前述のとおりいくつかのアドバイザリーが公開されており、他の修正についてはアドバイザリーが不要と判断していますが（ただし、他の実装が同様の修正に対してアドバイザリーを発行する場合もあるため、ご注意ください）、特定の修正が重要だと思われる場合は ocaml/security-advisories への PR を提出することもできます。

修正の詳細は以下のとおりです。Eric Ebinger、Thomas Gazagnaire、Anil Madhavapeddy による報告に感謝します。また、mirage-crypto のレビュー、マージ、リリースに時間を割くことを可能にしてくれた Tarides にも感謝します。

どうも！

Rpmfile ライブラリ（RPM ファイルのパース用）の初のメジャーリリースと、Bytream ライブラリ（バイトのストリーミングと処理を行う最後のライブラリ）のマイナーアップデートを発表できることをうれしく思います。

let () = 
  let metadata = 
    In_channel.with_open_bin 
      "hello.rpm" 
      Rpmfile.Reader.from_channel_without_payload 
  in

  let name, release = Rpmfile.View.(name metadata, release metadata) in 
  Printf.printf "%s.%s\n" name release
  (* hello.1.3 *)

こんにちは！

ここ数ヶ月間取り組んできたプロジェクト oxbow を共有できることをうれしく思います。

dwm を使っていた頃に大きく影響を受けており、Hyprland や Niri などの他のウィンドウマネージャーからもいくつかアイデアを取り入れています。主な機能は以下の通りです：

• タグごとの設定（レイアウト、mfact、ギャップなど）
• even、diminish、dwindle、spiral、deck、monocle を含むタイリングレイアウト
• 4 方向へのスクロール（Niri 風）
• "alt-tab" 風のオーバービュー
• 純粋なフローティングレイアウト。oxbow はウィンドウのネイティブなドラッグとリサイズリクエストを尊重し、フローティングモードをより自然に感じさせます
• スクラッチパッド、スティッキーウィンドウ、ウィンドウスワロー、ギャップなど、dwm の人気パッチ
• タグ、出力、サイズ、位置などの初期設定を行う正規表現ベースのウィンドウルール
• oxctl を介した IPC 制御で、上記すべての設定、状態の照会、イベントのサブスクライブが可能

oxbow は opam でパッケージ化されていますが、Nix/NixOS でもインストールできます。

これが私の初投稿であることにお気づきかもしれません。このプロジェクトが OCaml への初めての挑戦だからです！自分がずっと欲しかったウィンドウマネージャーを作るために oxbow を書き、同時に OCaml を学びました。とても楽しい体験で、他のいくつかのプロジェクトでも OCaml を使っていく予定です。OCaml の強みを活かすよう最善を尽くしましたが、oxbow の内部や他の側面を改善するための提案、PR 等を大歓迎します。

よろしくお願いします！

皆さんこんにちは、

ocaml-cdp の初リリースを発表できることをうれしく思います。これは Chrome DevTools Protocol 向けの型付き OCaml ライブラリです。

皆さんこんにちは！

FP Launchpad が FUN OCaml 2027 をバンガロールで開催する ことを発表できることを大変うれしく思います！これはインドで初めての FUN OCaml 開催（そして初の主要な OCaml カンファレンス）となります。

FUN OCaml 2027 は、OCaml の愛好家とプロフェッショナルに捧げる 2 日間のオープンソースハッキングイベントで、OCaml の実世界への影響に焦点を当て、グローバルコミュニティを結びつけます。

イベント詳細

• 日程： 2027年1月25〜26日
• 場所： MLR Convention Centre、Brigade Millennium Campus、JP Nagar 7th Phase、バンガロール
• 形式： 1 日目はトーク（基調講演を含み、オンラインでライブ配信）、2 日目はハンズオンワークショップと共同ハッキング。

Call for Participation（CFP）が公開中！

CFP は 9月30日 まで受け付けています。初めて登壇する方、業界の実践者、学術研究者、オープンソースメンテナーなど、あらゆる経験レベルからの応募を歓迎します。

特に興味深いと思っているトピック：

• ビジネスや個人プロジェクトでの OCaml の活用方法
• エコシステムの OCaml ライブラリ、フレームワーク、ツール
• 2 日目にハッキングへの意欲を刺激するハンズオンデモ
• 実際のコードとその設計決定の背後にある推論への深堀り
• 経験談と学んだ教訓

すべてのトークはライブ配信され、watch.ocaml.org と FUN OCaml の YouTube チャンネル にアップロードされます。

• 提案を提出する： https://fun-ocaml.com/%EF%BC%88%E3%81%BE%E3%81%9F%E3%81%AF%E7%9B%B4%E6%8E%A5 CFP 提出リンク から）
• 最新情報をフォロー： FUN OCaml の各種ソーシャルチャンネルをフォローし、FUN OCaml Discord サーバーに参加（ウェブサイト参照）。

皆さんの提案をお待ちしており、バンガロールでお迎えできることを楽しみにしています！

注記： 今年インドで FUN OCaml を開催することを選んだ主な理由は、（a）学生とプロフェッショナルの両方でイベントを満席にしやすいこと、（b）高品質な制作録画を再び実現できることです。OCaml ビギナーワークショップへのより高い需要と参加者を見込んでいます。一方で、インドへの渡航が EU 域内への渡航より不便であることも理解しています。

スピーカーとして渡航費用に不安がある場合は、CFP フォームのチェックボックスにチェックを入れて財政支援を申請してください。また、早めに提案を送っていただければ、セッションが採択され次第すぐにビザ申請（ビザサポートを提供しています）を開始できます。

皆さんこんにちは、

ease-caml（opam にも掲載）をご紹介できることをうれしく思います。これは OCaml 向けのイージングライブラリです。

beta1 に引き続き、opam 2.6.0~beta2 のリリースを発表できることをうれしく思います。

このバージョンはベータ版です。安定版リリースに向けて、ユーザーの皆様にテストしていただき、これまで気づかれなかったバグを発見していただくことをお願いします。