Attributes · Gotchas & Edge Cases · Practice Question
How Does Applying `s#` Differ From Applying the Other Attributes?
Question
What is the key behavioural difference between applying the sorted attribute and applying the other three attributes?
Solution
/ `s# modifies the original variable IN-PLACE — no reassignment needed
n: til 10
`s#n
attr n / `s — n itself was modified
/ All other attributes require reassignment to take effect
n: `g#n / must assign back
attr n / `g
/ Demonstrate the difference clearly:
m: 1 2 3 4 5
`g#m / does NOT change m
attr m / ` — m has no attribute
`s#m / DOES change m
attr m / `s — m was modified in-placeExplanation
KX's documentation notes that setting the sorted attribute on a list that is already sorted does not make a copy, while setting any other attribute does. So when the list is already sorted, s# changes the original object directly, even without reassignment. This is unique among the four attributes.
When you write `g#n, `u#n, or `p#n without capturing the result, the attributed copy is returned as the expression result but the original variable is not modified:
n: 5 3 4 1 2
result: `u#n / result has `u, n is unchanged
attr result / `u
attr n / `This is a common source of bugs: a developer applies `g# to a table column expecting it to take effect, but the attribute silently disappears because the result was not assigned back.
When you write `s#n, the original n is modified directly — the expression also returns the attributed list, but the modification has already happened to n itself:
n: til 10
`s#n / n is modified
attr n / `s — changed without reassignmentPractical consequence: when applying g# or p# to a column in a table, use the functional form that modifies in-place:
@[`trade; `sym; `g#] / modifies trade`sym in-place using @
/ or:
update `g#sym from `trade / also modifies in-place (table update form)The expression `g#trade`sym alone would not modify the table — the result is discarded.