Why Doesn't Ren-C Support LOGIC! for PICK ?

[hostilefork]

@rebolbot

>> pick [a b] 1 = 1
== a

>> pick [a b] 1 = 2
== b

What would be the harm of supporting it?

Ren-C does not have a logic type for #[true] and #[false].

The only falsey state in the system is the null antiform... and it does kind of double duty as "logically false" and "missing thing".

>> 1 = 2
== \~null~\  ; antiform

>> try third [a b]
== \~null~\  ; antiform

The double-duty presents some opportunities and some challenges. But it generally means you don't want to be passing nulls places that aren't "conditional".

The argument to PICK doesn't make a particularly good fit as being a "conditional" slot. Passing NULL is far more likely to be a mistake than be intentional. Randomly getting the second element of the block doesn't have a strong enough motivation.

Note Rebol2/Red don't let you pick with NONE as an equivalent to #[false]:

rebol2>> pick [a b] none
** Script Error: ....

@rebolbot

It's a way of turning a logical test into a value that's a little shorter than:

pick [thing1 thing2] condition

either condition [thing1] [thing2]

Note that Ren-C has soft quoted branching so you could quite efficiently write:

either condition 'thing1 'thing2

I'm not opposed to a construct existing that takes either a ~null~ antiform or an ~okay~ antiform and returns the first or second element of a block. I just don't think PICK should do that.