boolean true and false values.

[Albert Hofkamp]

On Thu, 22 Jun 2000 23:17 +0100 (BST), Tim Rowe <digitig at cix.co.uk> wrote:
>In article <slrn8l1oc2.3c1.hat at se-46.wpa.wtb.tue.nl>, 
>hat at se-46.wpa.wtb.tue.nl (Albert Hofkamp) wrote:
>
>> I read a number of replies, but didn't read an answer that seems 
>> satisfactory.
>> I ran in the same problem, and was also not able to find a elegant 
>> solution.
>> Using 0 and 1 or `true` and None is not correct imho, there should be a 
>> native
>> way to use true and false for indicating boolean values.
>
>There is not an elegant solution, short of making very fundamental changes 
>to the language that would IMHO break its nature. There is no problem with 

I also fear that it would break things if you'd make changes to something
fundamental as this.

To be honest, I tried to write a reply yesterday, but couldn't really argue why
I feel bad about not having boolean values, so I did a bit of thinking first.

Today, I think I may have a part of the answer.
My work is language and tools development of a specification language aimed at
users with almost no experience in programming.
Unlike Python, our specification language is statically typed.
For my work, I program in C++.
Obviously, that makes me biased towards a statically typed language :-)

My trouble with python is that there are types, and at the same time they are
not there, which is confusing to me.

As an example:

a="a'slrk;jwhg"
a=1

works, since Python dynamically adapts the type of a (this may be not entirely
semantically correct, but I hope you understand my point).

a=1
print "a"+a

does not work, as Python keeps telling me every time I try.

Maybe I make a reasoning mistake somewehere, but to me a sometimes adapts
dynamically, and sometimes not.
As a language aimed at 'the masses', I think this is hard to explain.

Then the lack of booleans.
In my work I noticed that having clean and orthogonal concepts helps starting
programmers. In our language design the language tries to force users into
thinking cleanly and orderly, otherwise they end up with a messy program which
the machine doesn't like.
Having a separate concept 'boolean' forces users to really write tests, rather
than arbitrary expressions which happen to deliver the right result.
An example (or rather, 2 examples :-) ):

>>> if []:
...   print "yes"
... else:
...   print "no"
... 
no
>>> if [1]:
...   print "yes"
... else:
...   print "no"
... 
yes
>>>

I'd really hate to explain that a list has a truth value to a beginner.
(in fact, I would even argue that [] should deliver true, since it _IS_ a list
instead of None).

Last but not least, I am not sure whether you'd really want the dynamic nature
of current Python. [ what do you mean, a migration path ? :-) ]
>From programming theory, I learned that there are invariants which have to be
preserved. Something like "the variable 'total' contains the total sum of
elements dealt with upto now". Obviously, total has a single type here, which
makes the entire dynamic typing concept with sequences like 'a="rg"; a=1' unwanted.

I realize that introducing new variables on the fly is extremely important for
ease of hacking^H^H^H^H^H^H^Hprogramming, but letting it mess up the type
concept seems an unwanted side effect to me.

BTW: the semicolon in the sequence above is there not by accident, I'd really
     like to see Python move towards multi-statement lines, as it makes programs
     more readable if used correctly.
     I personally use the idea of 'first statement on a line messes up an
     invariant, the remainder of the line restores the invariant' in C++, which
     works great.

>assignment, but there is a serious danger with testing. You would have the 
>situation that
>	if foo:
>could follow the true branch, but
>	if foo == true:
>would follow the false branch. This has been a perennial C/C++ issue, and 

I know, just defining false=0 and true=1 will not work.

>C++ now has boolean types, and that problem has been largely resolved, but 
>that's only been possible because C++ is (fairly) strongly typed and will 

For C/C++, mixing boolean with integers is not bad, as C/C++ has a different
attitude towards the user. (Still, seeing C++ introducing bool means to me that
there is apparently a need for this concept even in C/C++).

>> Also, I am missing the data type 'set'. It can be faked with a 
>> dictionary, but it
>> is just not the same. Any one else got this problem ?
>
>It can be implemented very easily as a class wrapper around a list, that 
>checks for presence before adding an element, and defines union, 

Yes, I know, but why is it not in the language ?
Quite a lot of algorithms rely on having sets. If you put them in a list, there
is an order which is not always wanted.
Also, implementing a set in anything else than a set is conceptually not clean.
(to be fair, the list operations are quite extensive, so living without sets is
doable).

>intersection, &c. It raises interesting questions of how deep the equality 
>test should be, and I suspect different applications would need different 
>answers, so I'm not sure it should be a built in. Anyway, all the paired 

The user should be able to customize it, but this is really about the equality
test rather than the set concept.

>delimiters on my keyboard are already used -- what would you delimit it 
>with? :-)

{x,y,z} ?

(it may be possible to extend the dictionary concept with 'x' meaning 'x:none')

[ Before I my mailbox gets filled with flames, I do love Python, and I am
  pushing it as the standard glue language in our group. The comments above are
  solely arguments for improving Python further
]

Albert
---
Look ma, windows without Windows !!