unset! transparency in any and all

[Oldes]

Should I make this change?
Current version (compatible with Red (almost) and Rebol2):

any []     ;== none
any [()]   ;== #[unset!]
any [() 1] ;== #[unset!]
all [1 ()] ;== #[unset!]
all []     ;== true (in Red none)
all [()]   ;== #[unset!]

after change:

any []     ;== none
any [()]   ;== none
any [() 1] ;== 1
all [1 ()] ;== 1
all []     ;== true
all [()]   ;== true

In original R3 alpha it was:

any []     ;== none
any [()]   ;== none
any [() 1] ;== 1
all [1 ()] ;== #[unset!]
all []     ;== true
all [()]   ;== #[unset!]

Related discussion: http://www.rebol.net/cgi-bin/r3blog.r?view=0207
Related issues:
Oldes/Rebol-issues#564
Oldes/Rebol-issues#850
Oldes/Rebol-issues#2248
And also:
red/REP#85
red/red#4469
red/red#4482

[acook]

Reading into the old issues is pretty interesting. To me it is surprising that unset wouldn't be treated like none, but the argument is compelling to ignore them entirely. So I'm okay with either approach.

[Oldes]

This is better:

unset? all []     ;== true
unset? all [()]   ;== true

[Oldes]

So now it is:

all [
  print "Testing ANY"
   none? any []
   none? any [()]
     1 = any [() 1]

  print "Testing ALL"
     1 = all [1 ()]
  unset? all []
  unset? all [()]

  print "Tests OK"
] ;== true

[hostilefork]

(Updated for 2026 conventions...)

For whatever it is worth 🤷 my notion of "UNSET!" is split into two ideas: VOID! and TRASH!.

You can think of TRASH! as an "erroring unset!" and VOID! as a "vanishing unset!". Trash doesn't display anything in the console... and it can encode a message (there's an automatic feature that uses the symbol of the function as the message, to help know where trash came from if it causes an error down the line).

>> print ["Things like PRINT return trash, with no == result in console"]
Things like PRINT return trash, with no == result in console

>> eval [comment "things like COMMENT return void"]
== \~\  ; antiform (void!)

VOID! behaves in ANY and ALL like your unset! does above.

TRASH! will error... but you can use ELIDE as a kind of "evaluative comment" to erase things that make trash:

>> elide print ["It's easy to erase things with ELIDE if you want to"]
It's easy to erase things with ELIDE if you want to
== \~\  ; antiform (void!)

Neither TRASH! nor VOID! participate in things like EQUAL?, nor can they be tested for truth by things like IF. (It's obvious why a vanishing type shouldn't be either conditionally true or false when tested in isolation. But less obviously that it shouldn't be legal in comparisons... however, I think Rebol2 was correct to not allow unset! in comparison operators.)

If I had to collapse these down to just one type, I would pick the VOID! semantics, as they are more important.

However, the TRASH! distinction has turned out to be very useful. I think having a dedicated "meaningless" type has a lot of value, because vanishing becomes a meaningful state...and if you have a function returning that it vanishes, people start to rely on that. This ties your hands in future evolution of a function's return result when you come up with a more meaningful idea. And it's nice to have a state tailored to "don't show in console" that doesn't have other implications.

[Oldes]

But I don't want to introduce new datatypes for this purpose (but I can imagine, that unset! could contain some flags as there is plenty of available space in the value slot for that). I understand that in some cases it may be useful, but in other cases it may be just confusing. Not to mention that I don't have time to rewrite the core to support it right now.

Btw.. it would be useful to provide full test cases... for example in Rebol3 it is now like this:

all [
	 none? any []
	 none? any [()]
	  1 == any [() 1]
	  1 == all [1 ()]
	unset? all []
	unset? all [()]
] ;== #(true)

[hostilefork]

unset? all []
unset? all [()]

I am 100% certain this is a good idea, and have motivating examples. It is important to know from the outside of the ALL "did you actually encounter a falsey condition, or did everything opt out?"

e.g. in my world loops always return the falsey state if they BREAK, and return no value if they never ran their bodies. So you can combine this knowledge:

 all [
     some-loop...
     some-other-loop...
 ]
 => NULL "one of the loops broke, so the whole thing is a BREAK"
 => VOID! "neither loop ran, so the whole thing reports nothing ran"

---

none? any []
none? any [()]

I suspect that motivating examples exist where this should match ALL (being VOID?/UNSET?).

Is there any good reason why this should short-circuit, and not be able to give you something from the second ANY?

any [any [...everything vanishes...] any [...]]

Or in my loop protocol:

any [
   some-loop...
   some-other-loop...
]
=> NULL "at least one loop encountered a BREAK"
=> VOID! "none of the loops ran"

If you flatten the signals into just a falsey state you lose the distinction.

I'll admit that it's a distinction that's not as "obviously useful on day one" as (all [] => no value) is. But I think over the long run, there will be applications. And I don't see the reason to throw out the information.

---

So I would suggest:

all [
     unset? any []
     unset? any [()]
     1 == any [() 1]
     1 == all [1 ()]
     unset? all []
     unset? all [()]
] ;== #(true)