boolean true and false values.

[Quinn Dunkan]

On 23 Jun 2000 07:56:39 GMT, Albert Hofkamp <hat at se-46.wpa.wtb.tue.nl> wrote:
>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.

Just remember one thing:

In C, variable names have types.  So if you say
int i = 4;
the symbol "i" has the type int, the number 4 doesn't.  In my (non CS-trained)
eyes, C doesn't really have any types, since you can change them 'en passant'
with a cast... or it sorta does, but there's weird holes and tricks.  I guess
that's why they call it weakly typed.  Anyway, I find the situation
non-intuitive.

In python, *values* have types.  So 4 is an integer, '4' is a string, and i is
a symbol, which is just a name for whatever it refers to.  It doesn't have any
type, it's just a name, the actual data has the type.  Like in a filesystem:
the file *name* doesn't have a type, it's the contents (text, binary, jpeg,
etc.).

I don't know a lot of languages, but of the ones I do, C and its derivatives
are the only ones that have the 'variable name is typed' behaviour, and I find
the C way quite difficult to understand properly (and C was my first
language!).

So python never dynamically adapts types, except for integer -> float
promotion things.  It's just that names don't have types at all, values do.

>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.

Yeah, well I do think it's easier to grasp "functions that return true are
true and functions that return false are false, and everything else is an
error" than "well, this this this and that are false, everything else is
true".  But having implicit booleans is just plain easier to type.  And if I
want to write in a B&D language that knows better than I how I should write my
programs, then there are a few really interesting ones out there which are not
python :)

>Having a separate concept 'boolean' forces users to really write tests, rather
>than arbitrary expressions which happen to deliver the right result.

But python is all about arbitrary expressions that happen to deliver the
right result :)

But you're right, just as disallowing mutation forces users to really write
modular functions, rather arbitrary collections of procedures that happen to
give the right result when you test a few boundry conditions.

>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.

Sounds like you're making a case that all newbies should be taught haskell or
scheme.  After all, invariants should be preserved.  The best way to do that
is to make them not vary.

>>> 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 ?

It is in the language (as in 'a builtin type'), just not in the distribution.
I posted a link before.

>[ 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
>]

Gosh, maybe your perfect language is already out there.  haskell has some of
the great things about python like whitespace-denoted blocks, along with
static typing, strict usage of a Boolean type, no options to vary your
invariants, and yes, a Set type.  And there's no need for all that wordy
redundant declaration like in C.