Jatha

I have stumbled upon Jatha in my travels of the web on this fine Saturday afternoon. I am quite stumped by it.

I will be honest, I did not spend more than 30-60 minutes on looking at it. I was trying to get ahold of the big picture behind the code, something that I like to do before digging in.

I will say that my ideas and theirs have nothing in common. It appears to be attempting to be a lisp interpreter written in Java (complete with registers!). Why you would use a Lisp interpreter written in Java instead of one written in Lisp (and already written, by the by) is beyond me. But the idea of Lisp in Java intrigued me, so I want to elaborate on it for a little while.

Idea: Lisps concepts mapped to Java

Rather, this should be "Lisps concepts mapper to OO design." Let us take, for a moment, the concept that everything in Lisp is data, where the first piece of data in a list is commonly evaluated. We can extend that concept to say, correctly, that everything in Lisp is a list, and every piece of a list is either another list or an atom. Let's then apply that concept to Java, and say that in Java, again correctly, that every class extends Object, or rather that every instance of every class is an Object.

Let us then define two Objects that everything in LispJava will extend from: Atom and List. Luckily for us List is already defined, so we can go ahead and use that (we can even use LinkedList if we like). And Atom is just Object with an "eval" method. For all numbers, this eval method is overloaded to return itself. For functions, this eval method is a bit trickier, for you need to write real java code that would operate on the arguments, so eval would need to take a list as an argument (the remaining elements, or cdr, of the list starting with the function).

Then, you can have lists of these LispLists or LispAtoms, and these can moved around and generated by regular JavaCode, thus giving you a way to create a MetaProgram inside the JVM. Adding functions would be a function of adding new LispFunctions (which are LispAtoms which are in turn LispObjects) and inserting them as needed into your program. You would effectively have created, via polymorphism, a redefinable language inside of Java.

Could you then extend this to include closures and Lambda functions as well? This would be tricky, but you would effectively have to create anonymous inner classes that contain pointers to the information. Macros? This could be a superset of LispObject creators that take arguments themselves.

Why would you want to do this, though, when you have Lisp already?

Perhaps it IS true that programmers will rather learn a new API than a new language. And to those I wish you to look at what I have written above and ponder this fact: If you can understand how polymorphism and inner classes achieve closures and the ability to swap between data and functions, then you are already almost to the point of understanding Lisp. You just need to start seeing every atom, every list as an object that can be moved, changed, created dynamically and extends from the One True Lisp Object. After you achieve that hurdle, and you can see how it would be useful, maybe you should give parentheses a try.

If you still can't stomach the parens, give Ruby a try. It gives you everything I've talked about without Lots of Infuriating and Silly Parentheses.