Feature request: Underscore as NONE! literal

[rgchris]

This 'feature' comes from early Ren-C. It's a minimal change and visually works quite well. Underscores can still be used in words (even words comprised of just more than one underscore).

proto-map: #[value _]
proto-block: [_ _ _ a b c _]
assignment: _

Much more succinct than the #(none) alternative.

[Oldes]

Should it be just a word?
Early R3 alfa used # as a none. It could be enabled again as issues are not series. Although I'm still not sure if it is good or bad.

[rgchris]

For sure, or just write an alternate loader. Ultimately it's not a huge change to the language. Quite the contrary—fills a huge gap and, I will attest, is very natural to use (if you start using it even as a convention, you'll have a hard time going back).

[acook]

I'm not sure if it is a huge gap? And like you mention, reduce already works here. And so does replace.

Given:

a: 1
b: 2
c: 3
_: #(none)
proto-block: [_ _ _ a b c _]

When:

reduce proto-block

Then:

[#(none) #(none) #(none) 1 2 3 #(none)]

Or without reducing:

replace/all proto-block '_ #(none)

Then:

[#(none) #(none) #(none) a b c #(none)]

I think what might be good is a replace/flat refinement, which ignores blocks and brackets and just replaces all instances of the given word, regardless of depth.

And/or replace/nested which takes a limit argument and allows replacements up to limit depth of block nesting.

There is a case to be made for replace/flat to be implemented at the C level, since parse does not natively support treating brackets as plain words (as far as I know).

[rgchris]

Yes, but REDUCE only works at a shallow level and doesn't typically address nested values in static blocks and any workaround can be a significant (and convoluted) extra step. As an example, I use blocks to represent SVG and other XML. Visually, _ is a much more discreet representation of none than #(none) (or #) when evaluating that much data by eye. As a word though, it isn't NONE, so you have to do the extra evaluation when navigating the block. Underscore just works for this purpose.

Out of curiousity—do you feel the change is unnecessary, or do you feel that _ should be protected as a word choice?

[acook]

Personally, I want to learn about and solve for your use case - without it being a huge hassle for you to work around, while also not introducing non-backwards compatible changes.

From my understanding the issue is that:

1. current syntax means that what you care about ends up getting lost among the syntax of things you don't care about
2. current mitigations require a lot of inefficient code which would be better handled in the language itself due to the language design

The single-depth-only limitation of reduce/replace is why I mentioned the need for the replace/flat and replace/nested refinements. I could also see a reduce/flat in that set as well, but I wanted to avoid any unnecessary evaluations based on your concerns (which I agree with) so I only mentioned the reduce flavored ones. I could have been more explicit about that!

I feel that _ should be protected as a word choice because it is often used as a placeholder variable and treating it like a literal would break existing code and prevent anyone else from using it for anything else.

But I still want to find solutions.

[rgchris]

Got it! I don't know that it being a good placeholder name is more valuable than it's potential in this case—there's so many other options (including __ 🙂). My experience of none? _ is from Ren-C (ca. 2016, about three years prior to that fork deviating significantly away from Rebol syntactically and semantically), thus there is some precedent for this change in the Rebol world without the sky falling (also, see that my quickie implementation doesn't break tests in non-obvious ways). Writingthing: _ is common, convenient and clear.

---

Just looking at your example, I see this as illustrating the visual/semantic/cognitive benefits almost perfectly. Before/after:

[#(none) #(none) #(none) a b c #(none)]

[_ _ _ a b c _]

Once you see it, it's so hard to unsee.

[Oldes]

@rgchris looking at your implementation, as your mold is producing _ instead of #(none), one would not be able to load Rebol code in Red anymore:/ I don't know how common this situation may be, but I still try to be compatible at least with syntax (although there are exceptions already). Is it acceptable?

Also if I understand it well, you implementation does not handle this case correctly:

>> blk: transcode "/_"
== [/_] ;<-- should be [/ _]

>> length? blk
== 1 ;<--- should be 2

>> type? blk/1
== #(refinement!) ;<--- should be #(word!)

Anything else?

[rgchris]

one would not be able to load Rebol code in Red anymore:/

You could reinstate #(none) for MOLD/ALL to retain compatibility, however 1) Red should adopt this too—I just don't think I'm the person to suggest it, and 2) Red needs a Rebol loader so they can handle all historical Rebol constructs (as does Rebol 3, but all in good time...). I was a skeptic of the underline change for a long time (can track it in the old SO chat :), but now I find it difficult to live without.

Anything else?

I've been using my branch for the last week with a lot of quirky tests (need to get them online) and I haven't spotted any other problems with it. If I find any other edge cases, I'll add them to the issue tracker!

[Oldes]

Here is dedicated wish: Oldes/Rebol-issues#2669

[Oldes]

@rgchris should not form produce none instead of _? Having:

>> form none
== "none"

>> mold none
== "_"

[rgchris]

I don't have a strong opinion—I try to avoid forming NONE. There is even a case to be made that form none => "" or ERROR!.

[Oldes]

So could it be like this?

>> ajoin/all/with [ "a" _  3] ", "
== "a, none, 3"

>> ajoin/with [ "a" _  3] ", "
== "a, 3"

>> append "foo " _
== "foo none"

I would like to know answer so I could merge the changes. I don't have strong opinion as well, but have a feeling, that none is more human-readable string (taken from the form doc-string) than _.

[rgchris]

It really depends on context. My inclination would be error, though 'none' may be more appropriate in certain circumstances. In my experience, 'none' being formed at all is usually an undesired side effect of not checking input/output.

[Oldes]

This feature has been implemented since version 3.19.7. Let’s see how well it will be received.