Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!gdt!exspes
From: exspes@bath.ac.uk (P E Smee)
Newsgroups: comp.lang.c
Subject: Re: BOOLEAN as enum
Message-ID: <1990Apr12.085850.27391@bath.ac.uk>
Date: 12 Apr 90 08:58:50 GMT
References: <1990Apr6.102819.9379@bath.ac.uk> <1990Apr6.230447.22818@aqdata.uucp>
Organization: University of Bristol c/o University of Bath
Lines: 34

In article <1990Apr6.230447.22818@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes:
>:From article <1990Apr6.102819.9379@bath.ac.uk>, by exspes@bath.ac.uk (P E Smee):
>> Depends on what you're writing.  I frequently find it appropriate to
>> have THREE possible answers to a yes-or-no function.  Loosely described
>> as 'TRUE', 'FALSE', and 'I don't know'.
>
>If there are three answers, then it isn't a TRUE/FALSE question so
>the names "TRUE" and "FALSE" shouldn't be used.  
>If there are more answers then pick other names.

I think we're becoming theological here.  I understand your position,
and can see the rationale behind it.  On the other hand, my viewpoint
is that for most useful TRUE/FALSE questions, there is actually a third
possible 'answer' which loosely speaking translates as 'I'm not able to
determine which is the case'.  Maybe because of incomplete data; maybe
because of a hardware limitation; maybe because you've given me invalid
arguments.  And so on.

That is, the question is actually a TRUE/FALSE question, but there is
some probability that it will be (in some contexts) 'unanswerable' or
indeterminate.  Adding a third return value provides a handy way of
handling these cases.  (I see it, in some sense, as analogous to IEEE
NaN's for floating point.  Though the analogy is a bit weak since my
'Can't tell' value is not automagically supported by the hardware.)

As I said elsewhere, though, what mostly concerns me is that any given
chunk of code is written consistently -- just in case I have to take it
over.  If you prefer tri-state 'two-states' (I do) then fine, use them.
If you don't like them, use some other method of exception handling.
Please don't mix them haphazardly.

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132