Poking Blocks Out of Range

Development Semantics
1

If you poke an item into an empty block, Rebol2, R3-Alpha, and Red will error:

rebol2>> block: []

rebol2>> block/1: 'a
** Script Error: Value out of range: 1

The error is a good sanity check, but it seems being able to poke in series out of range would be useful too.

I'll point out that you can erase items in blocks now:

>> block: [a b c]

>> block.2: none
== \~[]~\  ; antiform (splice!) "none"

>> block
== [a c]

As well as insert multiple items with splices:

>> block: [a b c]

>> block.2: spread [d e f]
== \~[d e f]~\  ; antiform (splice!)

>> block
== [a d e f c]

So splices can fundamentally disrupt the shape of a block in a poke operation.

Maybe if you use a splice, that's your way of saying "I'm okay with disrupting the size of this, just generally"? Then you use a length-1 splice to bypass the safety of an out of range check...?

With blanks, it seems there's even a pretty good answer for if you wanted to fill in space:

>> block: []

>> block.4: 'a
** PANIC: Out of range

>> block.4: spread [a]
== \~[a]~\  ; antiform (splice!)

>> block
== [_ _ _ a]

This could have parity with strings, e.g. poking strings into strings vs characters:

>> text: ""

>> text.4: #a
** PANIC: Out of range

>> text.4: "a"

>> text
== "   a"

That seems like a reasonable compromise...?

1 Like
2

I'll mention that I've become increasingly comfortable with just using splices literally.

>> block: [a b c]

>> block.2: ~[d e f]~

>> block
== [a d e f c]

At one time they were unfamiliar. But once you start to "see" them, the little squiggle next to the brackets makes sense as the container where the delimiters "aren't really there".

1 Like