REBOL3 tracker
  0.9.12 beta
Ticket #0000564 User: anonymous


TypeIssue Statustested Date25-Jan-2009 21:34
Versionalpha 32 Categoryn/a Submitted byGregg
PlatformAll Severityminor Priorityhigh

Summary ANY and ALL treat unset! as a value, not as none! or false!
Description ANY and ALL only recognize none! and logic! values for their failure cases. Unset! slips through there as a value.
Example code
>> type? any [get/any 'c]
== unset!

Assigned ton/a Fixed inalpha 38 Last Update18-Aug-2015 07:35

25-Jan-2009 22:17

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:
- ALL [()] == unset! ; current behavior
- ALL [() 1] == 1 ; current behavior
- ANY [()] == none ; new behavior
- ANY [() 1] == 1 ; new behavior

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).
25-Mar-2009 04:28

Implemented as suggested above.
17-Aug-2015 18:21

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:

my-function: func [a b ...] [...] ;-- accidentally doesn't return a value

if all [
condition1 condition2 condition3
my-function a b ...
] [
print "Yay all conditions hold, let's roll!"

That's bad if UNSET! is treated as conditionally true.
17-Aug-2015 22:34

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
"Accidentally executed no code whatsoever, executed [return #[unset!]], or executed code that evaluated to #[unset!]."
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".
18-Aug-2015 07:35

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 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.

Date User Field Action Change
18-Aug-2015 07:35 Fork Comment : 0004658 Added -
17-Aug-2015 22:37 MarkI Comment : 0004657 Modified -
17-Aug-2015 22:36 MarkI Comment : 0004657 Modified -
17-Aug-2015 22:34 MarkI Comment : 0004657 Added -
17-Aug-2015 18:21 Fork Comment : 0004656 Added -
25-Mar-2009 10:18 BrianH Status Modified built => tested
25-Mar-2009 04:34 carl Status Modified waiting => built
25-Mar-2009 04:34 carl Fixedin Modified => alpha 38
25-Mar-2009 04:28 carl Comment : 0000502 Added -
27-Jan-2009 03:31 BrianH Priority Modified normal => high
27-Jan-2009 03:30 BrianH Comment : 0000374 Modified -
25-Jan-2009 22:22 BrianH Comment : 0000374 Modified -
25-Jan-2009 22:18 BrianH Status Modified submitted => waiting
25-Jan-2009 22:18 BrianH Code Modified -
25-Jan-2009 22:18 BrianH Description Modified -
25-Jan-2009 22:17 BrianH Comment : 0000374 Added -
25-Jan-2009 21:34 Gregg Ticket Added -