Notation for Hexadecimal literal integers

[rebolbot]

Submitted by: fork

When searching for a good hexadecimal literal notation in Red, it was challenging due to saturation of the notational space.

(For instance: the idea of 0x10 could not work to be a hex byte for 16 because that is a PAIR! Something like 04D2h might seem appealing except then FFFFh would compete with WORD!, so it would have to become 0FFFFh. And so on.)

Recent discussions questioning the value of abc{def}ghi being the same thing as abc {def} ghi have shown it's not true (consider how #{01} loads vs # {01}). But it's also not desirable, as it's a visual compression that detracts from readability... all while chewing away at the lexical space.

So to get the ball rolling on thoughts about how this space around {}, "", and <> might be reclaimed, I thought I'd make a proposal. How about 0x{AE}, 0x{AEAE}, 0x{AEAEAEAE} etc. be supported as a notation for hexadecimal literal integers?

Bowing to C isn't necessarily the greatest idea. And one could easily get confused and type 0x10 instead of 0x{10}. So don't take this too seriously...rather as a start on thinking about how being freed from some of the current beliefs about spacing could open the field. "The beginning of a search for a better idea."

>> print 0x{10}
== 16

>> print 0x{1000}
== 4096

>> print 0x{10000000}
== 268435456

^{CC - Data [ Version: r3 master Type: Issue Platform: All Category: Unspecified Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: fork

Another possible suggestion if #2094 is implemented (or the variation thereof: "Outer Space Minus Four")

foo: hex>AE
bar: bin>11110000
baz: oct>707070

The lack of a space, and the rejection of "participation of > in otherwise backwards legal symbols" laid out in #2206, frees these notations up.

Typing mistakes could be invalid with a space on the left (>AE not valid)

foo: hex >AE

Invalid with a space on the right (unless a tag is open on the line already, somehow...in which case, you messed up). Don't accept bin> unless followed by the data, no space between.

bar: bin> 11110000

And this is valid, but seriously? That is obviously a comparison. You shouldn't expect differently.

baz: oct > 707070

(This leads to the question of if a natural tag should be prohibited from ending with a space, which I think is a good rule to throw in also.)