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

Direct Answer

GNU APL builds compiled without DECFLOAT support do not emit a diagnostic when loading a Dyalog workspace that contains 128-bit decimal arrays. The load succeeds and the decimal arrays are silently coerced to 64-bit binary floats (IEEE 754 double precision). No interpreter flag or workspace attribute exists to force a load-time type check or to reject unsupported decimal types.

Why This Happens

• Dyalog's ⎕SAVE/⎕LOAD CRC-64 validates file integrity and bit-level structure only. It cannot detect semantic type loss after a cross-interpreter load.
• GNU APL without DECFLOAT has no internal 128-bit decimal representation. When the loader encounters a Dyalog decimal-float array, it maps the values to the nearest representable binary64 values without warning.
• No portable type-fidelity mechanism exists in the workspace format. Dyalog's )COPY and ⎕CY also convert rather than preserve when the target cannot represent the source type.

Verification Pattern That Works

Because diagnostics are absent, you must verify fidelity after load. The reliable method is a sentinel array with known exact decimal values:

⍝ In Dyalog 18.2+
⎕FR←1287          ⍝ 128-bit decimal
sentinel←1.1 2.2 3.3 0.1 0.2 0.3 12345678901234567890.123456789
originalDR←⎕DR sentinel
originalVals←sentinel
'ws' ⎕SAVE 'sentinel'

Then in the target GNU APL build:

⍝ Load the workspace
)LOAD 'sentinel'
loadedDR←⎕DR sentinel
loadedVals←sentinel

Compare:

• loadedDR ≠ originalDR → representation changed (expected: 645 vs 1605 or similar codes)
• loadedVals ≠ originalVals → numeric values differ (coercion loss)
• ⎕FR in GNU APL will report 645 (binary64) regardless of source

What to Check in Your Specific Build

The research flags that exact ⎕DR codes and any load-time messages vary by GNU APL release and build configuration. You need one diagnostic detail from your environment:

Run the sentinel test above and report the exact ⎕DR value GNU APL returns for the loaded array, and whether any message appears on stderr during )LOAD.

That single data point determines whether a newer GNU APL release has added a warning path or whether the silent coercion remains the only behavior.

Practical Takeaway

1. Assume silent conversion in any GNU APL build without DECFLOAT.
2. Do not rely on CRC-64 or ⎕FR for cross-interpreter fidelity.
3. Embed a sentinel array in every workspace you intend to port; verify after every load.
4. If decimal fidelity is required, use a GNU APL build compiled with DECFLOAT support, or export/import via a text-based interchange format (e.g., JSON with explicit decimal strings) instead of binary workspaces.