OpenEuphoria

2. Re: Phix language

• Posted by petelomax Nov 20, 2011
• 4440 views

Phix started before RDS went open source, so it is a complete rewrite.
It is an alternative implementation, with some advantages and some disadvantages.
I have no problem with OE stalwarts completely ignoring Phix or anyone flitting between the two.
I think this list includes all the major differences:

• Native 8-bit strings
• Named parameters, eg message_box(title:="title", text:="text", style:=MB_OK) works the same as message_box("text","title",MB_OK)
• No implicit sequence ops
• include file handling is a bit more intuitive, has relative directory handling, and it also does automatic includes, eg if you forget to include msgbox.e before using it, it will find it for you.
• Direct comparison (eg if name="pete" then)
• Negative indexes (as well as $)
• Variable length slice assignment (eg s="food" s[2..3]="e"; s is now "fed")
• Short circuit evaluation of all expressions (4.0 may now be the same?)
• Automatic pass by reference optimisations (for an example see bench.exw)
• inline assembly (x86)
• Additional compile-time type checking
• Automatic internal memory leak checking
• Self-hosted, no need for Watcon/Borland/gcc.
• No DOS or Linux versions.
• No floating point for loops
• Currently only one developer on Phix compared to quite a few on OpenEu. Overall I'd say it was pretty stable and perfectly usable but there is plenty left to do, including finding that special "magic" that gives it a real edge.
• There are plenty of things in 4.0 that have not made it into Phix.
• There is no intent to make all 4.0 programs run "out of the box" on Phix but modifying them to work should be straightforward.
• Many new bugs!

Right now I'm working on extensive low-level changes for native thread support, which took a murderous time to get started but are currently fair zipping along.

Regards,
Pete

4. Re: Phix language

• Posted by jimcbrown (admin) Nov 23, 2011
• 3083 views

I think enough life has been worked into Phix to make it a worthwhile project and language in its own right, and I'd hate to see it go the way of Bach.

6. Re: Phix language

• Posted by petelomax Nov 26, 2011
• 2516 views
• Last edited Feb 15, 2016

I put together a little webinar (my first ever) http://www.phix.is-great.org/tutorial.php

Not that I would ever abandon Phix, but I suspect that if I joined OpenEu I'd just spend all day arguing with everyone. Fairly often I chip in with "how I did it" comments anyway.

Regards,
Pete

8. Re: Phix language

• Posted by jeremy (admin) Nov 28, 2011
• 2314 views

I double youd spend all day arguing. Everyone is sensible and when a sensible feature is suggested, it's easily adopted. Arguing only pursues when there is something very controversial or something that deviates vastly from where we are. In that case, a good discussion should be had. But... with the Phix language, it seems to be going in the same direction. I wouldn't think there would be any problem.

Jeremy

10. Re: Phix language

• Posted by petelomax Nov 29, 2011
• 2085 views

It's not entirely straightforward.

Both OpenEu and Phix have 31 bit integers in the range #C0000000 to #3FFFFFFF, ie beginning 0b00 or 0b11. I think they both use #40000000 to indicate <no value> and other values are shifted memory addresses. OpenEu shifts 3 bits, requiring data to be quad-word aligned, and uses one bit to distinguish a float from a dword-sequence (cmiiw). Phix shifts 2 bits, only requiring data to be dword-aligned, and uses a type byte in the data header, potentially 255 datatypes, currently using 3: #12 float, #80 dword-sequence, #82 8-bit string.

Performance-wise, some programs are up to four times faster in Phix, but several indexing operations are (unavoidably) around 30% slower, because of an additional low-level test.

A program like Edita is noticeably faster but a fair number of benchmarks are slower. Swings and roundabouts I suppose but if pushed I'd have to say adding 8-bit strings to OpenEu would probably not be a good idea, especially so with the extent of the changes it would require. Likewise adding say #81 to Phix for a bit array could potentially increase that 30% overhead to 60% on general subscript ops.

So to answer your question it is a hidden implementation detail, with gains and losses.

Regards, Pete

12. Re: Phix language

• Posted by petelomax Nov 30, 2011
• 2021 views

Strings are "auto-expanded" when necessary. For example

  s = {-5,0}&"ab" -- s is now {-5,0,'a','b'} 
  s = "ab" & -5   -- s is now {'a','b',-5} 

Internally, the compiler creates 8-bit strings when it sees double quotes and dword sequences when it sees curly braces.

Elsewhere, dword-sequences can be used in place of strings, eg

  open_dll("kernel32.dll") 
  open_dll({'k','e','r','n','e','l','3','2','.','d','l','l'}) 

behave the same though the later automatically does the same sort of "pack" that OpenEu must be doing.

The only real oddity is that prepend always yields a dword-sequence since otherwise prepend(string,char) would perform a complete copy to avoid non-dword aligned data, which gets a bit costly when you do it lots of times. But apart from explicitly testing it, you can use the result as if it was a string, so it doesn't really matter.

Regards,
Pete