mark-probst

I'm looking forward to it! :-)

Compiling to machine language doesn't automatically make code fast, neither does compiling to C make it automatically slow(er).

There is very little about C that makes this inherently slow, and almost all of the stuff one has to do to make it fast has to be done when targeting machine code as well.

On the other hand the C compiler does lots of things very well that would otherwise have to be coded by hand, like register allocation, interfacing with existing code, and, yes, portability.

This example is completely contrived, of course:

  (let [x 1]
    (defn make-adder [y]
      (fn [] (+ x y)))
    (defn make-multiplier [z]
      (fn [] (* x z)))
    (defn mutate! [new-x]
      (set! x new-x)))

Now for

  (make-adder 2)

we get a function whose environment includes x and y, whereas the environment for

  (make-multiplier 2)

includes x and z. Assuming you have shallow environments, you'll have one environment [x' y] and another one [x'' z], whereas with deep environments (like in ClojureC) you'd have [[x] y] and [[x] z] where the [x] is shared between them. Now, if you call

  (mutate! 3)

with deep environments you only need to store the 3 once (to x), whereas with shallow environments you'll need to store to x' and x''.

I'd say - optimistic estimates (for pessimistic, multiply by 2) - core language 1 more weekend, core library 2 more weekends after that. So far it's been about 3 weekends of work.

Contributors are always welcome ;-)

A dynamic vector will not work in the general case because environments can "fork". You can, however, have shallow environments, where making a new environment based on an old one involves copying some or all of the old environment's fields. That can become a problem, however, if your language supports set!ting local variables - the local variable might be represented in more than one environment, so you'd have to keep track of that and do more than one store.

See Andrew Appel's "Compiling with Continuations", for example.

It's too early to do benchmarks. Nothing in ClojureC is optimized at this point, so it would do very badly. I'm focussed at making it work first, then on making it fast. We'll get there.