OpenEuphoria

1. request for change of boolean

• Posted by Kat <kat12 at ?oosahs?net> Dec 06, 2007
• 901 views

Is it possible to change how boolean expressions are evaluated such that only
values greater than 0 pass this test? :

readfile = open(flagfilename,"r")
if readfile then
-- it's there, process it
end if

Currently, if readfile = -1 , it evaluates to TRUE, when in fact the readfile
was not opened.

Kat

3. Re: request for change of boolean

• Posted by Juergen Luethje <j.lue at g?x.?e> Dec 06, 2007
• 846 views

Derek Parnell wrote:

> Kat wrote:
> >
> >
> > Is it possible to change how boolean expressions are evaluated such that
> > only
> > values greater than 0 pass this test? :
> 
> Why? Is there a compelling reason to change the current implementation? For
> example, does it cause your programs to fail or run slower?
> 
> 
> > }}}
<eucode>
> > readfile = open(flagfilename,"r")
> > if readfile then
> > -- it's there, process it
> > end if
> > </eucode>
{{{

> 
> You should code this as ...
> 
>   if readfile < 0 then ...
> 
> Would that be a problem?
> 
> > Currently, if readfile = -1 , it evaluates to TRUE, when in fact
> > the readfile was not opened.
> 
> The valid values that can be returned from open() are all positive integers
> greater than 2. The values 0, 1, and 2 are pre-opened files for stdin, stdout,
> and stderr. Thus negative values are returned to indicate that the file could
> not be opened. A positive value would actually imply that it opened just fine.

True.
Eu's built-in open() function does not return boolean values. And
treating integers as boolean values can cause problems, of course.
But that's not Eu's fault.

<snip>

Regards,
   Juergen

5. Re: request for change of boolean

• Posted by CChris <christian.cuvier at agric?lture.gouv.fr> Dec 06, 2007
• 848 views

Kat wrote:
> 
> 
> Is it possible to change how boolean expressions are evaluated such that only
> values greater than 0 pass this test? :
> 
> }}}
<eucode>
> readfile = open(flagfilename,"r")
> if readfile then
> -- it's there, process it
> end if
> </eucode>
{{{

> 
> Currently, if readfile = -1 , it evaluates to TRUE, when in fact the readfile
> was not opened.
> 
> Kat

1/ I routinely use things like

if readfile+1 then
-- readfile is a valid handle
end if

Granted, the "+1" is excess typing, but if only it were the only problem with
Eu...

2/ If the nil logical value was in the language, then open() could return nil on
failure and your test would work. Much cleaner, I wish it were here. But it means
changing two state logic to three state. Some code is expected to break. This has
been discussed already a few months ago.

3/ Another approach, more object oriened (donning firefighter gear fast), and
much easier to use as a result is:
- in the standard library:
<eiffel>
class FILE
-- whatever should go in here
feature {NONE} -- they are private
    last_open_file: INTEGER -- last handle retrieved

    open(file_name,file_mode:STRING) is
        local
            success: BOOLEAN -- some internal flag
        do
            -- whatever it takes
            if success then
                last_open_succeeded = TRUE
                last_open_file = the_handle
            else
                last_open_succeeded = FALSE
            end
        ensure
            success = last_open_succeeded
        end

feature -- public
    last_open_succeeded: BOOLEAN -- set by open on success
    get_last_open_file(): INTEGER is
        require
            last_open_succeeded 
        do
            Result = last_open_file
        end
</eiffel>    

- in your code:
<eiffel>
open(file,mode)
if last_open_succeeded then 
    my_file = get_last_open_file() 
    process(my_file)
else 
    file_not_opened() -- must do something about it
end
</eiffel>

If you try to access a file that couldn't be opened without cheking, you get an
exception.

Again, while the above two scenarios would make coding safer and clearer, they
just don't fit in what Eu is. If I ever can get a corret type system to work in Æ
- not for the near future -, then the nil solution will be used.

CChris

7. Re: request for change of boolean

• Posted by c.k.lester <euphoric at ck?est?r.com> Dec 06, 2007
• 841 views
• Last edited Dec 07, 2007

Kat wrote:
> 
> Is it possible to change how boolean expressions are evaluated such that only
> values greater than 0 pass this test? :
> 
> }}}
<eucode>
> readfile = open(flagfilename,"r")
> if readfile then
> -- it's there, process it
> end if
> </eucode>
{{{

> 
> Currently, if readfile = -1 , it evaluates to TRUE, when in fact the readfile
> was not opened.

I agree with this. I have counted on positive values being TRUE and
values <= 0 as being FALSE. It has bit me before. Yes, it's simple to
fix, but if we are treating the value as boolean...

9. Re: request for change of boolean

• Posted by Matt Lewis <matthewwalkerlewis at gm?il.c?m> Dec 06, 2007
• 837 views
• Last edited Dec 07, 2007

Kat wrote:
> 
> I liked the way bool and bytebool worked and evaluated in Pascal. Rather
> like common sense, or a checkbook. If the value was positive, any value,
> then it was there, money was in the checkbook, it was TRUE. If it was
> negative or zero, it was not there, there was no money, and it evaluated
> to FALSE. Somehow, it makes sense to me that Eu would have extended that
> to sequences (so {0,0,0,-300} = false, while {0,0,5000,0} is true). In 
> reality, it seems to be not only flamebait on my butt, but a great example
> of why it's a good idea to NOT provide specific code to illustrate a point.

First, I didn't think that your post was flamebait, nor do I think that
Derek did, based on his response.  My impression was that he

* considered your proposal
* asked for some more background to understand the motivation behind
  your request
* offered a work around for the specific case you mentioned
* discussed the reasoning behind the functioning of open()
* offered another work around

Then Juergen commented on Derek's post (that one doesn't strike me as a
flame, either).

CChris kinda agreed with you, and showed you how he works around it, then
offered another work around.

As I can rarely resist, I'll offer my own 2 cents on the topic.  There are
languages that treat -1 as TRUE and 0 as false.  This makes more sense when
you look at them bitwise--all bits either on or all bits off.

Whatever the merits may be for changing the truth evaluation in euphoria,
it would likely break a lot of code, so there'd better be a real good 
reason behind it.  And I doubt that "not having to type 'var >= 0'"
would make the cut.

Obviously, you could write a function that would return 1 or 0 based on
your description of PASCAL.

Matt

11. Re: request for change of boolean

• Posted by Jason Gade <jaygade at yah?o.?om> Dec 06, 2007
• 837 views
• Last edited Dec 07, 2007

Huh. Learn something new everyday.

I've never encountered a language where any nonzero value was counted as
"false". I know that some languages treat true as equal to "-1" and some others
treat true as equal to "1" but that's for converting boolean to integer.

Which languages treat numbers <= 0 as false? Which versions of Pascal?

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

13. Re: request for change of boolean

• Posted by Derek Parnell <ddparnell at ?i?pond.com> Dec 07, 2007
• 843 views

c.k.lester wrote:

> ... the test for
> 
>    if readfile then
> 
> is faster than the test for
> 
>    if readfile < 0 then

I think that if you actually test this assertion you wil find that there is no
performance penalty for using either form.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

15. Re: request for change of boolean

• Posted by Kat <KAT12 at c?osa?s.net> Dec 07, 2007
• 837 views
• Last edited Dec 08, 2007

Derek Parnell wrote:
> 
> I disagree because by showing a specific example gave us some insight in to
> the way you are thinking, and that can't be a bad thing. However, in this
> specific
> example, it also showed us that you had a misunderstanding of the way that the
> open() function works. It does not return a boolean and thus your argument was
> weakened. It returns EITHER a valid file handle (a positive integer) OR an
> error
> flag (-1). 

I fully realise it returns a -1 when error, but i mistakenly hoped -1 could be
called FALSE, so when i used the filehandle as a boolean, the code would run and
read smoothly. The same happens when decrementing a flag or index, and testing it
later: it becomes TRUE again when it goes negative. This just smells counter
intuitive to me. For operations like open(), i consider non-positive numerals as
"there", but they are error codes, not indicators of success, but that's just in
my lil book.

Perhaps i was misremembering pascal, i hope i get a little latitude since i
stopped writing new code years ago to deal with the dog situation here, when my
world was consumed with me not being consumed.

I do not remember how pascal typed bytebool, but i seem to remember it was an
array of bits, which simply couldn't go negative, perhaps a bytebool was a 0-255
byte. But likewise, i seem to be remembering if i typecast a string, mapped an
array of bytebool (or chars, didn't matter as there's no negative chars) onto it,
in an attempt to reduce memory needs, booleans still performed as expected when i
stopped using that memory as "string" and began using it as "array of bytebool".
When they aren't 0-255 bytes, but instead are -127-+127 bytes, in Euphoria, as
Matt pointed out, they could be negative with lots of bits set in that format, so
a plain bit test fails to respond as i expect(ed)(s)(ing). Unless they were
typecast as bytebool in pascal, which did different tests,, i dunno.




Kat

17. Re: request for change of boolean

• Posted by Kat <kat12 at coos?hs?net> Dec 23, 2007
• 848 views

CChris wrote:
> 
> Kat wrote:
> > 
> > Derek Parnell wrote:
> > > 
> > > I disagree because by showing a specific example gave us some insight in
> > > to
> > > the way you are thinking, and that can't be a bad thing. However, in this
> > > specific
> > > example, it also showed us that you had a misunderstanding of the way that
> > > the
> > > open() function works. It does not return a boolean and thus your argument
> > > was
> > > weakened. It returns EITHER a valid file handle (a positive integer) OR an
> > > error
> > > flag (-1). 
> > 
> > I fully realise it returns a -1 when error, but i mistakenly hoped -1 could
> > be called FALSE, so when i used the filehandle as a boolean, the code would
> > run and read smoothly. The same happens when decrementing a flag or index,
> > and
> > testing it later: it becomes TRUE again when it goes negative. This just
> > smells
> > counter intuitive to me. For operations like open(), i consider non-positive
> > numerals as "there", but they are error codes, not indicators of success,
> > but
> > that's just in my lil book.
> > 
> > Perhaps i was misremembering pascal, i hope i get a little latitude since i
> > stopped writing new code years ago to deal with the dog situation here, when
> > my world was consumed with me not being consumed.
> > 
> > I do not remember how pascal typed bytebool, but i seem to remember it was
> > an
> > array of bits, which simply couldn't go negative, perhaps a bytebool was a
> > 0-255
> > byte. But likewise, i seem to be remembering if i typecast a string, mapped
> > an array of bytebool (or chars, didn't matter as there's no negative chars)
> > onto it, in an attempt to reduce memory needs, booleans still performed as
> > expected
> > when i stopped using that memory as "string" and began using it as "array of
> > bytebool". When they aren't 0-255 bytes, but instead are -127-+127 bytes, in
> > Euphoria, as Matt pointed out, they could be negative with lots of bits set
> > in that format, so a plain bit test fails to respond as i
> > expect(ed)(s)(ing).
> > Unless they were typecast as bytebool in pascal, which did different tests,,
> > i dunno.
> > 
> > 
> > Kat
> 
> I just installed the latest FreePascal IDE v2.2.0 from www.freepascal.org, and
> remembered your post. Here's what the docs say:
> <quote>
> 
> Boolean types
> 
> Free Pascal supports the Boolean type, with its two pre-defined possible
> values
> True and False.
> It also supports the ByteBool, WordBool and LongBool types. These are the only
> two values
> that can be assigned to a Boolean type. Of course, any expression that
> resolves
> to a boolean
> value, can also be assigned to a boolean type. Assuming B to be of type
> Boolean,
> the following
> 
> Table 3.3: Boolean types
> Name      Size Ord(True)
> Boolean    1    1
> ByteBool   1   Any nonzero value
> WordBool   2   Any nonzero value
> LongBool   4   Any nonzero value
> </quote>
> Note to self: Pasting from a .pdf isn't the best way to keep text formatting.
> 
> The previous version of FPC I was using had the same text. As I have hardly
> ever used bytebools myself, preferring cleaner (imho) booleans, I can't tell
> how it worked on other compilers.
>
> CChris

 From Turbo Pascal v6 Programmer Guide (oem hardcopy) book, 
page 24: ....Boolean is an enumerated type ....
page 218: .... An enumerated type is stored as an unsigned byte if the
enumeration has 256 or fewer values; otherwise, it is stored as an unsigned word.

In other words, it cannot be negative. Ergo, if a boolean compare result is
negative, it's an error or it's stored as zero, or FALSE. It makes sense to me
that if the code execution says putting a -1 into a boolean byte that can be only
positive, it's an error, it's FALSE, so a zero is put into the boolean because
ord(FALSE) = zero. This may be due to compiler error checking flags being set
just right, i don't remember. Or looked at another way, when a -1 is compared to
0 or 1 (it hasto be TRUE(1) or FALSE(0) to be legal), either result is FALSE, so
a 0 is stored in the boolean.

FreePascal v1.0.6 says the same, except for it having 32bit booleans too. And
64bit booleans? Hmm, googling FreePascal tells me it's the same, but now more
advanced than in 2002.

None of my TP5 or 6 or 7 help files will run on winxp, so i cannot check them. I
found only my TP6 books, which don't have bytebool, and little about booleans in
general, and almost nothing on the compiler or runtime switches, in the index or
contents. The 3rd party books don't address the alledged problem.

Anyhow, nevermind.

Kat

19. Re: request for change of boolean

• Posted by Kat <KAT12 at co?sah?.net> Dec 23, 2007
• 848 views
• Last edited Dec 24, 2007

Bernie Ryan wrote:
> 
> Kat wrote:
> > 
> > CChris wrote:
> > > 
> > > Kat wrote:
> > > > 
> > > > Derek Parnell wrote:
> > > > > 
> > > > > I disagree because by showing a specific example gave us some insight
> > > > > in
> to</font></i>
> > > > > the way you are thinking, and that can't be a bad thing. However, in
> > > > > this
> > specific</font></i>
> > > > > example, it also showed us that you had a misunderstanding of the way
> > > > > that
> > the</font></i>
> > > > > open() function works. It does not return a boolean and thus your
> > > > > argument
> > was</font></i>
> > > > > weakened. It returns EITHER a valid file handle (a positive integer)
> > > > > OR an
> > error</font></i>
> > > > > flag (-1). 
> > > > 
> > > > I fully realise it returns a -1 when error, but i mistakenly hoped -1
> > > > could
> > > > be called FALSE, so when i used the filehandle as a boolean, the code
> > > > would
> > > > run and read smoothly. The same happens when decrementing a flag or
> > > > index,
> and</font></i>
> > > > testing it later: it becomes TRUE again when it goes negative. This just
> > > > smells
> > > > counter intuitive to me. For operations like open(), i consider
> > > > non-positive
> > > > numerals as "there", but they are error codes, not indicators of
> > > > success, but
> > > > that's just in my lil book.
> > > > 
> > > > Perhaps i was misremembering pascal, i hope i get a little latitude
> > > > since i
> > > > stopped writing new code years ago to deal with the dog situation here,
> > > > when
> > > > my world was consumed with me not being consumed.
> > > > 
> > > > I do not remember how pascal typed bytebool, but i seem to remember it
> > > > was an
> > > > array of bits, which simply couldn't go negative, perhaps a bytebool was
> > > > a
> 0-255</font></i>
> > > > byte. But likewise, i seem to be remembering if i typecast a string,
> > > > mapped
> > > > an array of bytebool (or chars, didn't matter as there's no negative
> > > > chars)
> > > > onto it, in an attempt to reduce memory needs, booleans still performed
> > > > as
> expected</font></i>
> > > > when i stopped using that memory as "string" and began using it as
> > > > "array of
> > > > bytebool". When they aren't 0-255 bytes, but instead are -127-+127
> > > > bytes, in
> > > > Euphoria, as Matt pointed out, they could be negative with lots of bits
> > > > set
> > > > in that format, so a plain bit test fails to respond as i
> > > > expect(ed)(s)(ing).
> > > > Unless they were typecast as bytebool in pascal, which did different
> > > > tests,,
> > > > i dunno.
> > > > 
> > > > 
> > > > Kat
> > > 
> > > I just installed the latest FreePascal IDE v2.2.0 from www.freepascal.org,
> > > and
> > > remembered your post. Here's what the docs say:
> > > <quote>
> > > 
> > > Boolean types
> > > 
> > > Free Pascal supports the Boolean type, with its two pre-defined possible
> > > values
> > > True and False.
> > > It also supports the ByteBool, WordBool and LongBool types. These are the
> > > only
> > > two values
> > > that can be assigned to a Boolean type. Of course, any expression that
> > > resolves
> > > to a boolean
> > > value, can also be assigned to a boolean type. Assuming B to be of type
> > > Boolean,
> > > the following
> > > 
> > > Table 3.3: Boolean types
> > > Name      Size Ord(True)
> > > Boolean    1    1
> > > ByteBool   1   Any nonzero value
> > > WordBool   2   Any nonzero value
> > > LongBool   4   Any nonzero value
> > > </quote>
> > > Note to self: Pasting from a .pdf isn't the best way to keep text
> > > formatting.
> > > 
> > > The previous version of FPC I was using had the same text. As I have
> > > hardly
> > > ever used bytebools myself, preferring cleaner (imho) booleans, I can't
> > > tell
> > > how it worked on other compilers.
> > >
> > > CChris
> > 
> >  From Turbo Pascal v6 Programmer Guide (oem hardcopy) book, 
> > page 24: ....Boolean is an enumerated type ....
> > page 218: .... An enumerated type is stored as an unsigned byte if the
> > enumeration
> > has 256 or fewer values; otherwise, it is stored as an unsigned word.
> > 
> > In other words, it cannot be negative. Ergo, if a boolean compare result is
> > negative, it's an error or it's stored as zero, or FALSE. It makes sense to
> > me that if the code execution says putting a -1 into a boolean byte that can
> > be only positive, it's an error, it's FALSE, so a zero is put into the
> > boolean
> > because ord(FALSE) = zero. This may be due to compiler error checking flags
> > being set just right, i don't remember. Or looked at another way, when a -1
> > is compared to 0 or 1 (it hasto be TRUE(1) or FALSE(0) to be legal), either
> > result is FALSE, so a 0 is stored in the boolean.
> > 
> > FreePascal v1.0.6 says the same, except for it having 32bit booleans too.
> > And
> > 64bit booleans? Hmm, googling FreePascal tells me it's the same, but now
> > more
> > advanced than in 2002.
> > 
> > None of my TP5 or 6 or 7 help files will run on winxp, so i cannot check
> > them.
> > I found only my TP6 books, which don't have bytebool, and little about
> > booleans
> > in general, and almost nothing on the compiler or runtime switches, in the
> > index
> > or contents. The 3rd party books don't address the alledged problem.
> > 
> > Anyhow, nevermind.
> > 
> > Kat
> 
> boolean is a TYPE not a value.

No one said it was a value. I said the representation of the boolean state
*could* (not *must*) be a value, witness the bytebool or wordbool. It's a
function which returns a 1 or a 0. I also said in TP and FP that the
representation could not be a negative value, because the representaion of the
type is an unsigned byte. But even as a bytebool, the boolean returns 1 or 0.
 
> In boolean computer math it is one or zero; On or OFF.

Are you in some way correcting what i said? if so, what? The bytebool type,
allowing the "value" of the boolean representation to be a whole byte
representing 0 to 256 of "amount" of TRUEth? Note there was no way to represent
an amount of FALSE, a negative number, a -1, unless you did code yourself to
check for FALSE < 127(or some other value you chose) < TRUE. I didn't invent the
bytebool, but i have used it sorta like this:

bytebool: ItIsThere, Cow
ItIsThere = 12
Cow = 13
if ItIsThere then -- boolean on an unsigned byte
  if compare(ItIsThere,A_Lot) then ... end if
end if
if ItIsThere = Cow then
 -- this will fail even tho both are TRUE
end if

. The existance of bytebool suggests the internal representaion of the boolean
TRUE/FALSE is not only pointable to a non-bit-value, but is also evaluated down
to 1 or 0 when used internally.

> In logic it is a condition or the opposite condition.

Yes, the condition of TRUE or FALSE. If ItIs or ItIsNot. Which is why i made the
mistake of asking for Euphoria to evaluate a -1 error when opening a file to be
ItIsNot open, because the -1 says it wasn't opened, that is, it is not a
readfile, as a readfile it is FALSE because it wasn't opened, so

if readfile then...end if

should fail if readfile = -1.
 
> Enumerators can be negative or positive. 

Not as expressed in Turbo Pascal, or apparently FreePascal, where the boolean
representations are unsigned bytes (not single bits).

> Bernie

So are we arguing just for the sake of the arguing now? I have appologised for
bringing up the topic, i feel i haveto defend the fact i have used fuzzy boolean
"values" (those representations other than 1 or 0 when used directly in
usercode), that they didn't have negative "values", and i didn't invent them. I
don't see the point of pressing the issue, it won't happen in Euphoria because i
was told it isn't going to happen. I give up, you win. Ok?

Kat

21. Re: request for change of boolean

• Posted by Derek Parnell <ddparnell at bigpond.c?m> Dec 23, 2007
• 834 views
• Last edited Dec 24, 2007

Kat wrote:
>  From Turbo Pascal v6 Programmer Guide (oem hardcopy) book, 
> page 24: ....Boolean is an enumerated type ....
> page 218: .... An enumerated type is stored as an unsigned byte if the
> enumeration
> has 256 or fewer values; otherwise, it is stored as an unsigned word.
> 
> In other words, it cannot be negative.

I realize that you already know this but for the benefit of onlookers, the above
description is talking about how boolean values have been implemented in Turbo
Pascal - that is, their actual bit representation in RAM. It is not talking about
the semantics of booleans, which deals with how they can be used and what they
mean to a program.

The TP manual is stating that booleans cannot never be repesented in RAM as
negative numbers.

> Ergo, if a boolean compare result is
> negative, it's an error or it's stored as zero, or FALSE.

This is where we part company though. I do not see the necessary logical
connection between the manual's statements and your conclusion. I suspect that
when negative numbers are converted to boolean before such a comparision, TP
converts zero to false and all other values to true.

Here is a small Pascal demo program ...

=================
program booltest;

var
  remainder: Boolean;

begin
  remainder := Boolean(-1);
  if remainder then
      Writeln('-1 is true')
  else
      Writeln('-1 is false');

  remainder := Boolean(1);
  if remainder then
      Writeln('1 is true')
  else
      Writeln('1 is false');      

  remainder := Boolean(0);
  if remainder then
      Writeln('0 is true')
  else
      Writeln('0 is false');      

end.

==========

This gives the result :

-1 is true
1 is true
0 is false


-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell