Re: request for change of boolean
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
|
Not Categorized, Please Help
|
|
