OpenEuphoria

Re: Euphoria's inconsistent typing

• Posted by petelomax Nov 04, 2015
• 2316 views

The compiler uses a (constant/)type propagation scheme which probably does a better job than you imagine. Suppose you have a function x(object y) and there is only one call to it: f(5). The compiler deduces that y is only ever an integer in the range 5 to 5. It even knows when a sequence contains only integers, and therefore that s[i] yields an integer. I gleefully plagiarized and extended some of the ideas in Euphoria for Phix, if you are interested they are in pltype.e which you can find at https://bitbucket.org/petelomax/phix/src - but be warned I found that code the hardest thing to get right out of the lot. I completely forget where the equivalent code in OpenEuphoria is, maybe someone else can point you at that.

If you think of something even mildly difficult, then admittedly the compiler will probably not get it right, but the dumb obvious cases (easily over 90%) can and do make a huge difference.

function foo() 
  sequence s = {{1},2} 
  return s[2] 
end function 
 
--compiler dont know what foo returns ahead of time 
atom a = 1 + foo() 

In which case why not write

function foo() 
  sequence s = {{1},2} 
  atom res = s[2] 
  return res 
end function 

In (simpler) cases where the compiler has managed to get the type propagation right, it will even omit the unnecessary type-check, and in that case there is absolutely no performance difference whatsoever between using an explicit res variable and the hidden un-named temp variable that the compiler would otherwise have to use anyway.

--Type information have limited advantage something like this is more consistent: 

As above, I beg to differ

var a = 1 
var s = {} 

Now that I don't follow. Is that supposed to be somehow different to:

object a = 1 
object s = {} 

One last thing:

Regards,
Pete