OpenEuphoria

Re: bitwise operations limited to 32 bits

• Posted by SPringle May 05, 2010
• 1267 views

I don't think it is bad that you can turn type-checking off. If you think it should stay on leave it on. In the case of hard coding the condition you can't turn it off, even when you know the code is error free.

In my opinion, the problem is when you type check a long sequence of values testing each member against a test and if the sequence is very long, it is really hard to understand what part of the list is wrong.

type datetime_list(object s) 
    if atom(s) then 
         return 0 
    end if 
    for i = 1 to length(s) do  
        if not datetime(s[i]) then 
            return 0 
        end if 
    end for 
    return 1 
end type 
 
datetime_list list 
list = get_list() -- type check error here of list 
 

This routine will say that the list is wrong in the routine that uses the type and put an impossibly long list into ex.err. The first ten records will look fine. On the other hand, it seems reasonable to do the following:

type datetime_list(sequence s) 
    datetime dt 
    for i = 1 to length(s) do  
        dt = s[i] -- type check error here 
    end for 
    return 1 
end type 
 
datetime_list list 
list = get_list() -- type check error here of list 
 

If the value s[142] is not a valid datetime, this type routine implementation would make it clear where the problem is via the variable i. However, when you call the type as function to validate data you will get a crash in the validation process. We do not want that.

sequence s = get_list() 
if datetime_list(s) then -- type check error here!  BAD 
 

The first implementation is the correct one, but the second is much simpler and will be better optimized. It would be nice if the interpreter would act differently when you call the type as a function. As a function, a type-check failure inside the type-check could just exit the call chain with a return value of 0, ala longjmp for example.

Shawn Pringle