Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am currently working on the implementation of a new programming language, for fun. I realize that most languages never become popular, but I still want the language to have a high-quality implementation. The language is loosely lisp-like. It supports closures, first-class continuations, a homoiconic syntax, first-class functions, etc. In addition, I want my language to be able to have access to already established library code (specifically the Java Standard library, etc).

Dynamically compiling to JVM byte-code is essentially out of the question, because of the difficulty of implementing the stated feature set (excluding first-class functions) using a virtual machine that is not designed to support it. On the other-hand, compiling to C/C++ or some other lower-level language will lead to an unwanted degree of platform-dependence and/or reduce/remove the ability to use the Java standard library via programs written in my language.

My (largely-completed) approach to the implementation is to implement a custom p-code interpreter in Java. The high-level language simply compiles its code on-the-fly to essentially an array of instructions for this custom virtual machine. Each instruction is an object that implements a common interface. When executed, the instructions manipulate a stack-machine. Unfortunately, executing each instruction requires a virtual method call; whereas, the normal implementation of such interpreters does not use object based instructions. However, current micro-benchmarks and guess-based-estimates indicate that the completed implementation should match the speed of Python, given equivalent programs.

So do you think this method of implementation is crazy or amateurish, given the language's design goals?

What would you do differently?

share|improve this question

closed as primarily opinion-based by MichaelT, GlenH7, Simon, Bart van Ingen Schenau, gnat Jan 2 '14 at 19:49

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Note that to ensure the high quality with limited man power you need automatic testing of functionality. Perhaps even Test Driven Design. Do it right from the start - it will save you time and perhaps even your project. – user1249 Apr 21 '11 at 7:19
Are you looking for performance or functionality? I'd recommend getting the functionality right, then worrying about performance. And imo Java is a win for development speed. Groovy, Python, or another dynamic language may be better still. – Anon Apr 21 '11 at 13:12
up vote 3 down vote accepted

What you propose seems like a generally sound approach. The object-per-instruction might be a bit heavyweight, but there's no reason you can't start with that, especially if it's an easy design to work with.

Although you suggest that compiling to bytecode is out of the question at the moment, that's something you can always decide to add later. You can have a runtime environment that interprets some code and compiles the rest of it (Lisp environments have been doing that forever, and JIT compilers continue to do that today).

Keep in mind that there can always be more than one language implementation. C++ was first implemented as Cfront, a preprocessor on top of C. Early JVMs always interpreted bytecode, but they almost all JIT now. Python has multiple implementations, some of which even compile down to native machine code where possible.

share|improve this answer

Dynamically compiling to JVM byte-code is essentially out of the question, because of the difficulty of implementing the stated feature set (excluding first-class functions) using a virtual machine that is not designed to support it.

There are a lot of languages supporting most of the features you describe already that compile to JVM byte-code (JRuby, Scala, Clojure). The implementations of those languages are open-source, so I would recommend to study their approach in implementing these features on the JVM.

But since your stated goal is fun, I can imagine that looking through the compiler implementations of other languages is not something you want to start with.

My experience in implementing a programming language on the JVM is that it will easily work, but have some rough edges, especially around performance and memory consumption when you suddenly use a little more data than in a toy program for testing.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.