How OCaml's Proposed Include Functor Syntax Reduces Repetition

A reverse-array example shows how to derive common module functions from a minimal implementation without an extra wrapper module.

チャンネル
Jane Street
公開日
2024年8月7日
動画
8:06
読了時間
3 分
スライド
4
原文
英語
YouTube で開く
スクロールすると動画は右下に小さくなって再生を続けます。字幕は閲覧言語に合わせて切り替わります。
閲覧言語2 言語で読めます
この記事はまだ日本語に翻訳されていないため、英語の原文を表示しています。
要約

30 秒でわかる

A Jane Street speaker demonstrates the experimental include functor syntax developed in its OCaml compiler branch and proposed for upstreaming. Starting with an array-mapping interface, he builds a functor that supplies derived operations, shows the conventional wrapper-module approach, and replaces it with the new syntax.

  1. 1A mappable interfaceThe interface provides map and iter along with mapi and iteri, which also pass a key. An array implementation uses integer keys.
  2. 2Reverse traversalA reverse-array implementation handles the empty array and visits elements from the end. Traversal order matters when the supplied function has side effects.
  3. 3Derive the remaining operationsMap and iter can be built from mapi and iteri by ignoring the key, so a reusable functor can implement the common pattern.
  4. 4The wrapper-module boilerplateThe conventional approach puts the minimal definitions in a module, includes it, and includes the result of applying the functor to it.
  5. 5Include functorThe proposed syntax applies the functor using preceding definitions in the current module, avoiding the explicit wrapper and extra includes.

ポイント

  1. A module interface can expose convenient functions that are derived from a smaller set of core operations.
  2. In the example, map and iter can be defined from mapi and iteri by ignoring the key argument.
  3. A functor can package those derived definitions for reuse across modules.
  4. The conventional approach wraps existing definitions in a module and includes both it and the functor result.
  5. The proposed include functor syntax applies a functor to preceding module definitions without that explicit wrapper.
全文

チャプターごとに整えた全文を読む

文字起こしのみ
01

A proposed module convenience

The speaker introduces include functor, developed in Jane Street's compiler branch and being considered for upstreaming. A Mappable signature illustrates the repeated implementation pattern.

I want to introduce include functor, a feature developed in Jane Street's branch of the OCaml compiler that we are working to upstream. It simplifies a common pattern: writing the core of a module and using the same reusable logic to fill in the rest. The compiler used in the demonstration is linked in the video description.

The Mappable signature
スライド 1 / 4The Mappable signatureThe signature defines map and iter alongside the key-aware mapi and iteri operations.

Consider a module type Mappable with a data type, a key, and four operations: map and iter, plus mapi and iteri, whose functions also receive the key. An array can implement this interface straightforwardly: its key is an int, its data type is an array, and the four functions can use the corresponding array operations.

02

Reverse arrays and derived functions

A reverse implementation defines indexed operations from the last element to the first. The ordinary operations can be derived by ignoring the index.

Now suppose we want another array module that traverses from back to front. The order matters when an iteration function has side effects. The key and data type remain the same, but mapi works backwards: it handles an empty array separately, applies the function to the last element to initialize the result, and then fills the remaining positions down to zero.

Reverse array traversal
スライド 2 / 4Reverse array traversalThe implementation walks backward and handles the empty array in mapi.

The reverse iteri is simpler: it uses a backwards for loop. But I don't want to write map and iter again. They can be derived from mapi and iteri by ignoring the extra key argument, and the same pattern applies whenever we implement Mappable. We could still provide a specialized implementation when efficiency calls for it.

03

A reusable functor and its boilerplate

The signature is split into a minimal interface and additional operations. Applying a functor conventionally requires a wrapper module and explicit includes.

A functor can package the common derivation. First I split the interface into Mappable_minimal, containing the types and indexed operations, and the full Mappable interface, which includes that minimal part and adds map and iter. The functor Make_map_iter takes a module M matching Mappable_minimal.

Inside Make_map_iter, map calls M.mapi with a function that ignores the first argument and otherwise applies the supplied function. Iter does the same with M.iteri. The compiler infers the expected signature, so we now have a reusable way to produce the two ordinary operations.

Applying that functor to the reverse-array definitions is awkward in the conventional syntax. I wrap those definitions in a module M, include M, and include Make_map_iter(M). This works, but it requires the extra wrapper and explicit inclusion; without an enclosing signature, M itself would also remain visible.

Applying the functor with a wrapper
スライド 3 / 4Applying the functor with a wrapperThe conventional version includes the module M and the result of Make_map_iter(M).
04

Using include functor

The new syntax applies the functor to prior definitions in the current module and includes the result. The speaker briefly notes that it also works in module types.

Include functor removes that wrapper. After writing the core definitions directly in the module, I write include functor Make_map_iter. Conceptually, it applies the functor to the definitions already present in the module and includes the result. I can therefore define only the core functionality and get the rest without repeating the extra module and includes.

The include functor syntax
スライド 4 / 4The include functor syntaxThe new syntax applies Make_map_iter to the preceding definitions without an explicit wrapper module.

The syntax also works in module types, where it includes the functor's module type, though that is less common than the implementation example. The documentation has more detail on that use.

同じチャンネルの記事

1:48:29EN
JSJane Street· 2026年10月16日How AI Is Changing Programming: John Krazit and Ron MinskyRon Minsky, John Krazit · Jane StreetJane Street’s AI tooling lead and the Signals and Threads host examine agent infrastructure, security, code review and the changing experience of writing software.コーディングエージェントDeveloper productivity評価(Evals)+2
1:36:37EN
JSJane Street· 2026年9月23日Aaron Bauer on Teaching Software Engineering in the Age of AIRon Minsky, Aaron Bauer · Jane StreetHow learning goals, active practice and editor design shape engineering education when models can generate the code.AI in EducationSoftware engineeringEducation+2
スライド 9 枚1:05:45EN
JSJane Street· 2026年9月11日Cyrus Omar on Live Programming and a Computational Commons for Humans and AICyrus OmarA demonstration of Hazel shows how immediate feedback, structured collaboration and carefully scoped permissions could support people and AI agents working together.Programming LanguagesHuman-AI Collaboration開発ワークフローとテスト+2
1:25:00EN
JSJane Street· 2026年9月2日Eric Mannes on Turning Messy External Data Into Trading ResearchRon, Eric Mannes · Jane StreetFrom commodity futures and an Excel risk system to point-in-time datasets and AI, Eric Mannes explains the domain knowledge behind data engineering at Jane Street.Data quality & curation開発ワークフローとテストInvesting+2
スライド 7 枚1:16:29EN
JSJane Street· 2026年8月26日Grant Sanderson and Alok Puranik: Positional Encodings Through Group TheoryGrant Sanderson, Alok Puranik · 3Blue1BrownStarting with assumptions about attention, they derive matrix exponentials and connect rotations, decay and Jordan blocks to RoPE and ALiBi.Transformers & attentionMathematics機械学習の基礎+1
27:39EN
JSJane Street· 2026年8月21日3Blue1Brown and Jane Street on Trading, Machine Learning and CultureGrant Sanderson, Nitya, In Young, Craig, Alok · 3Blue1BrownGrant Sanderson talks with Jane Street colleagues about market making, shared compute, research and the paths that brought them to the firm.Machine LearningFintechCompany Culture+2