|Version||alpha 32||Category||n/a||Submitted by||Gregg|
|Summary||ANY and ALL treat unset! as a value, not as none! or false!|
ANY and ALL only recognize none! and logic! values for their failure cases. Unset! slips through there as a value.
>> type? any [get/any 'c] == unset!
|Assigned to||n/a||Fixed in||alpha 38||Last Update||18-Aug-2015 07:35|
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).
|Implemented as suggested above.|
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.
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".
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.
|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:17||BrianH||Comment : 0000374||Added||-|