Jarc - An Arc interpreter written in Java

What's Cool about Jarc?

Interactive Debugger

Compiler for the JVM

Jarc 12 now has a compiler which optimizes tail-recursive functions. It's not generic tail-call elimination, but it can optimize functions that call themselves.

SQL Access

Regular Expressions

What's Lame about Jarc?

Web Apps

Jarc has a Java Servlet for creating web apps in arc. It doesn't use the standard arc html package. Jarc web apps looks like this:

(use 'jtml)

(def /hello (req res)
      "Hello World. "
      ;; Query parameters are available by apply:
      (p "Hi to " req!name)
      ;; All getXXX methods of HttpServletRequest are available by apply also:
      (p "Request method is " req!Method)
      (p "Cookies: "
	  (each cookie req!Cookies
	    (li (pr (getName cookie) '= (getValue cookie))))))
      (p (a href '/ "Index"))

How is Jarc different than Arc?

Jarc's goals are:
  1. It should be as easy as possible to call Java methods.
  2. It should be compatible with Arc.
Java method calls look just like Arc function calls:

(def msec ()
  (getTime (new java.util.Date)))

The "new" function creates an instance of a Java class.

The interpreter dispatches on the first argument. [1] So "getTime" is a Java method on Date. Jarc does a run-time method lookup on the Java class and finds "getTime". Arguments are automatically converted into the appropriate Java types to make the call whereever possible. In this simple example there are no arguments being passed to "getTime".

Static Java method calls also look just like Arc function calls:

(def system (cmd)
  (let proc (exec (java.lang.Runtime.getRuntime) cmd)
    (let in (new java.io.BufferedReader
		 (new java.io.InputStreamReader (getInputStream proc)))
      (awhile (readLine in) (prn it))
      (close in))))

This conflicts with the dot notation in Arc. Jarc trades-off compatibility in this one instance for easier Java method access. It saves typing one whole token!

If a static method is not found, then Arc dot notation semantics are used, so in practice there isn't any conflict.

Starting with Jarc 8 methods on java.lang.String automatically apply to Jarc strings.

   (replaceAll "foo" "o" "e") => "fee"

You can override methods on java.lang.String with macros, but not with functions. Java method calls take precedence over Arc functions. And macros take precedence over everything, of course.


I started writing this because I wanted a powerful language to write quick and dirty throw-away programs that call existing Java APIs. Like the Java API for the network management product I used to work on during the day. The main goal is that calling Java classes should be as concise as possible.

Jarc began in 2005 before Paul Graham released arc0. He had written enough on his web site about his ideas for Arc, that I was able to build something close to what Arc actually is.

I have used this at work to build two prototypes and also for some throw-away data crunching. It has been a great tool. Much better than writing in Java!

After Arc was released I updated Jarc to be compatible with Arc.

The biggest difference was that Jarc had dynamic binding and Arc does not. Changing that broke the cool things about Arc, like the debugger and sql package. They had to be converted to not rely on dynamic binding.

Current Status

The lastest version is available at: Jarc SourceForge download page.

You can also browse the source code on SourceForge.


[1] Paul Graham suggested that Arc might have dispatch on first arg in Arc at 3 Weeks.

-JD Brennan, Sep 16th, 2010