While reordering the refinements wasn't specifically pertinent to the order of mandatory parameters... the idea of a major design change which moved the refinements suggested part of a "cultural shift" where a new guiding principle would be spread across the system...
...though the idea I've come up with is that refinements could occupy any position relative to the mandatory arguments (before, after...between!) and that these positions are part of the interface, to say where they would be if they were used.
-
This removes a degree of choice at the callsite (which was a limited/illusory choice: only letting you pick the order once the mandatory parameters had been gathered).
-
...but it adds a more meaningful degree of choice to the definer of the interface, to position optional parameters at locations which make the most sense relative to the mandatory parameters and each other
-
...and APPLY becomes the fallback for getting arbitrary choice of any order you like, which I think is likely a best choice if you find yourself ever using more than one refinement for some reason.
So that drops the idea that there's some universal rule or renaissance coming, and it just kind of is what it is.
Basic Sensibility: What Do Callsites Need
I think in the example of APPEND, it's actually infrequent to be appending to a lengthy literal as the first argument. The second argument is more likely to be long:
; unlikely
append [
blah blah blah blah
blah blah blah blah
] item
; more likely
append data [
blah blah blah blah
blah blah blah blah
]
Because you don't typically mutate literal data (and often in Ren-C, you're prohibited from doing so, in a "runs more than once" context such as a function body or loop body).
But in other cases, the question would be "is there a data transformation that can't be understood unless you had the configuring parameters first".
I mention DELIMIT above in the thread. But COMPOSE:PATTERN is maybe an even bigger example:
compose:pattern [
some bunch of {{code that}} <spans>
#multiple lines
[and could go on for pages]
] ${{}} ; afterthought...
compose:pattern ${{}} [ ; forethought
some bunch of {{code that}} <spans>
#multiple {{lines}}
[and could go on for pages]
]
If REPLACE were non-mutating, it might similarly seem like a situation where the substitutions should come first to help you interpret the effects on literal arguments:
name: "Bob"
replace '*** name --[
Dear ***,
We value you as a customer, and...
]--
So long as it mutates, the idea becomes less obvious, due to the unlikeliness of literal code you're looking at which the configuration would help understand if seen beforehand.
Anyway, I don't think there's a last word on this particular design point, but the pressure to find universal consistency is lessened.
