#savetheissue

#savetheissue

The use of issues for Prebol/Red macros is somewhat a departure from their raison d'être, but not wholly egregious. However assuming that metalanguage is their primary purpose and appropriating them as such is a programmers' conceit.

The semantic representation of issued strings is useful, and with not too much of a stretch aligns with IDs in HTML and hashtags in social media. Viewed through the lens of Rebol as a messaging language (as opposed to a programming language), issues contain much of what was described as implied semantics.

(also too as a slight digression, this point is why Rebol's syntax and grammar needs to be considered apart from most every other scripting language)

1 Like

This post was from a 2017 thread about whether "blanks" should be an arbitrary number of underscores.

That thread long predates today's unification of CHAR! and ISSUE! into the RUNE! type, which has provided answers to that particular question.

But the question of whether Ren-C's RUNE!s have "saved" the issues by merging them with character or not is something that perhaps should be revisited.

(Spoiler: I think RUNE! has saved the issue, and is a better name.)


The merging of ISSUE! and CHAR! has collapsed things that would have been formerly distinct.

In Rebol2/R3-Alpha/Red:

rebol2>> second "abc"
== #"b"

rebol2>> first [#b]
== #b

rebol2>> (second "abc") = (first [#b])
== false

In Ren-C

>> second "abc"
== #b

>> first [#b]
== #b

>> (second "abc") = (first [#b])
== \~okay~\  ; antiform

So really, all a "character" is, is an issue which contains a single codepoint.

You May Need Quotes, BUT Space And Newline Don't!

Sometimes you need quotes around a character and sometimes you don't:

>> second "a[b"
== #"["

But this addresses precisely the problem an ISSUE! would have had, if it wished to represent that character.

The choice of _ to represent space and # to represent newline helps with the two most common problematic states that anyone would want to talk about:

>> rune? _
== \~okay~\  ; antiform

>> form _
== " "

>> rune? #
== \~okay~\  ; antiform

>> form #
== "^/"

And you can make runes that are all spaces or all newlines, and just get longer versions of them:

>> tab: ____

>> rune? tab
== \~okay~\  ; antiform

>> form tab
== "    "

>> blank? _
== \~okay~\  ; antiform

>> blank? ____
== \~okay~\  ; antiform

RUNE!s Avoid WORD!-ifying Issues (That Was A Disaster)

R3-Alpha (and apparently still Oldes R3) have the misguided idea that ISSUE! be an ANY-WORD?, without actually confining it to WORD! rules:

rebol2>> any-word? #39FFC0 
== false

r3-alpha>> any-word? #39FFC0 
== true  ; uh, what...?

r3-alpha>> to word! #39FFC0
== 39FFC0   ; ...oh no :-(

r3-alpha>> w: to word! #1234
== 1234

r3-alpha>> word? w
== true

r3-alpha>> w
== 1234

At least Red didn't follow that mistake:

red>> any-word? #39FFC0 
== false

Ren-C's RUNE! is in the spirit of ISSUE! as being to hold any data.

Bringing CHAR!s Efficiency Benefits To ISSUE!

One difference between #a and #"a" historically was that the character fit in a single Cell, whereas the issue was a string type and pointed to a separate node. This means #a had a cost more like "a"... a difference that is significant.

(For an understanding of the kinds of costs this adds up to, it's analogous to what I write here about optimizing tuples/paths/chains.)

Clearly Ren-C didn't want to go from a CHAR! costing 16 bytes (4 x 32-bits) or 32 bytes (4 x 64-bits)... to suddenly costing multiples more. Hence RUNE! was made immutable, and small runes fit completely in Cells.

So if you write something like #foo you are getting that UTF-8 data packed directly into the Cell. It only makes a Flex node to hold more data if it needs it.

And Nothing Of Value Was Lost...!

In the messaging language sense, CHAR! being the "owner" of hash-quote had no value.

Actually, negative value...

rebol2>> to issue! "abc def"
== #abc

red>> to issue! "abc def"
== #abc def

r3-alpha>> to issue! "abc def"
** Script error: contains invalid characters

The benefits of unifying the types seems to be unarguable. If you're in the programming-language sense, you get the value of more succinct and easier to work with characters. If you're in the meta-language sense you get more robustness.

More compression, more rigor, and a single hardened part.


So What Do You Think? Did Ren-C #savetheissue?

1 Like