ALL [()] should have the same result as ALL []

[Siskin-Bot]

Submitted by: Ladislav

Checked #564: "ANY and ALL are primarily used as control structures. As such, it might be good for unset! values to be skipped by both ANY and ALL, like noops." If that is what we want, then

all [()] 

has to yield the same result as

all [] 

i.e. True, not #[unset!], etc.

equal? type? all [()] type? all [] ; yields False

---

^{Imported from: CureCode [ Version: alpha 54 Type: Bug Platform: All Category: n/a Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#850}

Comments:

Rebolbot commented on May 26, 2009:

Submitted by: BrianH

Good point, even though #[unset!] counts as true for control functions. Ticket changed to reflect the new request - just put a copy of your comment in there and tweaked the code.

---

Rebolbot commented on May 27, 2009:

Submitted by: Ladislav

I guess that it is possible to change the implementation of All so that #[unset!] is completely ignored, i.e., that

all [1 ()]

would yield 1, etc.

---

Rebolbot mentioned this issue on Jan 12, 2016:
Make ALL completely ignore UNSET! values

---

Rebolbot mentioned this issue on Jan 22, 2016:
[Epic] Backwards-incompatible API changes, for the greater good

---

Rebolbot added the Type.bug on Jan 12, 2016

---

Hostilefork added on Jun 13, 2018

---

Hostilefork commented on Jun 13, 2018:

This is clearly a point of confusion overall. I'll note that at time of writing, Red says:

>> all []
== none

>> all [()]
;-- no result

I guess that it is possible to change the implementation of All so that #[unset!] is completely ignored, i.e., that

all [1 ()]

Originally in Ren-C this was the implementation choice, because NULLs were "neither true nor false". This was a feature inspired by the desire to have ways to print output in the middle of an ANY or an ALL without disturbing the logic of it (picking either true or false would disturb one or the other). Hence NULLs would "opt out" of ANY and ALL.

Beyond having functions that would always opt-out, this feature speculated a little bit on being a kind of arbitrary tristate...where one might have a routine that could return a truthy value, a falsey value, or a NULL... thus either voting yes or no or abstaining. Building in such a feature is kind of random, and actually got in the way of much more mainstream needs of the "non-value" status of NULL.

But when "invisibles" came on the scene, they provided new features such as ELIDE to take care of most opting-out scenarios. And it really just began to make more and more sense to consider NULLs as falsey, which Ren-C now does:

metaeducation/ren-c#816

And all failed ALLs return null as well, not blank. So all [()] = (), basically...and x: all [false] will error, because there is no actual value to be assigned. If this is okay, you have to say so explicitly with x: try all [...]

In light of this, it makes perfect sense that all [] should also be null...which offers the consistency sought in this issue. So the previous synthesis of a truthy value is now removed:

metaeducation/ren-c@e8ab17a

Clearly no one would be writing all [] in source anyway, so this would only come up in generated or composed code. That code could solve this problem by putting whatever result it wanted in at the tail, such as all [... true], or use one of the many null-handling operations in Ren-C, e.g. all [...] else [...]

---

Hostilefork mentioned this issue on Jun 13, 2018:
ANY and ALL treat unset! as a value, not as none! or false!

---

Oldes added a commit to Oldes/Rebol3 that referenced this issue on Oct 7, 2018:
FEAT: making UNSET! as a conditionally "TRUTHY"

---

Hostilefork commented on Oct 23, 2018:

In Ren-C, further changes have affected this issue...because GROUP! no longer synthesizes any values...it only groups them.

>> 1 + 2 ()
== 3

Hence ALL does not have the opportunity to differentiate all [()] and all []...it is running the evaluator and deferring to it, and in doing so sees nothing. It would be the same as all [comment "Hi"] as well.

There's no special code in ALL needed for this transparency--it just emerges from the new properties of GROUP!.

https://forum.rebol.info/t/what-to-do-about-do-and/772

---

Hostilefork added the Ren.resolved on Oct 23, 2018

---

[Oldes]

Current behaviour is:

>> equal? if all [][1] if all [()][1]
== true

[Oldes]

Now it is:

 none? any []
 none? any [()]
   1 = any [() 1]
   1 = all [1 ()]
unset? all []
unset? all [()]