1. Re: 3.0.3 - type boolean
Derek Parnell wrote:
>
> 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
Ugh. I dislike strongly-typed languages and I like Euphoria's elegant solution
to the problem of strongly- versus weakly-typed systems.
On the one hand, I don't think that any programming language that I'm aware of
would prevent a programmer from mixing units as in the example that you provided.
Also, I doubt that many experience programmers would make that particular mistake
(not that I'm that experienced...)
Of course, I guess you could have used the NASA Mars Probe example of mixing
Imperial and Metric units to better measure.
On the other hand, I appreciate the flexibility of being able to reduce things
to numbers in an understandable way when necessary.
> The primary purpose of any programming language ought
> to be to help communicate your intentions to humans who read the code, so I
> recommend that coders, as a first priority, try to make code clear before
> trying
> to make it as fast as possible.
I actually agree with this statement, though. I just prefer the flexibility in
some cases.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
