Dyalog Workspace Decimal-Float Arrays and GNU APL Builds Without DECFLOAT: Silent Conversion on Load

Restoring a Dyalog workspace containing 128-bit decimal arrays into a GNU APL build without decimal-float support raises an unresolved interoperability concern. The goal is numeric fidelity across interpreter boundaries, but the workspace format is vendor-specific and version-sensitive. Dyalog 18.2+ ⎕SAVE/⎕LOAD cycle validates a trailing CRC-64 checksum, but that integrity check confirms bit-level structure rather than semantic data types. GNU APL builds lacking DECFLOAT support may coerce decimal-float arrays to 64-bit binary floats on load, and it is unclear whether any diagnostic is emitted.

Because ⎕LOAD replaces the active workspace wholesale, scripted restores cannot rely on the checksum alone to detect a lossy numeric conversion. Dyalog’s )COPY and ⎕CY mechanisms allow selective object transfer but do not preserve the original representation when the target interpreter cannot represent it. The question is whether this conversion is silent by design, whether current GNU APL releases signal a warning or error, and what verification pattern reliably detects the change before downstream calculations proceed.

Does a GNU APL build without DECFLOAT support emit any diagnostic when loading a Dyalog workspace with 128-bit decimal arrays? Is there a documented interpreter flag or workspace attribute that forces a load-time type check rather than a silent coercion? What post-load inspection of ⎕DR or ⎕FR confirms that numeric arrays retained their original precision?