Re: Who is compiling Eu, and why?
- Posted by jimcbrown (admin) Jan 30, 2015
- 1939 views
Ok, over to the development team: Can you develop new features in OE faster and easier if those new features are not simultaneously pushed into the compiler, and future OE work be only for the interpreter and binder?
It depends on the specific features (e.g. definitely yes for string execution), but in general, the answer is no. Most of the work in adding a feature tends to be in the parser/scanner, which is written in Eu and is a piece of code shared in common, or it's in the runtime library, which is written in C and also generally shared in common (with a couple of exceptions).
What is desired is to leap beyond what OE is, instead of OE playing "a-catch-up-with-sequences". We don't need 10 new ways to use match(), we need assorted core features, some of which have been shown over the years in interpreters done by Karl, Matt, and Pete.
Pete Lomax's Phix is written in Phix, and so runtime changes are probably a lot easier to do there - there's generally no need to deal with C.
Matt's OOEU was based on the Eu backend. A lot of his features are just plain hard to get right in the C backend/C runtime library (which would be ncessary to get it working with the conventional interpreter/binder/shrouder).
(IIRC Karl's work with Bach was done under a less than open-and-free license, so I don't have any information on the work he did there.)
