Support Manually Specified Activity Information via Codual / Dual Type Parameters

[yebai]

This issue proposes supporting manually specified activity information—specifically, whether function arguments or variables are active or inactive—without making automatic, IR-level activity analysis a core goal of Mooncake.

This proposal keeps Mooncake’s core design simple while giving users explicit control over activity information and leaving the door open for future automatic activity analysis through external packages.

Motivation

Automatic activity analysis based on IR-level analysis is not a goal for Mooncake in the foreseeable future. Nevertheless, there is practical value in allowing users (or external tooling) to explicitly specify activity information and have Mooncake respect it during differentiation.

At the same time, such a mechanism would naturally enable future experimentation with automatic activity analysis implemented outside Mooncake.

Proposal

• Mooncake should allow users or third-party packages to manually specify activity information (e.g., active vs. inactive arguments).
• This information can be conveyed to Mooncake by utilising the type-parameter trick of Codual / Dual.
• Mooncake remains agnostic to how the activity information is produced, whether manually specified or automatically inferred elsewhere.
  Below is a simplified sketch illustrating how activity information can be encoded at the type level and consumed by Mooncake without IR-level analysis.

# Activity markers encoded as types
struct Active end
struct Inactive end

# Dual types carry activity information as a type parameter
Dual{Active, T}
Dual{Inactive, T}

# Example function
f(x, y) = x^2 + y

# Manual activity specification, the idea is 
x = Dual{Active}(3.0)     # participates in differentiation
y = Dual{Inactive}(2.0)   # treated as constant

f(x, y)

In this setup:

• x is marked as active and contributes to derivative computation.
• y is marked as inactive and is treated as a constant.
• Mooncake’s differentiation logic dispatches on the activity type parameter rather than inferring activity

The above example focuses on Dual, but the same idea applies equally to Codual. A third-party package could later aim the construction of Dual{Active} and Dual{Inactive} values based on its own activity analysis.

Scope and Non-Goals

• Primary focus: Manual specification of active and inactive arguments.
• Non-goal: Implementing automatic IR-level activity analysis within Mooncake.
• Secondary benefit: Enabling future automatic activity analysis via third-party tooling without changes to Mooncake’s core.

Courtesy: #455 (comment)