Re: Example where Euphoria defaults on a boolean expression
Rom wrote:
> From: "Juergen Luethje" <jluethje at gmx.de>
>
>> No, please try:
>>
>> integer E
>> E = 0
>> ? not E and E
>> E = not E
>> ? not E and E
>
>
> There was a bug in my example:
>
> atom e, f
>
> e = 3 -- does not matter what value you state here
> f = 3 -- does not matter what value you state here
>
> -- (I wrote wrongly "if (f = e) and not ( f != e) then ..." )
>
> if (f = e) and ( f != e) then print( 1, 1)
> else print ( 1, 0)
> end if
>
> object line
> line = gets( 0)
>
>
> f = e and f != e cannot be resolved. The evaluation should return nil.
>
> Euphoria will alway return False here. Euphoria will never return
> possible true. Then we are a long way into philosophy.
>
> I tried to exemplify that with the examle. If we have rule (A and B
> and C), and we don't know C, then we cannot know if (A and B and C) is
> true. We cannot conclude from the (A and B) about (A and B and C). That
> is what a program has to be evaluated if we don't know C. That is an
> unresolvable boolean problem (but we all know that if (A and B) is true
> then (A and B and C) may be true. What is unresolvable (=nil) here is
> nothing more mysterious than maybe.
Yes, I understand. But "maybe E" is not logically equivalent to
"not E and E". (Well, you talked about that with dm31 at uow.edu.au in the
meantime.)
> But C/Delphi/Euphoria never return unresolvable as a possible result
> for ANY logical expression (implying that all logic statements can be
> solved) . That does not mean that every logical expression can be
> solved, just that these languages cannot return unresolvable as a
> possible result.
>
> Of course an evaluation of an uninstanciated boolean var is
> unresolvable. If a program output True or False here that output is
> rubbish.
>
> It is so easy to implement a nil flag (= uninstanciated var) to deal
> with uninstanciated vars.
>
> A = nil if A -> nil
> A = True, B = nil if A and B -> nil
> A = False, B = nil if A and B -> False
> A = True, B = nil if A or B -> True
> A = False, B = nil if A or B -> nil
> 3 * nil -> nil
> 3 / 0 -> nil
If "nil" means "unknown", then "not nil" means "known" -- but known to
be true, or known to be false? Is there a solution to this logical
pitfall? I would appreciate it very much, if there were a "3-value-logic"
(false/unknown/true) in Euphoria.
For instance I also would prefer
open(<non existing file>, "r") -> nil
to
open(<non existing file>, "r") -> -1
The above mentioned use of "nil" is primarily independent of the problem
of uninstanciated variables, and those things shouldn't be mixed up, I
think. Using nil for such variables looks easy indeed, but I think it's
also easy to genarate a runtime error (as Euphoria currently does), to
deal with them. The question is to me, what brings more benefit?
>From my personal experience (being not an IT professional) it looks to
me, that generating runtime errors for uninstanciated variables is
better for the sake of safety.
Regards,
Juergen
--
Q: How many Microsoft engineers does Bill need to change a light bulb?
A: None. He just declares darkness to be an industry standard.
|
Not Categorized, Please Help
|
|
