⎕WC class definition persistence across Dyalog version upgrades with ⎕ML misalignment

Question

The persistence of ⎕WC class definitions across Dyalog major version upgrades remains ambiguous when the ⎕ML mixed-language flag setting differs between save and load sessions. A class definition saved in Dyalog 17.x embeds version-specific metadata that Dyalog 19+ may interpret through an updated class schema, potentially triggering WS FULL errors or silently omitting fields that do not conform.

The ⎕ML version gate further influences method dispatch in inherited classes, and the interaction between the flag's value at save time and the target workspace's setting is not uniformly documented across Classic and Unicode editions. This ambiguity creates a design decision point for environments migrating Dyalog versions while preserving ⎕WC-dependent workflows.

Does Dyalog 19+ retain the original ⎕ML version gate from a saved ⎕WC definition, or does it override it with the current workspace setting? When fields are silently omitted during cross-version loading, is there a mechanism to retrieve a list of discarded properties? Can the embedded version metadata of a ⎕WC definition be inspected without loading it into a target Dyalog release?

Tasadduq Burney · Answer

Direct Answer
Dyalog 19+ does not retain the original ⎕ML version gate from a saved ⎕WC class definition. At load time, the interpreter applies the current workspace ⎕ML setting, not the value active when the class was saved. There is no documented mechanism to retrieve a list of fields silently omitted during cross-version loading. The embedded version metadata of a ⎕WC definition cannot be inspected without loading it into a compatible Dyalog session.
Confirmed Facts vs. Likely Explanation
Confirmed: ⎕ML is a workspace-level system variable that controls language semantics and method dispatch. A workspace saved in Dyalog 17.x carries a binary format that later releases must interpret.
Likely explanation: Because ⎕ML is evaluated at the session level, class definitions are validated against the active ⎕ML rather than a persisted per-class gate. When the active value differs from the save-time value, schema validation may reject or drop fields. The exact conditions that produce WS FULL versus silent omission, and any divergence between Classic and Unicode editions, are not uniformly documented and should be treated as unverified until tested in your specific version pair.
Steps for This Case

Record the save-time ⎕ML value. In the target Dyalog 19+ session, set ⎕ML to that same value before loading the workspace. For example: ⎕ML←1.
If the class is available as source, re-create it in the target version rather than loading the binary workspace. This avoids cross-version schema translation entirely.
After loading, compare the class fields against your expected schema using standard Dyalog introspection. If properties are missing, treat the load as lossy.
If a WS FULL error occurs, it indicates a validation failure during load rather than a silent omission; adjust ⎕ML or rebuild from source.

One Detail That Changes the Recommendation
Are you migrating between Classic and Unicode editions, or staying within the same edition? The workspace binary format and ⎕ML behavior can differ across that boundary, which determines whether a direct load is viable or whether source reconstruction is required.

⎕WC class definition persistence across Dyalog version upgrades with ⎕ML misalignment

1 answer

Direct Answer

Confirmed Facts vs. Likely Explanation

Steps for This Case

One Detail That Changes the Recommendation

Your perspective belongs here.

1 question comment

Clarification on ⎕ML version handling