Maps: Versatile Interface

In another episode of 'Where should you use maps vs. ...?', was reflecting on this post:

I don't know if maps are the most suitable choice here, but they would certainly be the least awkward expression of such options were they a little more versatile:

load/options %some-resource.reb #(
    tabs: no
    CRLF: yes

I'm not a fan of Red's specific literal notation for this, but running with it for the purposes of this thought. If a function were to receive such a map, could you REDUCE or COMPOSE it so as not to have to qualify each word?

reduce options 123
=> #(
    tabs: #[false]
    CRLF: #[true]

Would a literal map be bound to its containing context?

reduce use [bar][
    bar: "Bar"

    #(foo: bar)
=> #(foo: "Bar")

Red does not support this, but seems a reasonable expectation to me.

Permitting REDUCE which would presumably only reduce values and not keys and most likely creating a copy would have a distinct advantage over the awkward composition of objects in the cases where they have been used in these cases:

do-this-way: func [
    do-this/options content reduce #(
        option1: option1
        option2: option2
load/options %some-resource.reb #(
    tabs: no
    cr-lf: yes

I'm not a fan of Red's specific literal notation for this

I'm still skeptical on whether investing and spreading the MAP! concept in the core plays to the language strengths at all. It's like we're just going for JSON, but worse.

Besides BLOCK!s looking better, they afford you more options in representation:

   numbers: 1 2 3
   thing: (*) specially-marked
   [1]: "maybe SET-BLOCKS are the gateway to having generic keys?"

Cracking open the toolset of what it would take to give you "powers" for such blocks would help in dialecting. So focusing here has benefit across the board.

If it's performance people are concerned about, we can make the system speed up lookups when it notices access patterns it thinks it can speed up (e.g. a behind-the-scenes-HASH!)...and you could give it hints. But it would all still be the currency of BLOCK!.

I appreciate the versatility and possibility in your suggestion and trying to gain leverage from the language. However there is the inherent complexity in this even if you bring it to a core level. If all you're looking for is a list of yes/no/this-here/that-there, then maps and the handling thereof seemingly offer an immediate path with some potential perks