Should literal BLANK! be one, or two underscores?

@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. :slight_smile: So perhaps this would remain as a definition for everyone, but it should probably not be considered a literal if it is not "canonized"

I like the idea it could be 1..3 underscores if you want.
I don't want to change all my existing scripts that use a single _!

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.

1 Like

Eh? Is it hard to replace a single _ with __ in rebol code?

1 Like

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.

Yeah, I have to find every script that I've written and change it .. no mean feat!

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 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.

So, I'll need a script that scans all my repos for scripts after _ was introduced, loads them, scans for _, fixes them, and then updates them.

And then does the same for all my *.reb scripts locally.

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.

1 Like

@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. :frowning: 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 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?

I'll go with the consensus.

I also prefer just single blank mainly for same reasons @ShixinZeng gave.

However for an alternative solution then how about #_

Because this then follows on nicely to having literal TRUE / FALSE...

blank: #_
true:  #true
false: #false

And if not enough savings are perceived over #[true] & #[false] then these can be shortened (or have aliases) to #T & #F

PS. I know this is stepping further onto ISSUE! datatype but we already have Prebol, Include & Red macros doing this!


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