The misleading names of TRUE? and FALSE?


#1

One might think that the way to test a value for being logic truth is TRUE?..though that’s misleading, since all values except LOGIC! false and BLANK! are true. Similarly, FALSE? doesn’t just test for LOGIC! false… it also says blank is false.

(Note: If you’ve found yourself writing things like all [logic? foo | foo]…that is more succinctly done as foo = true.)

In any case, TRUE? is a somewhat rare operation…because usually testing for “truthiness” is implicit in conditional operations. You don’t have to say if true? foo […] or case [true? foo […] …]. The only real time you would use it would be to coerce things to a logic, which is covered by TO-LOGIC in modern Ren-C (which doesn’t consider 0 to be false as Rebol2 did. I managed to get this change accepted to Github rebol/rebol back around the time of the open sourcing.)

@earl argued that TRUE? was somewhat more readable, but a lot has changed with chaining. Getting a logic result from FIND is now done with FIND? instead of TRUE? FIND (or FOUND? FIND), and other routines have XXX? forms that are chained into TO-LOGIC. So I believe this swings the balance to where having a misleading operation that people might be tempted to use to mean = true or = false is simply not worth it.

So anywhere you would have used FALSE? instead use NOT. Anywhere you would have used TRUE? instead use TO-LOGIC,. And we kill these misleading operations.


It appears that Red has gone with the change in TO as well, so the same approach should work for them:

--== Red 0.6.2 ==-- 
Type HELP for starting information. 

>> to-logic 0
== true
>> to-logic 1
== true
>> to-logic none
== false
>> to-logic false
== false
>> to-logic true
== true

#2

Are you advocating use of a TO-* function? :slight_smile:

With apologies to certain late-night comedians, could also introduce TRUTHY? (with corresponding FALSEY?)

My only objection to using TO-LOGIC is that the intent is not as clear as with TRUE? (or TRUTHY?).

if to logic! some-result [...]

Is a little less direct in meaning than:

if truthy? some-result [...]

It also kind of reads: if this is converted to logic, then …


#3

My point above is that we need to look at the real examples. You wouldn’t write if to logic! some-result [...] because you could say if some-result [...] and your “truthy” is intrinsic.

The cases you would use TO-LOGIC are going to read more sensibly:

some-logic-var: to-logic select [a b c] d

Because you really are doing essentially a cast. But again, there is now SELECT? etc.

I’m not opposed to truthy? existing; one might argue that just using not would be better than going as far as falsey?. I just don’t see places where TO-LOGIC doesn’t appear to fit better into the scheme. e.g.

all?: redescribe [
    {Shortcut AND, ignores voids. Unlike plain ALL, forces result to LOGIC!}
](
    chain [:all | :to-value | :truthy?]
)

Doesn’t it actually make more sense with:

all?: redescribe [
    {Shortcut AND, ignores voids. Unlike plain ALL, forces result to LOGIC!}
](
    chain [:all | :to-value | :to-logic]
)

But short answer being, I don’t have a problem with truthy? if you think you would use it, and would even add falsey?. I just think it’s time for TRUE? and FALSE? to go.


#4

Fair enough on NOT vs. FALSEY? I do agree that TRUE?/FALSE? are misleading and should go.

“Truthiness is the belief or assertion that a particular statement is true based on the intuition or perceptions of some individual or individuals, without regard to evidence, logic, intellectual examination, or facts.”


#5

Yup. Seen too many incorrect uses.

So the deed is done…I went ahead and added:

truthy?: :to-logic
falsey?: :not

Because I guess for anyone who uses them, that’s what they wanted. If people gravitate toward them, they can stay. If not, we’ll get rid of one or both.


#6

Questions for what the truth-biased complement of NOT are have puzzled many. Some might say it’s SO. (“is not!”…“is so!”)

In chat we came up with a name that had slipped my memory. Because I’ve thought to myself “hm, what was that idea we had as another name for TO-LOGIC or TRUTHY?” a couple of times, I dug it up. It was DID.

It does appear to work for some things. For instance, it’s better than FOUND? (which isn’t necessary if you’re just using it in an IF condition and not storing in a variable, but people did it anyway):

