Ecru, A C Runtime For E

I'm happy to announce Ecru, a new implementation of the E language.

E is a language designed both for security and safe and efficient concurrency. Twisted borrowed the idea of Deferreds from E, where they are much better integrated into the language than in Python, owing to the syntax and library support E provides. E's design is based around capability security, even to the level of allowing mutually untrusting programs to run in the same process. Due to its consistent focus on security, it's possible to write secure programs without having to do much more than stick to good object-oriented style.

My goals with Ecru development are, initially, to develop an environment suitable for restricted execution of the type that my esteemed colleague has been looking for, allowing safe scripting of server-hosted applications. A wider goal is to provide an effective replacement to the C implementation of Python for development of network software; a successor to Twisted, as it were. Furthermore, E's semantics lend themselves to more efficient implementation than Python's. Although Ecru has received essentially no optimization work thus far, I believe it may be possible to make it faster than Python for many tasks, without being any more difficult to work with.

Right now Ecru depends on Python, since I'm using PyMeta for its parser. Ecru only implements enough of E to run the compiler; I plan to soon implement OMeta in E, so that Ecru can also be used standalone. There's a simple REPL in Python, so you can download Ecru and try it out right now. Currently I'm focusing on cleaning up the code (bootstraps are usually messy affairs) and replacing some of the standard-library object stubs I wrote in C with the versions implemented in E in use by the existing Java version.


Timothy Fitz said...

Of your esteemed colleague's requirements, which does the Java implementation of E not support today?

Allen Short said...

#2, #3, and #4. CPU restriction might be easiest to add, but it's an AST-interpreter so some restructuring might be necessary. Memory restriction would be tough since Java doesn't give you much control over allocation; everything goes in one big heap. Efficiency is also a concern - it's an interpreter written in Java.

Anonymous said...

When Democracy fails, you can count on Stalin!