Eph

History

During my last year in high school (2008 / 2009) I was working on a compiler for my own modern programming language, Eph. As I realized lately, the roots of this project date back to 2006 when I first tried to develop a compiler in C++. Back then, though, I couldn’t really decide on whether to develop a compiler or an interpreter (thus, language features were a rather fluid concept ;-) and C++ was a horrible language for programming it the modern, object-oriented way, too, so I gave up when I got to the semantic analysis.

The idea wasn’t dead, though, and neither was the wish to create a compiled, fully object-oriented and therefore simple programming language which erases all the awful mistakes people made when designing C++. (Meanwhile, the beauty of Python convinced me that there’s no need for an interpreted language.)

It came up again when I entered my last year in high school (2008 / 2009): I intended to file the project as additional 5th exam in Computer Science for my Abitur (A-levels). That imposed a though time limit of a less than a 3/4 year on me during which I had to complete the following:

• create a sound concept for the language
• document the language features and design reasons
• develop the compiler itself
• keep records of the development process

I managed to get to the semantic parser again (this time in Java) but then struggled with my original ideas for the language. Till this point I hadn’t had to decide on a final concept because – as the whole thing was rather an experiment – I developed the software in a very object-oriented way which would still allow me to change, add or remove language features later on. I rethought my concept and arrived at the conclusion that my previous concept was literally bullshit and I didn’t have the time (I had like 1 month left) for brainstorming all over again. Also, I had been ill for some weeks and of all times it had to be the Christmas holidays which I originally planned to dedicate to the project. All this finally made me put Eph on ice.

Lately, though, the idea to continue the project has crossed my mind again which is why I decided to rethink it publicly. So, what I always had been absolutely clear about and still are (concerning the language features) you can find below. I tried to write everything down from pure memory. Also, there’re some new ideas that made their way into the list.

Finally, you can also take a look at the source code (Java). May it inspire you to develop a compiler yourself. :) Unfortunately, I didn’t create a proper documentation of the language features I planned and implemented at the time of programming (as I had everything in my mind) and probably won’t in the near future, either.

Planned features

Python-like syntax

• No semicolon at line end
• Avoid parentheses and curly brackets
• Mark blocks by indenting them. Statements which are followed by a colon (see example) always induce a block.

Strong object-orientation

• Every variable is an object. This also holds true for elementary data types.
• Prevent programmers from using singletons and static methods in a bad way (i.e. from implementing things as global state)
• Allow programmers to extend existing classes for their own purposes (to prevent them from creating static libs like java.math) to avoid things like those described here.
• Related articles I found during brainstorming (read: I explicitly agree with Miško Hevery’s ideas):
  • Constructors:
    • http://misko.hevery.com/code-reviewers-guide/
    • http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/
  • Global state & singletons:
    • http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
    • http://misko.hevery.com/2008/08/21/where-have-all-the-singletons-gone/
    • http://misko.hevery.com/2008/08/25/root-cause-of-singletons/
    • http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/
  • Static methods:
    • http://misko.hevery.com/2009/07/31/how-to-think-about-oo/
    • http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/
  • Dependency injection:
    • http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/
    • http://misko.hevery.com/2008/08/29/my-main-method-is-better-than-yours/
    • http://misko.hevery.com/2008/09/10/where-have-all-the-new-operators-gone/
    • http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/

Data types

• Easily convertable to each other
• Built-in support for different string encodings
• Built-in support for byte sequences / streams
• Operators may be overloaded for own data types (classes)

Miscellaneous

• Extensive reflection
• Anonymous functions
• Automatic garbage collection
• Extensive, built-in support for concurrency
• Aspect-oriented programming (AOP) (maybe to be combined with concurrency and class extensions?)