If you go back to R3-Alpha you see a table of errors:
https://github.com/rebol/rebol/blob/master/src/boot/errors.r
Each error category is a BLOCK!. The idea is that during bootstrap, MAKE OBJECT! gets called on that BLOCK!.
The category has fixed fields (code: and type:) and then the other fields are definitions of error message templates. They're either just plain strings:
deprecated: {deprecated function not allowed}
Or they are a BLOCK! with substitution points in it. The substitutions are GET-WORD! with the names of the error fields (arg1, arg2, arg3). The substitutions don't have to be in order of their definition in the object:
expect-arg: [:arg1 {does not allow} :arg3 {for its} :arg2 {argument}]
When FENCE! arrived I had to change these:
expect-arg: [:arg1 "does not allow" :arg3 "for its" :arg2 "argument"]
Recently I decided that it got better if I used TIED-INTEGER, e.g. $1
expect-arg: [$1 "does not allow" $3 "for its" $2 "argument"]
Although this moved away from a concept I had of error messages using better names than arg1 arg2 and arg3. I had been thinking that errors would have meaningful names for the parameters.
But honestly, the thought of going through all the errors and naming their fields is harrowing. It's hard enough to name the errors themselves. And you couldn't beeline for this brevity.
So I decided to go with this...but...
Why Not Use Interpolation (REWORD $N mode)
And for that matter, do we really need a SET-WORD in the file?
expect-arg "$1 does not allow $3 for its $2 argument"
I think this is probably the right answer for the %errors.r file.
But is it the right answer for error templates in general? What if you want to literally say something like "don't use $1 in this slot"?
This could be guided by whether you use a string, or a block.
expect-arg "$1 does not allow $3 for its $2 argument"
dont-use-1 ["don't use $1 in this slot"]
So a plain string would be interpolated, whereas a block assumes you've broken up the message into parts already so the strings don't need processing.
This might seem to suggest that if you used a string as your error message template, your error arguments would actually be in a block passable to reword... but then, they couldn't be antiforms.
REWORD gets around this with evaluation, but do we want to say the error arguments in a block are metaforms... or you just don't use antiforms as arguments to errors?
I dunno. But I think the idea of "plain strings interpolate, blocks use conscious substitution of args by name" seems good.
So if you want to name an error field, you can... just like before.
expect-arg [:action "does not allow" :value "for its" :param "argument"]
But I think I'm okay saying we skimp on this in %errors.r specifically. We're not exactly building a semantic graph here.
And they're error messages... you're not supposed to be picking them apart. If it was information you were supposed to be processing it shouldn't have made it to being an error!