OpenEuphoria

Euphoria Ticket #118: object() tests fail when translated

• Reported by ne1uno Nov 12, 2009
• 11 comments

function from_object(object x=4.1, integer a=1, atom b=2, sequence c="3") 
  return {object(a), object(b), object(c), object(x)} 
end function 
 
object oarg=5 
 
test_equal( "from_object()" 
        , {OBJ_INTEGER,OBJ_INTEGER,OBJ_SEQUENCE,OBJ_ATOM} 
        , from_object() ) 
test_equal( "from_object()"  
        , {OBJ_INTEGER,OBJ_INTEGER,OBJ_SEQUENCE,OBJ_INTEGER} 
        , from_object(oarg) ) 
 
 
function u_object(object x, integer a=1, atom b=2, sequence c="3") 
  return {object(a), object(b), object(c), object(x)} 
end function 
 
object uarg    
 
 
oarg= {} 
test_equal( "oarg empty brace is object3", 3, object( oarg ) ) 
 oarg= "" 
test_equal( "oarg empty quote is object3", 3, object( oarg  ) ) 
 
test_equal(" atom(args) args={}", 0,  atom({}) ) 
test_equal(" sequence(args) args={}", 1,  sequence({}) ) 
test_equal("object args={}", 3, object({}) ) 
object arg= {} 
test_equal("object args={}", 3, object(arg) ) 
object args= {0} 
test_equal("object args={0}", 3, object(args) ) 
 args= {{"" }}  
test_equal("object args={ }", 3, object(args) ) 
integer a= 0 
test_equal("object integer=1", 1, object(a) ) 
atom n=1.1 
test_equal("object integer=2", 2, object(n) ) 
atom ir 
test_equal("object ir=0", 0, object(ir) ) 
 

translated results 
test name 	test time 	expected 	outcome 
from_object() 	0.000000 	{1,1,3,2} 	{1,1,1,1} 
from_object() 	0.000000 	{1,1,3,1} 	{1,1,1,1} 
oarg empty brace is object3 	0.000000 	3 	1 
oarg empty quote is object3 	0.000000 	3 	1 
atom(args) args={} 	0 	  	  
sequence(args) args={} 	0 	  	  
object args={} 	0.000000 	3 	1 
object args={} 	0.000000 	3 	1 
object args={0} 	0.000000 	3 	1 
object args={ } 	0.000000 	3 	1 
object integer=1 	0 	  	  
object integer=2 	0.000000 	2 	1 
object ir=0 	0.000000 	0 	1 
 

Details

1. Comment by jimcbrown Nov 12, 2009

I am very confused by this.

Originally, object() always returned one. Then I changed it to return 1 if the variable was initialized, and zero otherwise.

Now, it seems to return 0 if uninitialized, 1 if the current value is an integer, 2 if the current value is a non integer atom, and 3 if a sequence.

When did this happen?

2. Comment by jimcbrown Nov 12, 2009

Actuall, adding the 1,2,3 system to the translator is easy. Just the very last test (testing uninitialized) would require some work.

3. Comment by jimcbrown Nov 12, 2009

In r3009, all your tests but the last one (atom ir) now pass.

4. Comment by DerekParnell Nov 12, 2009

The change to object() occurred on Sept 27th.

I didn't realize that the translator needed anything for this, so thanks for fixing it. Nor did I realize that there are no uninitialized variables in translated programs. That seems like something that needs to be addressed; translated functions should work the same as interpreted functions.

5. Comment by ne1uno Nov 14, 2009

ship it

6. Comment by DerekParnell Nov 19, 2009

Changed this to a request.

Either change the documentation to inform people that translated programs do not have uninitialized objects, or change the translator to behave as the interpreter in this case.

7. Comment by SDPringle Feb 25, 2010

I've always hated this. The type object() should return one if the object is initialized or if not crash the program with an error whether interpreted or translated. Here is a completely, artificial divergence in behaviors between interpreted and translated code. In other words, you have one behavior when interpreted and one when translated. Certainly anyone can see that this is a fundamental violation of the intention of translated code.

Now, we had already talked about not going the perl route with 'undef' values. Dummy values can always be initialized and its just as easy to check if it is the dummy value than to call some misnamed defined() function from perl. If you want something like that then name it as such.

The type object() is there for things that can be any kind of object. object() has always been the "don't type check this" case. It shouldn't ever be used as a function.

Since the translator always initializes its data we cannot make this work consistently between interpretation and translation. The core ideal of being able to translate your code is to keep the behavior of the interpreted version. Yet, any user that uses object() for initialization of variables will be bit hard when they translate their code for production.

8. Comment by jimcbrown Feb 25, 2010

The other aspect of object() (1 vs 2 vs 3 vs 4 to figure out the type of an object) is genuinely useful and works the same on interpreted vs translated. So, I think keeping that aspect of the change should not be a problem?

The change in object() being able to detect undefined variables was added at the same time as goto. This change added a necessary feature, as otherwise there is no way to deal with some obscure cases such as a goto into the middle of a for loop. (Argubly, this puts this use of object() in the same "use only if the programmer must" area as goto itself.)

I'm not sure how the difference in behavior between object() in translated and interpreted mode would made a difference. Translated programs are not guaranteed to crash when an uninitialized variable is used. The use of object() to detect unitialized variables to avoid crashing the interpreter therefore is not as applicable or as important as doing so in the translator.

There are a few cases where we'll see NOVALUE assigned to an object in a translaated program, and then a builtin function will check and emit a crash when it sees the NOVALUE. In this case, object() behaves identically on the translator and on the interpreter - in both cases it sees the NOVALUE and returns 0, warning the code that the variable is undefined...

9. Comment by ArthurCrump Feb 25, 2010

Is object() a type or a function? If it is a type it should only ever be 0 or 1, not 2 or 3.

10. Comment by jimcbrown Feb 25, 2010

It's a type but I don't see why it can't return 2,3,4 ... the point is if it is an object() it returns true. Any non-zero value is true..

11. Comment by jimcbrown Nov 11, 2010

The original bug report was fixed. The feature request to be able to detect uninitialized objects in the translator is not very useful (unlike in the interpreter, translated code won't crash when this happens).

Include: