REBOL3 tracker
  0.9.12 beta
Ticket #0002197 User: anonymous

Project:

Previous Next
rss
TypeIssue Statussubmitted Date28-Feb-2015 03:44
Versionr3 master CategoryUnspecified Submitted byfork
PlatformAll Severityminor Prioritynormal

Summary Notation for Hexadecimal literal integers
Description 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."
Example code
>> print 0x{10}
== 16

>> print 0x{1000}
== 4096

>> print 0x{10000000}
== 268435456

Assigned ton/a Fixed in- Last Update23-Mar-2015 23:32


Comments
(0004614)
fork
23-Mar-2015 23:32

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.)

Date User Field Action Change
24-Mar-2015 00:00 fork Comment : 0004614 Modified -
23-Mar-2015 23:32 fork Comment : 0004614 Added -
28-Feb-2015 04:08 Fork Description Modified -
28-Feb-2015 04:02 Fork Description Modified -
28-Feb-2015 04:02 Fork Description Modified -
28-Feb-2015 03:59 Fork Description Modified -
28-Feb-2015 03:45 Fork Description Modified -
28-Feb-2015 03:45 Fork Code Modified -
28-Feb-2015 03:44 Fork Ticket Added -