Compiling .clj files?

[arsala...@gmail.com]

Hi all.

Is possible to compile a .clj file to a .class file(s) for easy
distribution? I remember the docs mentioning that all code is compiled
down to bytecode in any case.

Regards.

--Arsalan

[Rich Hickey]

On Feb 13, 8:04 am, "arsalan.za...@gmail.com"

<arsalan.za...@gmail.com> wrote:
> Hi all.
>
> Is possible to compile a .clj file to a .class file(s) for easy
> distribution? I remember the docs mentioning that all code is compiled
> down to bytecode in any case.
>

There is no static compilation option at present. While all fns are
compiled to bytecode, the resulting bytecode depends on the state of
the dynamic environment. Compiling statically, while probably
possible, raises issues relating to the serializeability and identity
of object literals, the notion of load-time vs compile-time, eval-when
etc.

For ease of distribution I recommend putting your .clj files in your
jar.

Rich

[Steve Harris]

Or how hard would it be to support serializing the entire state of the
interpreter, so it could later be specified as a startup argument?

I'm currently dealing with a web-services oriented framework
(NetKernel) that allots units of work to Java methods on threads of
the frameworks own choosing, from a pool. So to do that work by
calling into an interpreted language like Clojure, it helps a lot if
the startup time of the interpreter is kept really low to service the
independent requests. Currently I've been using SISC Scheme, and I've
been depending on the ability to create custom heaps, so using large
slow-loading libraries (SXML, I'm looking at you) doesn't incur a
startup time penalty.

I'm really taking a liking to Clojure though, so I'm hoping some kind
of fast startup with libraries already loaded will be available for it
as well. Thoughts?

[Rich Hickey]

First and foremost, Clojure is compiled, not interpreted. Second, it
is a shared-heap language, just like Java, and a global namespace
language, just like Java (leaving out classloaders). So any libraries
it loads should only need to be loaded (and thus compiled) once, and
shared between threads, just like jars/classes, the only difference
being Clojure's came from text rather than stored bytecode.
Immediately after loading it is precisely the same - shareable
bytecode in memory.

Clojure's runtime is completely thread-safe. And Clojure's fns
implement Callable, and can be handed directly to Java theadpool
managers like the Executors framework.

I don't know anything about NetKernel, but I'm wondering at what point
you feel Clojure code would need to be reloaded.

Rich

[Steve Harris]

Ah OK - I think I didn't really ever get the point about Clojure being
compiled until now. I had read the words but it just seemed like an
implementation detail, I didn't realize the benefits it might have for
sharing loaded libraries among threads.

That's quite different than with SISC, where a separate interpreter
object had to be setup via the Java api for each thread, meaning for
each request in my case. And there was no practical way to share
loaded libraries among these that I could find.

It really sounds like Clojure is going to be easier. I'm going to
give it a try anyway, using Repl.java as an example.

Thanks for clearing things up.
Steve

[John Cowan]

On Thu, Feb 14, 2008 at 12:27 PM, Rich Hickey <richh...@gmail.com> wrote:

> Clojure's runtime is completely thread-safe. And Clojure's fns
> implement Callable, and can be handed directly to Java theadpool
> managers like the Executors framework.

How do they get their arguments? Callable is only for objects with
zero-argument constructors.

--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures

[Rich Hickey]

On Feb 14, 2:36 pm, "John Cowan" <johnwco...@gmail.com> wrote:

> On Thu, Feb 14, 2008 at 12:27 PM, Rich Hickey <richhic...@gmail.com> wrote:
> > Clojure's runtime is completely thread-safe. And Clojure's fns
> > implement Callable, and can be handed directly to Java theadpool
> > managers like the Executors framework.
>
> How do they get their arguments? Callable is only for objects with
> zero-argument constructors.
>

You would only treat a no-arg closure as a Callable. Same as in Java
where you would use an anonymous inner class that closed over any
needed state.

Rich