Lucretia - a type system for objects in languages with reflection

Object-oriented scripting languages such as JavaScript or Python gain in popularity due to their flexibility. Still, the growing code bases written in the languages call for methods that make possible to automatically control the properties of the programs that ensure their stability in the running time. We propose a type system, called Lucretia, that makes possible to control the object structure of languages with reflection. Subject reduction and soundness of the type system with respect to the semantics of the language is proved.

💡 Research Summary

The paper addresses a fundamental challenge in modern scripting languages such as JavaScript and Python: the tension between their highly dynamic, reflective object model and the desire for static guarantees about program behavior. While the flexibility of adding, removing, or redefining object fields at runtime enables rapid development, it also makes large code bases prone to subtle bugs that are hard to detect without a type system. Existing static type solutions (e.g., TypeScript, Flow, MyPy) assume a relatively fixed class or prototype structure and therefore cannot fully capture the effects of reflection and dynamic object mutation.

To bridge this gap, the authors introduce Lucretia, a novel type system specifically designed for languages that permit reflection. The core idea is to treat objects as record types consisting of a set of fields and a set of methods, and to make the possible transformations of these records an explicit part of the type system. Two transformation operations are defined:

1. Extension – when a new field is added at runtime (e.g., via setattr or Object.defineProperty), the original record type is transformed into a new type that includes the additional field. The system marks the new field as optional in contexts where it may not yet be present, preserving type safety for code that does not yet rely on it.
2. Shrinking – when a field is removed (e.g., via delattr), the type is adjusted to indicate that the field is now optional or may be absent, again ensuring that subsequent accesses are type‑checked against the updated shape.

These transformations are integrated into a subtyping relation so that a program can reason about objects whose shape evolves over time while still maintaining a sound static analysis.

The paper formalizes a small‑step operational semantics for a core language that captures the essential features of JavaScript/Python: variables, functions, record creation, field access, method invocation, and the reflective operations mentioned above. The heap is modeled explicitly as a mapping from object identifiers to records, and a separate heap type environment records the current type of each heap object. Typing judgments therefore involve both a conventional typing context Γ (for variables) and a heap typing Σ (for objects).

A comprehensive set of typing rules is presented:

• Variable and function rules follow standard λ‑calculus conventions.
• Record creation yields a record type whose fields are precisely those defined at construction time.
• Field access (obj.f) requires that the field f be present in the static record type; if the field is optional, the rule permits a runtime check.
• Method calls verify that the argument types match the method’s parameter types and that the return type is correctly propagated.
• Reflective operations have dedicated rules:
  • setattr(obj, f, v) checks that the value v conforms to the intended type τ, then updates Σ to map the object identifier to a record type extended with f:τ.
  • delattr(obj, f) updates Σ by removing f from the record type or marking it optional.
  • hasOwnProperty and similar inspection primitives simply query the current static record type without altering Σ.

The authors prove two central metatheoretic properties:

1. Subject Reduction – If a well‑typed expression steps to another expression, the resulting expression remains well‑typed under the same (or appropriately updated) typing environments. The proof carefully handles heap updates caused by reflective operations, showing that Σ evolves in lockstep with the operational semantics.
2. Soundness (Type Safety) – A well‑typed program cannot encounter a “field not found” or “method arity mismatch” runtime error. The proof proceeds by induction on the evaluation steps, leveraging the subject reduction theorem and the invariant that the heap’s runtime shape always conforms to its static type.

Beyond the formal development, the paper discusses practical considerations for implementing Lucretia in a static analysis tool. The analysis would interleave type inference with a traversal of the abstract syntax tree, updating the heap type environment whenever reflective statements are encountered. To handle prototype chains and multiple inheritance, the authors propose representing record types as composable structures and using intersection types to model overlapping fields. They also suggest visualizing type evolution to aid developers in understanding how object shapes change throughout execution.

In the related work section, Lucretia is contrasted with existing approaches. TypeScript and Flow provide structural typing but treat object shape as immutable after declaration, thus failing to model dynamic field addition. MyPy introduces gradual typing for Python but similarly assumes a static class hierarchy. Prior research on “type-and-effect” systems or “refinement types” touches on dynamic features but does not offer a unified treatment of reflection and heap‑typed objects. Lucretia’s contribution lies in its explicit heap‑type model and transformation rules, which together give a sound foundation for reasoning about truly reflective languages.

The conclusion emphasizes that Lucretia offers a viable path toward static verification of JavaScript/Python programs that heavily rely on reflection, without sacrificing the languages’ expressive power. Future work includes extending the system to handle higher‑order reflective constructs (e.g., dynamic code generation), optimizing the inference algorithm for large code bases, and integrating Lucretia into existing IDEs to provide real‑time feedback to developers.