boolean true and false values.

[Albert Hofkamp]

On 23 Jun 2000 10:00:29 GMT, Quinn Dunkan <quinn at photo.ugcs.caltech.edu> wrote:
>
>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 got a personal email which said the same thing using a rather nice metaphor
of pointing fingers to objects. I know that quite some things are said about
this stuff in the Python tutorial, but they didn't hit home, until this email.
Tnx for pointing it out to me.

[ for the other readers, consider real-life objects like coffee-mugs or
  telephones as the data or value, and your finger as the variable, pointing to
  the value. The values all have a type (e.g. a telephone is a thing of type
  'telephone'), the finger has no concept of 'point only to things of type X'
]

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

I understand that now.
However, I am not quite sure that that is what one wants.

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

Easier to type is imho no argument to justify introducing chances for making
errors. Unless the differences is very large, any time spend trying to find the
error is always larger than time spend to type the extra characters.

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

I think I am (is that bad ? :-) ).
I really like functional programming, and i am quite convinced that it is a
very good language to start really clean thinking. However, unless one
understands mathematics, functional programming is not easy to grasp. It gets
even more difficult if users are already contaminated with some other
non-functional programming language (e.g. try explaining to a C programmer that
you can specify complex behaviour without variables).
For this reason, Python is a better alternative imho (of course, our own
language is even better, but nobody on this list knows about the language, so
there is little point in telling that :-) ).

There is imho an important reason why the Python way of typing may be harmfull
for newbies.
Basically, you'd want them to program cleanly, which means that they should use
invariants even if they are not aware of it.

These invariants are always about variables, basically because they are valid
in a general case rather than a specific one. (e.g. one would write 'total
contains the sum of all elements dealt with upto now', rather than '4 is total
of the elements of the list starting with the elements 1,2,1, or the list
starting with 4, or the list starting with 1,3, or ..., 5 is the total of ' etc
etc)

In other words, variables are in reality quite tightly connected to their
values because a meaning is given to the variable.
For example, pointing the variable to a value of another type does not fit in
the idea of invariants. For example, by executing 'total="kjerg"', the
invariant is not longer true, since "kjerg" is not the sum of elements (it is
not even a number).

Thus, to a good programmer, the dynamic nature of variables is not needed. To
bad programmers, it is a tool which can be used quite abusively.
I once met some-one who was programming DB3, another dynamic language aimed at
data bases.
He did things like

count = 234
<use count as integer value>
count = str(count) # assuming that str(234) delivers "234"
<use count as string value>
count = int(count) # assuming that int("234") delivers 234
<use count as integer value>

etc

The first thing I did when I saw it was deciding on a single representation of
count, and inserting the appropiate conversions everywhere necessary.

This person was self-thaught so blaming him is difficult, but a less dynamic
language would have prevented him from doing this in the first place.

I tried explaining why the above was a bad idea, but even the difference
between 234 and "234" is already non-trivial to explain, let alone the above
stuff.


As a wild shot, what would happen if one would limit the use of variables to
values of the same type as the first occurence ?
(thus after x=3, i can only assign integers to x).



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