OpenEuphoria

2. Re: Euphoria's inconsistent typing

• Posted by petelomax Nov 04, 2015
• 2125 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

4. Re: Euphoria's inconsistent typing

• Posted by petelomax Nov 08, 2015
• 2060 views

There are plenty of reasons to stick with OpenEuphoria - it works on more platforms, it has more features, more people working on it, etc.

There is nothing to stop you trying Phix on the same computer, but if you run pgui/Settings, make sure you understand how to undo any changes you make that could affect OpenEuphoria, namely select merge undo.reg from the dropdown and click OK.

I might suggest the following reasons why someone might prefer to use Phix: smaller install, easier to modify and rebuild, threads, direct comparison (eg name="pete"), variable length slice substitution, automatic includes, and named parameters. There's also a new properly short-circuited iff() construct that I'm starting to find very useful, and a nifty little scanf() routine. There are also reasons to stay away.

There is nothing wrong with the two co-existing, quite the opposite I hope.

Pete

6. Re: Euphoria's inconsistent typing

• Posted by jimcbrown (admin) Nov 08, 2015
• 1934 views

I don't think that this works... the problem is, it looks like it is more fun to add new features to the language than it is to fix the bugs in the older stuff.

We put a feature freeze on 4.1.0 for exactly this reason, only to see the release of 4.1.0 held up indefinitely.

I think we should adopt the linux-next idea ( http://sourceforge.net/p/rapideuphoria/mailman/rapideuphoria-develop/thread/20110130234809.GA29676%40jbrown.linuxbuddhist.net/#msg26983630 ) - create a branch for the stable 4.1.0 release and then open up the openeu-next branch for rapid development (and rapid breakage).

That said, I also like the committee idea ( http://openeuphoria.org/forum/m/128867.wc ) . I think maybe we should appoint a committee to be responsible for releasing 4.1.0-RC1 and maybe even 4.1.0-final by a set date (say X-mas 2015).

8. Re: Euphoria's inconsistent typing

• Posted by elias_maluko Nov 08, 2015
• 1917 views

structure rgb  
    integer red  
    integer green  
    integer blue  
end structure  
  
rgb fgcolor = {0,0,0}  
fgcolor.red = #FE -- means fgcolor[1] = #FE  
fgcolor.green = #3B -- means fgcolor[2] = #38  
fgcolor.blue = #60  
  
sequence s = {0,0,0}  
s[1] = 0 -- okay  
s.red = 0 -- error (must declare s as rgb)  

Shawn you just read my mind on this one. I was thinking in this a bit different:

type rgb 
    integer red 
    integer green 
    integer blue 
end type 

I mean, replacing euphoria's 'type as function' by this.

What about the syntax for function type definition? Maybe something like Basic :o)

function foo () as integer 
  return 123 
end function 

Combining this new kind o type definition and function return declaration could speedup interpretation code and simplify the compiler.

10. Re: Euphoria's inconsistent typing

• Posted by petelomax Nov 09, 2015
• 1849 views

function foo () as integer 
  return 123 
end function 

The compiler will figure that out anyway. I maintain that the correct syntax for this (and more complex cases) is

function foo () 
integer res 
  res = 123 
  return res 
end function 

The problem, as I see it, with an "as xxx" clause is that should your function yield say either some udt or {}, you've got problems explicitly specifying that in an as clause, whereas if you just let the compiler figure it out, it'll do a better job.

Consider also something like:

constant DEBUG = 0 
function foo () 
  if DEBUG then 
    return {1,2,3} 
  end if 
  return 0 
end function 

It is trivial for the compiler to spot the result is always 0 when DEBUG is 0, and utterly ludicrous to attempt to encapsulate that info in an as clause.

(something like function foo() as iff(DEBUG=0?integer[0..0]:sequence[length 3..3]of integer)?! - and yes, that info is all something that the compiler already collects)

12. Re: Euphoria's inconsistent typing

• Posted by petelomax Nov 12, 2015
• 1802 views

rgb foo = {2,4,5} 
sequence goo = foo -- okay 
foo = goo -- error. 

Can you post a better example than that, because it shouldn't generate a run-time error and it shouldn't generate a compile-time error.

The thing is, you've just told the compiler that goo is an rgb, and indeed it is an rgb. In fact, as written you have a problem on line *1*: error: storing a sequence in a variable declared as rgb.

If you're thinking that you can only put an rgb in a variable declared as rgb into another variable declared as rgb, then we have another big problem: once you put anything into a sequence, you have no way to ever get it back out.

Pete

14. Re: Euphoria's inconsistent typing

• Posted by SDPringle Nov 14, 2015
• 1751 views

rgb foo = {2,4,5} 
sequence goo = foo -- okay 
foo = goo -- error. 

rgb foo = <cast_as(rgb)>{2,4,5} -- okay 
sequence goo = foo -- okay 
foo = <cast_as(rgb)>goo -- okay 
foo = goo -- compile time error. 
foo = <cast_as(rgb)>"not an rgb" -- (run-time?) error. 

I see, these points are right. I mean, the procedural UDT just checks things at run time only (EUPHORIA style). Cpp style declarative types things get checked at parse time. EUPHORIA 5.0 could have both.

You're right about not being able to get your objects back out once you put it into something that doesn't have a declarative type unless you have casting. In this example, goo should be also declared as rgb. Now if you cast a string which has a length different from the length of a rgb to rgb, arguably this should be a runtime error.

Now, array like syntax which just means a sequence where the parser knows and enforces each member of this sequence is a rgb gives us a way to have sequences of rgb in a safe way.

So in designing a language feature like this there are many possibilities:

Consider another structure

structure hsv 
   integer hue; 
   integer saturation; 
   integer value; 
end structure 

Strict typing like outlined above. structures are like inherited from the built-in type of sequence.

rgb foo =  {1,2,3} -- error 
sequence goo = foo -- okay 
hsv baz = foo -- error 
goo = baz -- okay 

Non strict between non-declarative type to declarative type but strict between declarative types

rgb foo = {1,2,3} -- okay 
sequence goo = foo -- okay 
hsv baz = foo -- error 
goo = baz -- okay 

You don't want people interpreting hsv values as rgb values or vice versa.

SD Pringle