It has been my habit to try and use braces over brackets under the assumption that it is somehow nicer, even though it is often less transparent.
Now that I question that assumption, it seems to have nothing in its favour, and plenty against it. Perhaps I'm overlooking something, but here's how I see it.
Possible justifications:
Lower processing cost?
At some level, this is what I often imagined, but (in version 2) the opposite seems to be true.
Pedagogy. Easier for beginners and mathophobes?Documentation wrote:For a basic shape adjustment the parser tosses the accumulated transform matrix when it sees the '}' and builds the affine transform matrix by combining the stored adjustments in the TRSSF order. For ordered shape adjustments the parser outputs the accumulated affine transform matrix when it sees the ']'.
There is no order independent interpretation of a set of transformations, or even a neutral one.
Recognising that order matters is fundamental to any understanding of what's going on, and pretending it is some esoteric detail that one can set aside does not facilitate progress elsewhere.
For anyone wishing to follow the actual order of composition, the code is misleading. You need the TRSKF decoder ring.
Dropping duplicates reinforces the same message; that this is not a cumulative process, and adjustments are really just attributes which are replaced by subsequent definitions. (Maybe they were, originally)
Anyone expecting two steps to count as two steps will have to discard their intuition here, and probably suffer generalised doubts where they could be forging ahead.
Reducing the correspondence between code and results only impedes the process of discovery.
"Error" prevention?
What counts as error if you don't know the difference? You can cut-and-paste mystery code just as well or badly either way.
To anyone actually aiming for some result, mistakes should be announced by letting the code's effects be expressed.
Silently modifying the code only makes mistakes harder to locate and correct.
Compatibility with legacy code. OK, but let's move on to version 3.
First, note that version 2 syntax is still available for now, so version 3 syntax is only required to combine it with new functionality. But it seems to me that users seeking advanced functionality will be less interested in default ordering.
If version 2 syntax is ever phased out, older code will have to be rewritten regardless, so why not write adjustments in their effective order rather than preserve obfuscation?
Assuming that default ordering is retained in Version 3, the new syntax seems rather odd.
Why is ordering represented by operators?
It is generally meaningless to combine both systems within a single adjustment group:
What's the canonical position of an adjustment amongst cons-ordered adjustments?
Any system for reconciling them would be needlessly complex compared with just consing them correctly in the first place.
It seems to me that re-ordering must be a single function or parsing mode over the whole group, in which case the tidiest syntax would be a keyword/symbol either before, or first within, the group braces.
My real motivation for raising this issue stems from the punctuation increase in version 3, but I wanted to address this first, and maybe focus on syntax in a separate discussion.