1. request for change of boolean
- Posted by Kat <kat12 at ?oosahs?net> Dec 06, 2007
- 900 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
2. Re: request for change of boolean
- Posted by Derek Parnell <ddparnell at bi?pond?com> Dec 06, 2007
- 840 views
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. Alternatively you could write a new function ...
function OpenFile(sequence name, sequence type) integer fh fh = open(name, type) if fh < 0 then rc = 0 else rc = 1 end if return {rc, fh} end function object readfile readfile = OpenFile(flagfilename,"r") if readfile[1] then -- it's there, process it end if
But I can't see that that is much of an improvement. Maybe I'm wrong though. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
3. Re: request for change of boolean
- Posted by Juergen Luethje <j.lue at g?x.?e> Dec 06, 2007
- 845 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
4. Re: request for change of boolean
- Posted by Kat <KAT12 at coosahs.n?t> Dec 06, 2007
- 826 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. > > Alternatively you could write a new function ... > }}} <eucode> > function OpenFile(sequence name, sequence type) > integer fh > > fh = open(name, type) > if fh < 0 then > rc = 0 > else > rc = 1 > end if > > return {rc, fh} > end function > > object readfile > readfile = OpenFile(flagfilename,"r") > if readfile[1] then > -- it's there, process it > end if > </eucode> {{{ > > But I can't see that that is much of an improvement. Maybe I'm wrong though. My appologies. Kat
5. Re: request for change of boolean
- Posted by CChris <christian.cuvier at agric?lture.gouv.fr> Dec 06, 2007
- 846 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
6. Re: request for change of boolean
- Posted by Kat <KAT12 at coosah?.?et> Dec 06, 2007
- 862 views
CChris wrote: > > 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. <interesting stuff snipped> > 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 Æ What is "Æ" ? > - not for the near future -, then the nil solution will be used. 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. Kat
7. Re: request for change of boolean
- Posted by c.k.lester <euphoric at ck?est?r.com> Dec 06, 2007
- 839 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...
8. Re: request for change of boolean
- Posted by c.k.lester <euphoric at cklester.?o?> Dec 06, 2007
- 851 views
- Last edited Dec 07, 2007
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? If I have a boolean variable, then yes, it could cause a malfunction. > You should code this as ... > if readfile < 0 then ... > Would that be a problem? A simple enough fix. But the test for if readfile then is faster than the test for if readfile < 0 then plus, it takes longer to type the latter, so that over the course of, say, a billion or iterations, you've really wasted a lot of time. (That last part is a funny haha.) :)
9. Re: request for change of boolean
- Posted by Matt Lewis <matthewwalkerlewis at gm?il.c?m> Dec 06, 2007
- 835 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
10. Re: request for change of boolean
- Posted by c.k.lester <euphoric at cklest?r?com> Dec 06, 2007
- 852 views
- Last edited Dec 07, 2007
Matt Lewis wrote: > 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. The manual does say 0 is false and everything else is true, so it's just a property of the language. Plus, yes, it would likely break tons of code.
11. Re: request for change of boolean
- Posted by Jason Gade <jaygade at yah?o.?om> Dec 06, 2007
- 836 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.
12. Re: request for change of boolean
- Posted by Derek Parnell <ddparnell at bi?pond.co?> Dec 07, 2007
- 830 views
Kat wrote: > > Kat wrote: > > > > > > > > > Is it possible to change how boolean expressions are evaluated such that > > > only > > > values greater than 0 pass this test? : Yes it is, but this would be a bad idea because it would break a lot of code, and it is not the way that programming languages have been traditionally implemented. Not that I have a problem per se about breaking away from traditions, but it is important to "surprise" people only when it is demonstrably better than the traditional way. I have not come across any programming language (that doesn't have a native boolean type) that treats a non-zero value as false. Traditionally, zero is falsehood and (not zero) is truth. There are some languages that use specific integers to mean truth, for example Forth uses -1 (if all bits off means false then all bits on means true). In languages that support the syntax ... if (value) then where 'value' is a numeric data type, you will find that this typically is shorthand syntax for ... if (value != 0) then ... This can be seen when you look at the generated object code. When dealing with languages that have a built-in boolean type, such as Pascal, such variables do not have sematic numeric values. Instead they have built-in literals of True and False. Typically boolean datatypes are not numeric datatypes, in that they do not allow arithetic, or comparsion outside of the boolean type. X : Boolean; Y : Integer; if (X = Y) ***** Syntax error X + Y **** Syntax error. > 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. Please show me the Pascal code that demonstrates this because I don't think you are remembering correctly. And by the way, my primary job involves developing financial software for banks etc... and a negative balance does not mean there is 'no money'. It means that the customer owes the institution some money and we calculate interest on that balance. > 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). It would be good to have a native boolean type, in the same way as any datatype helps with bug detection, but that would detract from the freedom that Euphoria offers. I am willing to offset the benefits of static datatype checking against the flexibility and simplicity of Euphoria. The 'type' system in Euphoria is optional and I supposed could do with a few enhancements, but I can live with it for now. > In reality, it seems to be not only flamebait > on my butt, I hope you didn't think I was flaming you, because that is very not true. You know me better than that, Kat. > but a great example of why it's a good idea to NOT provide specific > code to illustrate a point. 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). -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
13. Re: request for change of boolean
- Posted by Derek Parnell <ddparnell at ?i?pond.com> Dec 07, 2007
- 842 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
14. Re: request for change of boolean
- Posted by CChris <christian.cuvier at ?griculture.gou?.fr> Dec 07, 2007
- 834 views
Kat wrote: > > CChris wrote: > > > > 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. > > <interesting stuff snipped> > > > 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 Æ > > What is "Æ" ? > Æ is an acronym for Advanced Euphoria (might change without notice), which is an unreleased attempt to add useful things to the language which can't get agreed upon on this forum - I have no idea on how to reach the user community at large, and the Eu community may not be the larger source of users. Currently, it's 100% compatible with Eu, but this may dwindle to around 95% in the future. As compatibility decreases, the likelihood of a name change will increase. I have plans, but not much time, specially these days. Given the time and energy Rob has poured into Eu and how he has succeeded, and given what I can realistically marshall, it is not very likely that Æ will be ever released. At least I can make .exe with it without some of the headaches of Eu programming. The modified interpreter Orac uses is an early stage of Æ. > > - not for the near future -, then the nil solution will be used. > > > 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. In the strict framework of Eu, "x>0" looks to me as a good enough check. Code clarity would certainly benefit from a strict (2 or 3 state) boolean type being standard. And perhaps from a bytebool type as well - I'm less sure, but not against. > 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). Definitely. A sequence is true iff all its elements pass the test. I like the way Eiffel allows to write things like: if my_array.forall(agent some_predicate) then ... which is exactly the same idea, just made more explicit. ("agent" is a rough equivalent for a routine_id, but it is a full fledged object whose properties include the arg type list, return type and stuff). > 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. > > Kat This is a double edged sword. If you don't provide code, some people won't try to understand your point. If you do, other people will nitpick at it and forget about the broader picture the snippet illustrates. I still think not including example code is even worse than providing it, but that's about as good as it can get. CChris
15. Re: request for change of boolean
- Posted by Kat <KAT12 at c?osa?s.net> Dec 07, 2007
- 836 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
16. Re: request for change of boolean
- Posted by CChris <christian.cuvier at a?ricu?ture.gouv.fr> Dec 23, 2007
- 835 views
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
17. Re: request for change of boolean
- Posted by Kat <kat12 at coos?hs?net> Dec 23, 2007
- 846 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
18. Re: request for change of boolean
- Posted by Bernie Ryan <xotron at ?luefrog.co?> Dec 23, 2007
- 848 views
Kat wrote: > > 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</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 > > > 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 boolean is a TYPE not a value. In boolean computer math it is one or zero; On or OFF. In logic it is a condition or the opposite condition. Enumerators can be negative or positive. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
19. Re: request for change of boolean
- Posted by Kat <KAT12 at co?sah?.net> Dec 23, 2007
- 847 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
20. Re: request for change of boolean
- Posted by Bernie Ryan <xotron at blue?r?g.com> Dec 23, 2007
- 839 views
- Last edited Dec 24, 2007
Here is a deeper view into boolean as used in C. http://www.ddj.com/showArticle.jhtml?articleID=184402137&queryText=v%E4l Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
21. Re: request for change of boolean
- Posted by Derek Parnell <ddparnell at bigpond.c?m> Dec 23, 2007
- 832 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