Hex-Valued Integer Literals: Likely Not In Ren-C

On an old Trello there was a card about standardizing the differences between R3-Alpha and Red...and a checklist with only one item:

Hex-valued literal notation (Rebol has none, Red used to use FFh, FFFFh, FFFFFFFFh), now using 0#FF

The motivation was for purposes of Red/System, mostly.

In Ren-C this doesn't seem like a priority. It has ISSUE! (TOKEN!) as a read-only data type that fits in a cell. Hence a systems-oriented dialect already has an efficient way to represent these values.

For instance: it's not a big deal if your assembler says [mov ax, #FE] in its source... if it's generating machine code.

Of course, an ISSUE! in it isn't the same from a metaprogramming sense as a slot with an INTEGER! in it. So you don't get the automatic advantage of every dialect that has INTEGER! support for a given slot working with a hex notation. But isn't that what COMPOSE is for...?

my-dialect [something-or-another 255]

my-dialect compose [whatever (debin [BE +] #FF)]

Having more than one representation for the same type is generally bad, anyway. Let's look at what Red does here:

red>> FFh
== 255

red>> F0h + 0Fh
== 255

If it was so important that it had to be encoded in source, why is it thrown away immediately?

It's something about Red worth knowing exists, but off the radar for implementing, methinks.

1 Like