I've written up my concerns about source-level MAP!s...a big one being "when (if ever) do you evaluate":
{ Rethinking Braces }... as an array type? - #25 by hostilefork
LOAD-time is before binding so that won't work. And then if you do it at any other time, you wind up with something that's just a shorthand for MAKE OBJECT!...and will still need evaluation.
I don't see anyone being satisfied with the behavior of:
read/custom http://some.site/ #(
Accept: "text/x-rebol"
Upgrade-Insecure-Requests: secure-base + 1
)
This is no good if it's redefining + to be 1. So if we know that's bad, what's left that's good?
If the issue is wanting to have a way of saying "I'm giving you a lower, rawer form of input that's not dialected" then maybe that's a good fit for the @[...] array type. "This is just keys and values, I promise".
read/custom http://some.site/ @[
Accept: "text/x-rebol"
Upgrade-Insecure-Requests: 2
]
This tactic is taken with UNPACK, for example....which I think is clever.
But maybe the default of when you get a BLOCK! is "this is information in the READ/CUSTOM dialect", whatever that means. And its job is to produce the keys and values somehow. But you can bypass that intelligence with something that requests unintelligence.
I don't think any particular idea should be off the table
Definitely good to clock some time with other languages (which I've been doing recently) and to ask if there are lessons there to be learned.
I went down the road of thinking about {...} for a use besides strings. But I think that what we might see from strings being more powerful with binding for interpolation could usher in a new area.