1. Re: 3.0.3 - type boolean
Alex Caracatsanis wrote:
> A serious, newbie question: why is this a useful type to check?
Hi Alex,
I assume you already know what booleans are used for - to hold one of two
possible states. Your question is a good one as it highlight one reason why
Euphoria's type system is not really adequate to define types properly.
Firstly, a Boolean type is a good thing to have in a P/L because it can help you
think more about the algorithm rather than side-effects of pseudo-boolean types.
For example, compare these two lines ...
if SomeThing = TRUE then
if SomeThing = 1 then
Someone reading the second line might wonder what are the possible legal values
for 'SomeThing' other than 1. This can lead to wasted time or subtle bugs when
trying to reuse the variable with non-boolean values. Whereas the first line the
meaning and intention of the coder is obvious and the reader can know that only
TRUE and FALSE are legal.
Euphoria's type system helps us here.
However, it doesn't help some other sorts of bugs, such as ...
integer Result
Result = SomeThing * 4
Huh? What value is four truths? In general, one should not be able to do
arithmetic with Booleans! Or compare them to non-booleans. Some might even argue
that trying to sort booleans is also a mistake - but it is convenient <g>
Euphoria's type system does not help us with this type of bug. If it could be
extended to allow us to define what operations are legal and how they should
actually work, then we could have proper boolean type in Euphoria.
You can think of Types as like Units of Measure. There are some operations using
UM that do not make sense ...
Result_meters = 4_kilograms + 7_watts
This is a BUG as the UM are not compatable. A decent type system would help us
avoid silly mistakes that that.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
