[Tim]
> Java disallowed mixing ints with booleans specifically to stop the
>
> if (x = 1)
>
> flavor of C bug, but Python stops those via a different gimmick.
[Paul Prescod]
> I don't know if that's true or not, but it doesn't seem relevant.
Then you should have the grace to presume I'm not lying <wink>. It's
relevant only if *why* languages do what they do is interesting to you. It
is to me.
> Python's decision should be independent of it's C heritage so we need
> to look not only at why C-derived languages did what they did but also
> other languages. Most languages with no C heritage at all have a
> non-numeric boolean type.
I wouldn't presume to claim what "most languages" do, as I'm only familiar
with a relative handful.
> Here are other languages that (based on some admittedly cursory
> research) treat booleans as entirely distinct from integers:
I don't grasp why this should be interesting, in the absence of their design
rationales.
> * Scheme
> * SML
> * JavaScript
> * Visual Basic
> * Eiffel
> * Smalltalk
>
> I'd be curious to hear a list of high level, GC'd languages in the other
> camp.
I'm only interested in what's most useful. If I weren't, I'd sure wonder
what the heck garbage collection has to do with this <wink>.
> Methinks your Fortran/C bias shows. ;) And it isn't pretty.
You're arguing for the Fortran approach, and I don't have a C bias: I first
picked up C very late in my programming life. The languages I cut my teeth
on do include Fortran Classic, which had a non-numeric "logical" type with
manifest constants .TRUE. and .FALSE.; LISP 1.5, where the empty list "was
true" and all other values "were false"; SNOBOL4, which had no true/false
concept at all ("success" and "failure" drove control flow there); Pascal,
which is "like Fortran" in this respect; and APL, which indeed thrived on
doing arithmetic with 1/0 true/false values. The only one that was "really
like Python" here was APL.
I liked the APL approach best, simply because it was most useful. Perhaps
that's because my non-programming background is in discrete mathematics,
where identifying 0/1 with false/true is of great practical value. For
example, see "Concrete Mathematics" (Knuth, Graham and Patashnik), where
treating a true/false result as 1/0 is so common it's indicated merely by
surrounding a predicate expression with plain square brackets. This was a
notational advance over the non-programming state of the art (most texts
before CM, including Knuth's TAoCP, use a clumsy Kronecker delta notation).
The programming state of the art would be advanced a little by Guido's PEP,
in my view of the world.
>> days_in_year = 365 + is_leap(year)
>>
>> or
>>
>> print [("off", "on")[switch] for switch in switch_list]
> Personally, I find those both as obfuscatory workarounds for the lack of
> a terniary.
Ahem -- I thought we were disparaging *my* "C bias" here <wink>. How many
of the languages in your list above have a ternary operator? Languages that
don't distiguish expressions from statements (like your Scheme example) use
their all-purpose if/else constructs for this, but C introduced "the ternary
wart" for languages that do distinguish. It got into that mess by departing
from Algol, which also distinguished, but had both statement and expression
forms of if/else. IMO, C and Pascal both lost by departing from Algol here.
> I don't mind spelling out a terniary as an if/else and I don't mind
> spelling these out either.
Which then looks to me like a clumsy workaround for the lack of treating
false as 0 and true as 1. We're never going to agree on this, so enough.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4