🚀 go-pugleaf

Peter Seebach (seebs@solutions.solon.com) wrote:
|> In article <3va943$im@gabi.gabi-soft.fr>, J. Kanze <kanze@gabi-soft.fr> wrote:
|> >Come now: I know it is not precise, but you
|> >aren't going to tell me that you've never said things like, "if the
|> >expression is true, we do this".

|> That's one of the things I think...

|> >This is part of what I find causes the confusion: you really don't say
|> >things like: "if this pointer is true..." and you shouldn't say things
|> >like: "if strcmp returns true..." (since the return value of strcmp is
|> >*not* a logical value).

|> More generally, though, what I *really* say is "if pointer".  Come on,
|> in English, does one say "if that I am going to the store is true"?  No.
|> You say "If I'm going to the store".

|> In C, I don't say "if this pointer is not null".  I say "if this pointer".
|> I don't say "if this expression is non zero", I say "If this expression".

This is a false analogy.  `I am going to the store' is a statement that
can be true or false.  `This pointer' or `this expression' is not a
complete statement.

|> The comparison with falsehood is the basis of logical if in natural
|> language, and is how it is done in the programming languages I know.
|> The comparison with an appropriate false value is implicit.

There is a misunderstanding here.  I don't believe that you should ever
compare anything with a logically false value.

My argument centers on types.  Something with a logically false value
also has a logically true value, and no other values.  True and false
are not numeric values, nor are they pointers, and it makes no sense to
declare them as such.

|> Similarly, for flags, I just use if(flag), not if(flag != 0).  I consider
|> the former clearer; it says exactly what I mean, without adding garbage
|> that a good compiler will ignore.

With flags, I agree.  But then, my flags always have names like
`isSomethingOrOther', with immediatly identify them as logical
predicates.

Again, a flag has two possible values: true and false.  The number of
operations on a flag is limited.  A flag is a logical predicate, and I
want the compiler to scream if I accidentally write `flag + 6'.

|> >A special boolean type is a reality, whether C wants to admit it or not.

|> Yes, but it's a reality that consists of an understanding of when something
|> is true, not of a separate type to which everything else is converted.

Correct.  But only logic predicates are true or false (by definition).
And I don't want everything else converted to bool (which is actually
the status quo).

As I stated in an earlier posting, a type is defined by a set of
possible values and a set of behavior (legal operations).  A logical
predicate answers a true/false question: Is ...?

Stated differently, since int's are numeric values, why should one
numeric value (0) be priviledged?  Why should I have a short form for:

    if ( i != 0 )

and not for:

    if ( i != 3 )

, for example?

|> Rather these two are isomorphic, but the former we already have, and the
|> latter involves the addition of new logic and added conversions.

|> >Independantly of the variable, I want the comparison operators to return
|> >bool, not int, and I want if and while to require bool as the expression
|> >type.  A new type is not just for declaring variables (although if the
|> >type exists, I want to also be able to declare variables).

|> I just want them to return something that acts like a truth value.  All
|> I care about is that there are two trivially different cases, which there
|> are.

|> I don't want "if a is greater than b is true", I want "is a is greater than
|> b."

Agreed.  So a > b should return a bool.

|> This is what we have.  Why would we ever change it?  I don't seek ever
|> more confusing phrasings.

|> >Basically, I am a proponent of `say what you mean'.

|> Me too.  But, long experience has taught me that a pointer *is* when it's
|> non-null, and *isn't* when it's null.  So, if (fp) is perfectly natural
|> for me; it means "if my file pointer", and that's what I mean.

Logically, however, saying just "if my file pointer" implies that `my
file pointer' is a logical predicate, i.e.: a two valued type on which,
e.g., addition is not defined.

|> I think it helps that I learned Chinese; there's a trivial way to say "there
|> is" that's short enough to be useful, and once you get used to just using
|> the existance-and-or-relevance test, it's nice to have it in a
|> programming language.  It works on pointers, it works on everything.

I have nothing wrong with the idea of wanting to have a short way of
saying `isValid( ptr )', or whatever.  Although as far as I'm concerned,
`isValid( ptr )' already seems pretty concise to me.

|> It conveniently says exactly what I mean.

That in some contexts, `ptr' really means `isValid( ptr )', and in other
contexts, `ptr' means pointer.

For me, at least, `ptr' is an object (with a set of values and a set of
legal operations, thus with a specific type).  An object is, in fact, a
noun.  Grammatically, a noun can only be used with a verb, thus:

    *ptr                `*' == dereference, so dereference ptr
    ptr != NULL         ptr is not equal to NULL

and so on.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung