In thinking about the variable arity question...as well as string interpolation...I started wondering if maybe giving ECHO a string should imply interpolation.
Look at this line from the HTTP server stress test:
print [{CLIENT} n {: Will read} partial {/} total {bytes}]
This isn't really even the spacing that I wanted. Getting that would be laborious:
print [
{CLIENT} unspaced [n {:}]
{Will read} unspaced [partial {/} total] {bytes}
]
I've made this a little better with GET-BLOCK!s reducing and the resulting BLOCK! implying unspacedness:
print [
{CLIENT} :[n {:}] {Will read} :[partial {/} total] {bytes}
]
That's cool when you're building code up programmatically, but this is a statically templated string. Being forced to be messier than that sucks.
But With Interpolation...
echo {CLIENT $n: Will read $partial/$total bytes}
I kind of like the idea of defaulting to saying that if you don't use delimiters like $(...) then it assumes you're using a simple WORD!, and it wouldn't try to read any further than that. So it would see dots or slashes as terminal--as above. But you could put things like field selections or function calls in a group, like $(now/hour) for example.
Anyway, the concept here would be that if you give ECHO a string it would act like PRINT INTERPOLATE of whatever that string was. And then, if you give it a BLOCK! it would have the literalness that helps API clients splice values directly.
What's a bit annoying here is that being able to actually have $XXX access environment variables is extremely handy in scripting. So maybe we could say @XXX are language variables and $XXX are environment variables? :-/ I don't know.