I'm working with MAL that is supposed to be a Clojure clone.
I'm surprised to see the following.
Almost nothing is consider false in the second position
in the `if construct, however asking for a truth value explicitly
by `true? is different. (Naively I borrowed the code for if,
routinely isolated in a separate function, and used this for `true? ).
Testing failed, thus I checked with the Clojure installed on my system.

"
Clojure 1.10.1
user=> (true? true)
true
user=> (if true? 1 2)
1
user=> (true? true?)
false
"

Is there a reason for this?

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Saturday, September 9, 2023 at 1:47:23 PM UTC-7, none albert wrote:
> I'm working with MAL that is supposed to be a Clojure clone.
> I'm surprised to see the following.
> Almost nothing is consider false in the second position
> in the `if construct, however asking for a truth value explicitly
> by `true? is different. (Naively I borrowed the code for if,
> routinely isolated in a separate function, and used this for `true? ).
> Testing failed, thus I checked with the Clojure installed on my system.
>
> "
> Clojure 1.10.1
> user=> (true? true)
> true
> user=> (if true? 1 2)
> 1
> user=> (true? true?)
> false
> "
>
> Is there a reason for this?

(a) That is the way Clojure defines the IF operator. Only FALSE or NIL are false.
(b) That is traditionally the way Lisp defined the IF operator. Only NIL was false.

TRUE? is a function, so as an object it will not be considered equal to
the value TRUE. So asking if the function TRUE? is the value TRUE
will return false. https://clojuredocs.org/clojure.core/true_q

Now, the IF statement works differently. It will treat any value except FALSE
or NIL as being true. https://clojuredocs.org/clojure.core/if

On 2023-09-11, Tom Russ <taruss@google.com> wrote:
> Now, the IF statement works differently. It will treat any value except FALSE
> or NIL as being true. https://clojuredocs.org/clojure.core/if

That looks like a giant clusterfuck.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Monday, September 11, 2023 at 12:51:51 PM UTC-7, Kaz Kylheku wrote:
> On 2023-09-11, Tom Russ <tar...@google.com> wrote:
> > Now, the IF statement works differently. It will treat any value except FALSE
> > or NIL as being true. https://clojuredocs.org/clojure.core/if
> That looks like a giant clusterfuck.

It is in keeping with how Lisp traditionally defined "generalized booleans", and how
it is specified in the CommonLisp spec. Scheme is similar in treating anything other
then #f as being a true value. Similar logic can be found in many other languages like
the C-family (although zero counts as false as well there).

This is clearly not as type-safe as allowing only true Boolean values (t/nil; #t/#f, true/false)
to be used on conditionals, but it is not an uncommon design choice. It would be
cleaner in semantics to make the test more explicit about the condition, but there is
a legacy of languages often allowing various shortcuts in accepting a wider range
of values in places where boolean are semantically desired.

In article <a83c53e8-9fff-4586-bf3e-ecbf7b148829n@googlegroups.com>,
Tom Russ <taruss@google.com> wrote:
>On Monday, September 11, 2023 at 12:51:51 PM UTC-7, Kaz Kylheku wrote:
>> On 2023-09-11, Tom Russ <tar...@google.com> wrote:
>> > Now, the IF statement works differently. It will treat any value
>except FALSE
>> > or NIL as being true. https://clojuredocs.org/clojure.core/if
>> That looks like a giant clusterfuck.
>
>It is in keeping with how Lisp traditionally defined "generalized
>booleans", and how
>it is specified in the CommonLisp spec. Scheme is similar in treating
>anything other
>then #f as being a true value. Similar logic can be found in many other
>languages like
>the C-family (although zero counts as false as well there).
>
>This is clearly not as type-safe as allowing only true Boolean values
>(t/nil; #t/#f, true/false)
>to be used on conditionals, but it is not an uncommon design choice. It would be
>cleaner in semantics to make the test more explicit about the condition,
>but there is
>a legacy of languages often allowing various shortcuts in accepting a
>wider range
>of values in places where boolean are semantically desired.

Belatedly, I can relate to this. In Forth only if the condition is 0, the
if-action is suppressed. OTOH by convention, if a word returns a
boolean flag than the only values allowed are
be all bits 0, or all bits 1 (proper formed flag).

As you all know, Forth is not the cleanest language, so no scruples.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <20230911125054.179@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-09-11, Tom Russ <taruss@google.com> wrote:
>> Now, the IF statement works differently. It will treat any value except FALSE
>> or NIL as being true. https://clojuredocs.org/clojure.core/if
>
>That looks like a giant clusterfuck.

What is a 'clusterfuck'? What do you mean by this?

Kaz

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <a83c53e8-9fff-4586-bf3e-ecbf7b148829n@googlegroups.com>,
Tom Russ <taruss@google.com> wrote:
>On Monday, September 11, 2023 at 12:51:51 PM UTC-7, Kaz Kylheku wrote:
>> On 2023-09-11, Tom Russ <tar...@google.com> wrote:
>> > Now, the IF statement works differently. It will treat any value
>except FALSE
>> > or NIL as being true. https://clojuredocs.org/clojure.core/if
>> That looks like a giant clusterfuck.
>
>It is in keeping with how Lisp traditionally defined "generalized
>booleans", and how
>it is specified in the CommonLisp spec. Scheme is similar in treating
>anything other
>then #f as being a true value. Similar logic can be found in many other
>languages like
>the C-family (although zero counts as false as well there).
>
>This is clearly not as type-safe as allowing only true Boolean values
>(t/nil; #t/#f, true/false)
>to be used on conditionals, but it is not an uncommon design choice. It would be
>cleaner in semantics to make the test more explicit about the condition,
>but there is
>a legacy of languages often allowing various shortcuts in accepting a
>wider range
>of values in places where boolean are semantically desired.

Algol68 comes to mind.
real f; int i;
f := i;

f denotes a memory location where a float can be stored.
I denotes a memory location where a int can be stored.
Regards f := i.
Clearly you cannot store a memory location to a f.
Dereferencing: an int.
Clearly you cannot store an int to a f.
Widening and int to an f.

Now in the situation
if <expression>
you can have coercion and widening rules.
`if only accepts bool's but perhaps <expression> can be forced into
the mold "bool" .
This as rigorous as it gets.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Tue, 12 Sep 2023 12:09:33 +0200, albert@cherry.(none) (albert)
wrote:

>In article <20230911125054.179@kylheku.com>,
>Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>On 2023-09-11, Tom Russ <taruss@google.com> wrote:
>>
>>> Now, the IF statement works differently. It will treat any value except FALSE
>>> or NIL as being true. https://clojuredocs.org/clojure.core/if
>>
>>That looks like a giant clusterfuck.
>
>What is a 'clusterfuck'? What do you mean by this?

https://www.merriam-webster.com/dictionary/clusterfuck