Rethinking the ISSUE datatype
REBOL introduced a datatype called an issue. From the manual:
An issue! is a series of characters used to sequence symbols
or identifiers for things like telephone numbers, model numbers,
serial numbers, and credit card numbers.
It was a good attempt, but rarely, if ever, has it been used. Normally, we use strings for those types of values.
Instead, the issue datatype has gained usage as a meta keyword. This originally came from Prerebol, the REBOL preprocessor, but this usage pattern has gained popularity in other utilities too (such as Ladislav's Mecir's include package).
For example, you will see it as:
#if [a = b] [do something]
These expressions are using issues for meta keywords which are being preprocessed before (or as) the source code is being loaded.
This is indeed useful, but not the intention of issue as a datatype. In addition, this method is not efficient, because each issue instance is a unique string. So, each issue takes memory and equality checks require full string comparison.
In 3.0, due to the Unicode rework, we have to re-examine all character-based datatypes and consider their encoding. The more I thought about the issue datatype and its usage, the more I begin to think:
An ISSUE! should be a WORD! subtype.
Right now, we have:
as word-based semantic variants (natural, set, get, lit).
What if we added:
If we want, we can still call it an ISSUE! datatype, but the internal representation would be a word, and functions like any-word? would return true for it.
The advantage is that an issue would no longer require string memory (other than symbol table allocation) and equality comparison is extremely fast (including search with FIND.)
Above, each #include or #if found in code would not require extra storage and can be compared with greater speed.
I should also point out that this # usage is somewhat consistent with the mold/all meta-construct syntax:
What is the downside? If somewhere out there in userland the issue datatype is actually being used for its intended purpose: serial numbers, phone numbers, etc., then there could be some incompatibilities. But, then R3 makes no general guarantee of compatibility.
Internally, this is an easy change. So, that's not a factor.
Tell me what you think.