if found? find [a b c] d [...]

if did find [a b c] d [...]

It works even combined with negatives:

if did not find [a b c] d [...]

As a generalized “anti-NOT” it is far from perfect, but its current competition is TRUTHY?, so any imperfections in the concept might be worth glossing over:

logic-value: not any [a b c]
logic-value: did any [a b c]

Hmmm. Perhaps WAS might work in some other situations. was any […], was all […]

Saying did 1 => true and not 1 => false is a bit weird, given that no function ran. But then again, isn’t not "abc" => false pretty weird too if you sit down and analyze it? Isn’t the only reason that seems “coherent” (assuming it does) because you’re used to it?

Sometimes you have to kind of set a trend in programming. Someone came up with FOR and other constructs, we’re just looking at something people haven’t seemingly done much better than not not for.

Anyway, we said we were going to try TRUTHY? and FALSEY? as an experiment to see how we liked them. They’ve been around and I probably like them less than I used to.

I think I’d rather go with DID, NOT, and TO-LOGIC.


#7

(Weird, it seems I had to create another account to reply here from work.)

Anyway, I just wanted to say I really like DID. No other language has it, and Rebol needs to claim all of those first.


#8

I was just writing a test in the test dialect because I came across a stray resolved bug in rebol-issues while searching for remarks on DIFFERENCE of DATE!.

At first I almost made a mistake and wrote:

[
    #1822
    all [
        12:00 = difference 13/1/2011/12:00 13/1/2011
        12:00 = difference 13/1/2011/12:00 13/1/2011/0:0
    ]
]

For rigor, tests require all results to be actual logic true or false, not merely “truthy” or “falsey”. In this case it wouldn’t be that bad since it returns a true on success, and a BLANK! on failure, which would fail anyway. But I went to change it to use the ALL? form:

[
    #1822
    all? [
        12:00 = difference 13/1/2011/12:00 13/1/2011
        12:00 = difference 13/1/2011/12:00 13/1/2011/0:0
    ]
]

Then I thought about how annoying all these specializations are… ALL?, FIND?, etc. and contrasted the appearance with:

[
    #1822
    did all [
        12:00 = difference 13/1/2011/12:00 13/1/2011
        12:00 = difference 13/1/2011/12:00 13/1/2011/0:0
    ]
]

And I thought it felt more solid than ALL?. Where TO-LOGIC, TO LOGIC! and TRUTHY? look bad, it kind of works. So maybe we should take it seriously? Try it out for a while…contemplate it.


Dropping find?, while?, if?, unless? select?, etc
#9

As time passed, I came to like DID…a lot. Enough that I wrote an article about it:

http://blog.hostilefork.com/did-programming-opposite-of-not/

The ? CHAIN functions into TRUTHY? that were once introduced in Ren-C are all axed, so no more all? / find? and friends. Use did all or did find, etc. It’s nice to not have the clutter of a symbol, or to have to push the shift key…so it looks much smoother. And it’s good to not be generating a bunch of unnecessary function variations for every possible logic-returning thing…though they were a good test of CHAIN while they lasted.

Note that for conditionals, replacing the “was a branch taken” forms should not use DID directly, as their protocol is to test for “valueness” and not “truthiness”. So what was once called if? or switch? should actually look like not void? switch or any-value? if. Someday VALUE? will get retaken, and you can just write value? if, which is relatively succinct.

If someone can think of a word that tests for value-ness or void-ness which doesn’t have a ? in it, that would be interesting:

branch-taken: FOO case [
     condition1 [...]
     condition2 [...]
     condition3 [...]
     ;-- otherwise, no match, only way CASE returns void
]

assert [logic? branch-taken]

Solve for FOO, where FOO != 'VALUE? :slight_smile:

TOOK, perhaps? Conflates a bit with TAKE. RAN, maybe?

In any case, I think VALUE? is decent, and helps clarify what the protocol actually is.


#10

With all these improvements in the language, perhaps there will be a need for a helper program that transforms old Rebol 2 code towards Ren-C style code. This way helping porting old R2 scripts to the new environment.
I even can imagine a tool in an IDE that signals old-school programmers at work and suggesting them the new way of handling code.