@rgchris suggested something that had already run across my mind a few times. Are BLANK! literals a bit too thin at just one character wide?
Underscore is a very slight character in the first place. Two characters would make it stand out, and be the same width as empty block or a void-evaluating group:
data: __
rule: []
void: ()
Compare with:
data: _
rule: []
void: ()
Is there something intrinsically more pleasing about the two underscores? Does it resolve some of the qualms some people (@rgchris in particular) have had about the single underscore?
Or could blank be any number of underscores (defaulting to some value) and retain it as part of its formatting? :-/
>> x: _
>> y: __
>> z: ___
>> mold x
_
>> mold y
__
>> mold z
___
Problem being of course that BLANK!s are generated by the system a lot; standardization makes more sense.
For near term compatibility, if _ went back to being a WORD!, we could define:
_: __
Rebmu will of course want the ability to express a BLANK! in a single character. So perhaps this would remain as a definition for everyone, but it should probably not be considered a literal if it is not "canonized"
With the change to a single underscore we lost the gravitas of the word "none" somewhat. I feel that two underscores is more pleasing because one seems too slight to feel significant.
This has been on my mind pretty much consistently since the beginning of BLANK!. Since @rgchris brought it up on his own as well, and you agree too, and @gchiu's only objection is "I have to change code"...I think we are looking at something that needs to happen.
I mentioned that the main problem with this is that the system will generate them. And the ones the system generate need to have a standard width...so allowing users to vary beyond that seems to introduce a variance we don't really need. If it preserves the width, it becomes "data-bearing" and people can use it for information (e.g. length-of mold my-blank), which is the kind of thing I'd like to avoid. If it throws away the width, the person who made it a specific width for what-they-thought-was-a-reason will be unhappy.
If we've decided there's a best width--which appears to be two--there is value in asking people to standardize on that.
Well, _ for blank was only introduced within the past year. So...
In any case, when it comes to your code--since you are likely the first person who is going to be "shipping" code to users--it should embody the best principles we've worked out, to be showcases. I think the single underscore is indeed too slight, and things would look better with two.
As I was expressing that single underscore is easily overlooked, I should be happy. I don't have production ready code, so changes like this do not affect me much, but others do, so I think the burden to those who have to update should be considered.
@ShixinZeng has brought up a good point about fonts. Namely that not all fonts that have underscore will tie the two together with no gap. He prefers one blank.
We've also had @asampal and @kealist weigh in on the issue on the side of one blank.
It has been a conflicted issue for me, but it seems there are fairly solid arguments...combined with some intuition, for sticking with the status quo. But FWIW, I don't think it's been that bad. And other languages like Haskell have gotten away with it, and I don't think anyone freaks out too much about it.
Syntax highlighting can probably help out here for those who think there's a visibility problem. I know some editors even let you do character replacement when rendering. Unicode has something called "fullwidth low line": ＿ which is wider than _...so perhaps a syntax rule for lone underscores could substitute that?
I guess it's just a question. @rgchris, @Brett, as you warm up to blank, is it "so bad" as it is, singly?
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)
So perhaps this would remain as a definition for everyone, but it should probably not be considered a literal if it is not "canonized"
But FWIW, I don't think it's been that bad. And other languages