ponder-lab / Hybridize-Functions-Refactoring / #3870

89%

main: 90%

push

github

Refuse a function combining an element of a NumPy argument with another dtype (#1176)

* Refuse a function combining an element of a NumPy argument with another dtype

A call site passing a parameter a NumPy array, and a body comparing or combining a subscripted element of it with a tensor of another dtype, now fails with HAS_NUMPY_ELEMENT_DTYPE_COERCIONS (#1111). Eagerly the element is a NumPy scalar the operation converts; traced, the array is a tensor of its own dtype, and the operation raises. Whether the argument is an array is the engine's NumPy origin on the value the call site passes; the subscript's consumers are read as the #861 coercion check reads a parameter's, against the parameter's own dtype.

Unpacking, the issue's second case, is pinned as converting with a FIXME: a destructuring read is not yet told from an attribute read (wala/ML#1117).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NTnpjPjJj2aZy1ZkUD1eAn

* Read the element's own dtype, built against the engine snapshot

The divergence is now decided against the subscripted element's own tensor typing, not the parameter's: that a subscript keeps its tensor's dtype is the engine's fact, which the snapshot provides (ponder-lab/ML#1076). An untyped element decides nothing. The target points at 0.52.111-SNAPSHOT.

The unpacking pin's FIXME now names the iteration check (#830) as where the refusal will come from once wala/ML#1117 lands, and pins that check's answer today.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NTnpjPjJj2aZy1ZkUD1eAn

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

72 of 82 new or added lines in 4 files covered. (87.8%)

5816 of 6502 relevant lines covered (89.45%)

0.89 hits per line