ANY and ALL treat unset! as a value, not as none! or false! #564
Labels
Backwards incompatibility
CC.resolved
Issue with CureCode status built, tested or complete
Guru meditation
Oldes.resolved
Bugs/wishes with Oldes' fixes/features
Red compatibility
Issues and changes required for compatibility with Red language
Ren.resolved
Status.important
Test.written
Submitted by: Gregg
ANY and ALL only recognize none! and logic! values for their failure cases. Unset! slips through there as a value.
Imported from: CureCode [ Version: alpha 32 Type: Issue Platform: All Category: n/a Reproduce: Always Fixed-in:alpha 38 ]
Imported from: metaeducation#564
Comments:
Submitted by: BrianH
This is how R2 works as well. I have always been surprised that it doesn't throw an error, as that is the main difference between the unset! and none! types.
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. Unset values would be treated as they are now for ALL (as not false), and converted to NONE by ANY before testing:
Any change to how ANY and ALL treat unset! would have subtle implications to a lot of code, and the affected code would be very difficult to find and fix. So now is the time to make the change, before too much code is written in R3.
This is being discussed in R3 chat, in R3/Language (21), and this request is waiting for consensus. This comment will be updated with the decision when one is made (or removed if another comment declares the decision).
Submitted by: Carl
Implemented as suggested above.
Submitted by: fork
UNSET! should be an error for these. They are convenient proxies for a chain of ANDs or ORs without the infix baggage (once crowd-favorite #1879 is in place).
@brianh says what we're all thinking: "I have always been surprised that it doesn't throw an error, as that is the main difference between the unset! and none! types." When there's no benefit, principle of least surprise comes into play. Consider:
That's bad if UNSET! is treated as conditionally true.
Submitted by: MarkI
Firstly, your code example will fail as written, causing "** Script error: if does not allow unset! for its condition argument".
Secondly, "accidentally doesn't return a value" is a very misleading statement.
It means the same thing as "Accidentally returns #[unset!]." which is the same as
That seems to be pretty explicit, and in fact very difficult to do "accidentally". YMMV, of course.
Thirdly, this proposal would make it a lot harder and uglier to put calls to PRINT in ALL blocks.
Again, YMMV, but some might find it unacceptable to be forced to phrase all such PRINTs as "also true print".
This is what I am guessing BrianH meant by his statement "it might be good for unset! values to be skipped by both ANY and ALL".
Submitted by: fork
Okay, I think I was wrong here. But the best argument for why I am wrong is actually one that hasn't been brought up yet, but which @MarkI reminded me of...which are the needs of expression barriers. Which has broader implications for other constructs that have a similar question of UNSET! ignoring. See #2248
But since ignore should mean ignore...it leaves me in disagreement that ALL [()] == unset!. Instead it should be the same as ALL []... hence TRUE. Though it doesn't probably come up terribly often, that's a more coherent behavior.
The (hopefully final) resolution of this in Ren-C is that there is no such thing as an "UNSET! value", only a NULL evaluative result...and it is conditionally false.
Additionally, ANY and ALL, when they fail, return this NULL evaluative result.
This is true of other things that used to return "valued" BLANK! on failure:
While this is still true...the development since is that there is an unfriendly value called VOID! that is neither true nor false. However, it is not directly related to the unset state of a variable (because if a variable holds a VOID! value it is not unset):
https://forum.rebol.info/t/why-void-is-not-like-unset-and-why-its-more-ornery/947
If one wants to slip a routine that produces a VOID! into a stream of something like ANY or ALL and have it ignored, you can use ELIDE which is an "invisible" function
ELIDE and invisibles are a generic mechanism that work in any evaluative context (e.g. CASE statements)
The text was updated successfully, but these errors were encountered: