Should "BLANK" be one, or two underscores?

Development Lexer
1

UPDATE 2025: "blank" is now just a RUNE! which consists of all spaces and hence renders as an arbitrary number of underscores. So there's no BLANK! datatype--it's just spaces. However, this discussion is still pertinent--skip down to the end for the current points.

@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"

2

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 _!

3

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
4

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

1 Like
5

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.

6

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

7

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.

8

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.

9

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
10

@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 _...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?

11

I'll go with the consensus.

12

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!

#savetheissue
13

A post was split to a new topic: #savetheissue

14

So this comes up again with quasiforms, because ~~ is now available again

I definitely think _ and ~ should be BLANK! and quasiform blank. But I do wonder if there's any value to allowing you to make arbitrary length versions, and get their length?

>> foo: ____
== ____

>> type of foo
== &[blank]

>> length of foo
== 4

>> bar: '~~
== ~~

>> type of bar
== &[quasiform]

>> length of bar
** Error: can't use length on quasiform

>> unquasi bar
== __

>> length of unquasi bar
== 2

What use would such a thing have? I don't know. But the interesting thing is that this formulation is coherent, it doesn't lexically get confused with anything else and it holds up cohesively.

Long sequences of BLANK! have a problem in dialect use that you can't tell how long they are. But I can imagine uses for ~~ and ~~~ in dialects, and as I show above you can't really ask quasiforms their length, so the unquasi'd form as blanks would basically just exist to let you get at that count.

It's something to think about.

15

Once _ became the RUNE! for SPACE, answers all started falling into place.

>> form _
== " "

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

>> tab: ____

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

>> form tab
== "    "

There's still the "traditional" behavior for things like quasiforms and antiforms (well, the behavior one might have come to expect since 2022-ish):

>> quasi _
== ~

>> ~
== \~\  ; antiform (trash!)

And it seems to me the best idea in rendering is to extend this to where all the space chraacters are replaced with tildes when making a quasiform:

>> quasi __
== ~~

>> quasi ____
== ~~~~

So now we have those parts too. But not just those... also Sigils:

>> meta _
== ^

>> meta __
== ^^

>> pin _
== @

>> pin ____
== @@@@

>> tie _
== $

>> tie ___
== $$$

More dialecting parts means more fun!

But How Do You Get The Length?

You can of course recognize these by their identities:

>> '^ = '^
== \~okay~\  ; antiform

>> '^ = '^^
== \~null~\  ; antiform

>> parse [@ $$ ^^^ ~~~~] ['@ '$$ '^^^ '~~~~]
== ~~~~

But what if you want to programmatically "measure" how big they are, and derive some meaning from that?

It might seem like a simple answer:

>> length of _
== 1

>> length of ____
== 4

However, there's been some question about whether RUNE!s should lockstep answer these kinds of questions as if they are strings... or if there are other answers.

For instance, what if we want "blank" runes to answer truthy to if they are EMPTY?

>> empty? second [a _ b]
== \~okay~\  ; antiform

If we generally say that RUNE! refuses to answer LENGTH OF unless it it's a BLANK! in which case it says 0, then that might open up a more interesting axis of programmability.

Then if you wanted to know the length for some reason you could alias as a string:

>> length of as text! _
== 1

>> length of as text! ____
== 4

I think I could reasonably be convinced that RUNE! straddles the semantic line, to where we don't necessarily need it to casually answer LENGTH OF unless you do a little extra work.

How often are you going to be asking about the length of a rune, really? More or less often than a WORD!? Same?

But to me that's the main question, the rest of this looks good.