Defining Row Constraints for Extensibility
The recommended pattern for ensuring a minimum set of fields while maintaining extensibility is the use of row variables. Instead of defining a strict record type, you define a type signature that requires specific fields and a variable representing the "rest" of the record. This prevents the type system from collapsing the record into a fixed nominal type, which would otherwise strip away any additional fields passed to the function.
In a row-polymorphic system, a constraint is typically expressed as: { field1 :: Type1, field2 :: Type2 | r }. Here, r is the row variable. By returning the same row variable r in the output, the function guarantees that any fields present in the input record—even those the function does not know about—are preserved in the output.
Preventing Incompatible Types
To prevent the accidental introduction of incompatible types or field collisions, use row subtraction or explicit row constraints. If a function must add a field that might already exist, the type signature should explicitly exclude that field from the row variable r to avoid ambiguity during unification.
Resolution in Higher-Kinded Types
When row-polymorphic records are nested within higher-kinded types (such as Functor or Monad), the compiler handles resolution through unification. The row variable is treated as a type-level parameter. When the higher-kinded type is applied, the compiler attempts to unify the provided record's row with the constraint's row variable.
If the record is wrapped in a container (e.g., Maybe { x :: Int | r }), the compiler maintains the row variable r inside the container's type parameter. This ensures that the extensibility is preserved even when the record is transformed via mapping functions, as the transformation operates on the value while the type system tracks the row variable across the functorial boundary.
Verification Pattern
To verify that your constraints are correctly implemented and not "slicing" the record, test with a record containing an unexpected field:
-- Expected: { x: 1, z: "extra" } -> { x: 1, y: 2, z: "extra" }
-- Failure: { x: 1, y: 2 } (The 'z' field was lost)
Note: This analysis assumes a compiler implementation similar to PureScript or OCaml. If you are using a custom type-erasure process, please specify if your records are implemented as fixed-offset structures or hash-maps, as this affects the runtime cost of row resolution.
purescript