Type | Issue | Status | submitted | Date | 28-Feb-2015 03:44 |
---|---|---|---|---|---|
Version | r3 master | Category | Unspecified | Submitted by | fork |
Platform | All | Severity | minor | Priority | normal |
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 to | n/a | Fixed in | - | Last Update | 23-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 | - |