@MSGID:
<a83c53e8-9fff-4586-bf3e-ecbf7b148829n@googlegroups.com> 9c3926e4
@REPLY: <20230911125054.179@kylheku.com> ddc39a12
@REPLYADDR Tom Russ <taruss@google.com>
@REPLYTO 2:5075/128 Tom Russ
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<769eadf4-96c0-4632-b1c8-8117d20567c7n@googlegroups.com>
<20230911125054.179@kylheku.com>
@RFC-Message-ID:
<a83c53e8-9fff-4586-bf3e-ecbf7b148829n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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.
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441