[Harbour] Re: [xHarbour-developers] Extended field types in RDDs

[Mindaugas Kavaliauskas]

> In general if we define that NULL value should effect any of operators then
> we force modifing HVM. How it will effect different operators is unimportant
> because we can implement ant behavior, f.e. both:
>     VALUE1 <= 100 
> and
>     VALUE1 > 100
> may return false if VALUE1 has NULL attribute.
> But I do not like it because it will block us to add some compile time
> optimizations like replacing:
>     IF ! VALUE1 <= 100
> with:
>     IF VALUE1 > 100
> 
> because in first case result will be TRUE and in the second one: FALSE.

Perhaps the correct solution in this case is returning NULL value is any 
operand is NULL, i.e.
    NULL <= 100 returns NULL,
    NULL > 100 returns NULL,
    ! NULL returns NULL,
    ! (NULL <= 100) also returns NULL,
and IF NULL is treated as IF .F.


> In the future I plan to add to compiler optimization switch (not enabled
> be default) which will force much more aggressive expression reduction
> using standard math rules. 

What kind of optimization is it?! :)


> Please also note that some operations on NULL values cannot generate RT
> errors and have to be accepted by RTL functions or you will not be able
> to execute even simple BROWSE().

We can block NULL values from speading over the application. If any 
argument of function call is NULL, then function will return NULL. The 
exception is function ISNULL(). All this could be hacked inside 
hb_vmDo(). It will solve the problem of
     SET FILTER TO some_rtl_func(some_null_field) > 0
But this solutions seams to be too hacky and perhaps have many side effects.


Best regards,
Mindaugas