The list operators built on returnBreakStringsIntoTypeSugarInstruction — <sort>, <shuffle>, <sortIndices>, the index-returning operators and the counting operators — read bare string children only when every child is a string or a reference. A single authored component among them turns the whole sugar off, and the bare strings are then dropped with doenet-w0015.
The result is that a referenced component and an authored one behave differently in the same position:
<number name="n">5</number>
<sort>$n 3</sort> <!-- 3, 5 -->
<sort><number>5</number> 3</sort> <!-- 5, and a warning that " 3" is not a valid component to sort -->
Measured on infer-list-value-type at cba00a15a:
| Document |
Result |
Warning |
<sort><number>5</number> 3</sort> |
5 |
String " 3" is not a valid component to sort. Ignoring. |
<sort>$n 3</sort> |
3, 5 |
none |
<sort type="number"><number>5</number> 3</sort> |
5 |
String " 3" is not a valid component to sort. Ignoring. |
<sort>5 3</sort> |
3, 5 |
none |
The third row is the one that says where this belongs. The drop happens identically with an explicit type="number", so it is not a consequence of type inference and it is not new — it is how the guard has always worked. The behavior is deliberate enough to have a test of its own, "string children ignored when mixed with non-string children with warning" in sort.test.ts, and a matching one in shuffle.test.ts.
It is still worth revisiting. An author who writes <sort><math>d</math> a <math>b</math></sort> almost certainly means to sort three values, and the warning fires on a document that looks reasonable.
The shape of a fix, per the review comment that raised it: let non-reference components through the guard and rely on returnGroupIntoComponentTypeSeparatedBySpacesOutsideParens with forceComponentType: false, which already passes components through untouched.
Two things to settle before doing it:
- Whitespace-only strings between components. A
<sort> written across several lines has string children today that are pure whitespace. They must not become values. Type inference already ignores them — it splits on whitespace and discards empty tokens — but the grouping helper's behavior on them needs checking rather than assuming.
- What an inferred type means when components are present. Inference reads the bare strings only.
<sort><math>x</math> 1 2</sort> would infer number from 1 2 while the authored child is a math, which is the same mixture that already arrives through references and is handled downstream by allAreNumeric — but it should be confirmed, not assumed.
Both existing tests would change, so this needs its own changeset and cannot ride along with an inference PR.
Raised by Copilot in review of #1847.
🤖 Generated with Claude Code
https://claude.ai/code/session_016YdEWccVoUPCJoDYxKmHRo
The list operators built on
returnBreakStringsIntoTypeSugarInstruction—<sort>,<shuffle>,<sortIndices>, the index-returning operators and the counting operators — read bare string children only when every child is a string or a reference. A single authored component among them turns the whole sugar off, and the bare strings are then dropped withdoenet-w0015.The result is that a referenced component and an authored one behave differently in the same position:
Measured on
infer-list-value-typeatcba00a15a:<sort><number>5</number> 3</sort>5String " 3" is not a valid component to sort. Ignoring.<sort>$n 3</sort>3, 5<sort type="number"><number>5</number> 3</sort>5String " 3" is not a valid component to sort. Ignoring.<sort>5 3</sort>3, 5The third row is the one that says where this belongs. The drop happens identically with an explicit
type="number", so it is not a consequence of type inference and it is not new — it is how the guard has always worked. The behavior is deliberate enough to have a test of its own,"string children ignored when mixed with non-string children with warning"insort.test.ts, and a matching one inshuffle.test.ts.It is still worth revisiting. An author who writes
<sort><math>d</math> a <math>b</math></sort>almost certainly means to sort three values, and the warning fires on a document that looks reasonable.The shape of a fix, per the review comment that raised it: let non-reference components through the guard and rely on
returnGroupIntoComponentTypeSeparatedBySpacesOutsideParenswithforceComponentType: false, which already passes components through untouched.Two things to settle before doing it:
<sort>written across several lines has string children today that are pure whitespace. They must not become values. Type inference already ignores them — it splits on whitespace and discards empty tokens — but the grouping helper's behavior on them needs checking rather than assuming.<sort><math>x</math> 1 2</sort>would infernumberfrom1 2while the authored child is a math, which is the same mixture that already arrives through references and is handled downstream byallAreNumeric— but it should be confirmed, not assumed.Both existing tests would change, so this needs its own changeset and cannot ride along with an inference PR.
Raised by Copilot in review of #1847.
🤖 Generated with Claude Code
https://claude.ai/code/session_016YdEWccVoUPCJoDYxKmHRo