OpenEuphoria

Re: Re: What's new in 2.5?

• Posted by "Christian Cuvier" <Christian.CUVIER at agriculture.gouv.fr> Sep 08, 2004
• 439 views

[yet more snippage]

>>That's a major source of errors 
>>> designing the function or just forgetting the preliminary test, plus the 
>>> coding overhead.
> 
> 
> "major"? Are you sure of that?
> 

AFAIC yes. Note that I didn't say THE major cause.

> This seems to assume that the coder is not so concerned with what exactly
> is wrong, just that something is wrong. Something like ...
> 
>    ifx s[i+3] then
>       Abort("Something is wrong with the line above")
>    else
>        a = s[i+3]
>    end if

There's a lot of situations where you are only concerned by: does this 
statement make sense and hold? The latter depends on a yes answer to the 
first. The if/while statement forces you to separate the two (getting three 
states: makes no sense, true, false), while this is less often than not
necessary.
In most of the case I think of, the Abort(...) line would be an exit statement 
of sorts.

>  
> 
>>> Further, any undefined index real bug will show up anyway, most likelly in
>>> the
>>> same conditional block, when attempting to read or write from a nonexistant 
>>> element, which must remain an error condition in a nonconditional statement.
>>>
>>> This challenges the very idea that the proposed change will hide bugs.
> 
> 
> It does? Is this below a bug or not?
> 
>    
>    sequence y y = "derek"
>    ifx not(y = "frank") then
>        ProcA(y)
>    end if 
>    
> In your scheme, ProcA would always be called regardless of what value 'y'
> holds.
> 
> 
> -- Derek Parnell Melbourne, Australia

Wrong. y="frank" does have a {0,0,0,0,1} value. not will turn this into 
{1,1,1,1,0}. The problem is, that value isn't either atomic true or false, and 
the statement must error out.

Compare with:

     sequence y y = "derekp"
     ifx not(y = "frank") then
         ProcA(y)
     end if

There, the = logical test fails to evaluate because of the length mismatch, 
and the whole conditional is false, regardless of any other stuff appearing 
between "ifx" and "then". ProcA() is not executed either.

Note that this scenario falls a bit outside of the intended use, which is to 
recover when statements that may not fail do. Because of the residual crash 
case, the construct would be less valuable here.

I regularly wind out writing:
if equal(seq[i..j],sth) then...
but j may fall off bounds, and the statement is obviously not true. Out of 
frustration, I now peruse

function Equal(sequence s,integer i,integer j,sequence x)
integer l l=length(x)
if i<1 or j<1 or j+l>length(s) then return 0
else return equal(s[i..j],x)
end if
end function

No crash now, but does double duty with the interpreter. And I have to never 
forget to use it rather than simpler code that will likely fail.
See how "ifx s[i..j]=x then..." would help?

CChris