views:

205

answers:

6

I want to embed a dsl or existing full language within my application. It should be a simple, full Turing complete language but simple and light enough that the code can be interpreted without too much overhead.

Also the other "processes" can't effect any other process.

I was considering using Clojure and invoking the Clojure interpreter/runtime compiler on Clojure code but the Clojure runtime takes a lot longer than I would need. Also, I am not overly excited of using the Clojure language for this project. I was thinking more procedural and C-like.

I considered Ola Bini's Ioke language. http://ioke.org/index.html

Also, I considered writing a DSL in Scala ? Or using an existing DSL.

Updated: It looks like Rhino is exactly what I want. Because I am working with 1.5 java.

http://www.mozilla.org/rhino/tutorial.html

+8  A: 

Groovy's dynamic nature is ideally suited to writing DSLs. Indeed there are a large number of Groovy DSLs implemented by the Grails web framework, and plenty of tutorials and books that teach how to write DSLs with Groovy.

Also, Groovy's syntax is almost a superset of Java's, so it should be relatively easy to pick up (compared to Clojure). Calling between Java and Groovy code is seamless, so you can easily use all your favourite JDK classes within Groovy code.

I'd be inclined to avoid IOKE on account of it's immaturity and for the purpose of a DSL, I think a dynamically typed language like Groovy or JavaScript is a better choice than Scala.

Don
+13  A: 

How about JavaScript?

http://java.sun.com/javase/6/docs/technotes/guides/scripting/programmer%5Fguide/index.html

It's built in to Java 6.

hallidave
+1, use standard facilities where available, and JS is by far the most popular and well-known scripting language out there.
Pavel Minaev
+1 didn't know that...nice.
kenny
I throw holy water at hallidave and wield my cross and garlic
Jherico
Using one always present in the language will save you MUCH grief in the long run. It is 1) standard and 2) maintained. Two very interesting properties :D
Thorbjørn Ravn Andersen
Just to clarify: JavaScript is *not* an official part of Java 6. But the Sun JRE/JDK come with a JavaScript engine. The Mac OS X JRE *doesn't* come with a JavaScript engine and is stll perfectly valid Java 6 JRE. So to be truly portable, you'll have to ship with a ScriptEngine (for example Rhino).
Joachim Sauer
+1  A: 

If you want a DSL, then you don't really want to embed an existing language, you want to create a "Domain Specific Language". To me that means a lot more than just changing some keywords and not using parenthesizes.

For instance, right now I'm working on TV Scheduling right now. When we create fake guide data for a test, we always add a comment that looks like this (cut directly out of the test I'm working on):

 * TIME:8.....30....9.....30....10....30....11....30....12....30....
 * 4FOX:____________[Spotlight.............][Jeopardy..]____________
 * 6CBS:[Heroes....][Heroes....][Heroes....]________________________
 * 8HMK:xx[A.River.Runs.Through.It....][Blades.Of.Glory...]_________

If I have to create more guide data, I'll directly interpret those comments as a DSL (Making them a long string or string array instead of comments).

That would be an appropriate DSL.

If you're just after embedding a flexible language, Groovy or JRuby are both made for this, as is BeanShell.

There is, in fact, an entire API built around replaceable plug-in scripting languages so that you should be able to drop in any JVM language you want and not change your code a bit.

Bill K
It is possible to use a small subset of a language as a DSL. Then you get the benefit of the compiler combined with the smallness hopefully making it useful to the domain experts.
Thorbjørn Ravn Andersen
It's possible, but you.end_up.with really_bizare.and_stupid_syntax when you could actually just write a little interpreter. I despise what Ruby people have done to the concept of a DSL
Bill K
Also, by the way, you are restricted to the syntax of the language--so you would never consider doing something like the example I gave in the answer. Many good DSLs would be completely beyond a generic interpreter and therefore would be beyond consideration by someone who went straight for some canned interpreter as the base of their DSL
Bill K
+1  A: 

I suggest Java. It's: well known, fast, easy to integrate with Java, stable, statically typed, easy to migrate code, etc., etc.

Tom Hawtin - tackline
A: 

A small BrainF*ck interpreter should be fine according to your spec :)

If it is not quite what you had in mind, then consider what it is you want to solve. What is your case study? Is it to be able to add new code at will later without having to redeploy a new verison of your application?

Thorbjørn Ravn Andersen
+2  A: 

Check out scripting.dev.java.net for a list of Script Engines for embedding other languages in your Java applications. Note that some of the referenced languages now ship with their own JSR 223 integration, so there's no need for a 3rd party library to use them.

McDowell
The only sensible suggestion here. It's stupid to embed a single language when the runtime supports a standard way of exposing properties of the host language to a multitude of scripting languages.
pmf
It depends on what VM runtime (E.g pre 1.6) you are using and what you want to do with your application. One issue with a lot of the standard scripting languages are how slow and memory intensive they are. For example groovy is slow and memory intensive.Rhino, not so much.What you are saying is, you are saying that DSLs are stupid. I don't think that is the case.
Berlin Brown