ClojureC, a compiler for Clojure that targets C as a backend • Hacker News Board

Re: ClojureC, a compiler for Clojure that targets C as a backend

#51

Post by saosebastiao » Sun, May 05, 2013, 4:03 AM UTC

mullr wrote: post #26

This is neat. What worries me about this and similar efforts (like https://github.com/takeoutweight/clojure-scheme ) is that clojure's standard library design assumes that the underlying runtime will be do some kind of polymorphic method inlining. For example: the sequence library is all defined in terms of ISeq, which basically requires a "first" and "rest" to be defined for the data structure in question. These are…

Yeah, I wish we could somehow persuade Mike Pall to work some magic here. LuaJIT's general design sounds like the perfect fit for something like this.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#52

Post by uvtc » Sun, May 05, 2013, 4:15 AM UTC

timbaldridge wrote: post #2

sadly, this doesn't seem to support any sort of multithreading. Even something as simple as swap! isn't thread-safe in this implementation. So that kills one of the main reasons to use Clojure in the first place.

> sadly, this doesn't seem to support any sort of multithreading

Maybe multithreading is just not yet implemented?

> So that kills one of the main reasons to use Clojure in the first place.

I could see ClojureC being very useful for when you want:

  * small footprint
  * easy C-library interop
  * fast start-up time

and where you don't necessarily need multithreading.

(BTW, I'd be curious to hear what you think might be the differences in use cases between ClojureC and mjolnir/clojure-metal.)

Re: ClojureC, a compiler for Clojure that targets C as a backend

#53

Post by timbaldridge » Sun, May 05, 2013, 5:28 AM UTC

rdmckenzie wrote: post #36

jared314 wrote: post #35

Earlier quoted context omitted.

Have you looked at mjolnir[0]? It was part of a presentation at Clojure West this year. I'm not sure if the video is out yet, but the slides are[1]. [0] https://github.com/halgari/mjolnir [1] https://github.com/strangeloop/clojurewest2013/tree/master/s...

bah just as I was finishing my register allocator... My Firefox history indicates that I have read the Mjolnir page before, but I don't recall why I didn't use it at the time. Taking another look :-P. Thanks for the link!

Author of Mjolnir here. There's some major updates going on in the "datomic" branch. If you're thinking of using Mjolnir in a project, you'll want to keep an eye on that branch over the next few months.

With Datomic, the inference engine is completely re-written in datalog. This allows for a massive code clean-up, and the code in that branch is much cleaner.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#54

Post by pjmlp » Sun, May 05, 2013, 5:28 AM UTC

mullr wrote: post #26

This is neat. What worries me about this and similar efforts (like https://github.com/takeoutweight/clojure-scheme ) is that clojure's standard library design assumes that the underlying runtime will be do some kind of polymorphic method inlining. For example: the sequence library is all defined in terms of ISeq, which basically requires a "first" and "rest" to be defined for the data structure in question. These are…

You can workaround it by making use of PGO (Profile Guided Optimization).

This requires you to execute the application with profiling turned on.

Then you compile the application a second time with the additional input of the profile results, this way the optimizer gets additional information that helps it to do decisions similar to a JIT.

It is all a matter of adding support for this.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#55

Post by pjmlp » Sun, May 05, 2013, 5:32 AM UTC

rdmckenzie wrote: post #20

rayiner wrote: post #18

Earlier quoted context omitted.

Generating C is quicker to write and easier to debug (can more easily read intermediate output) and doesn't require accessing a C++ api.

I can't stress the C++ api part of this enough. At the moment I'm building a Pascal compiler in Clojure for course work and when the time came to do byte code generation the first thing I looked to was the LLVM infrastructure both for ease of use and because it would trivially provide me with the ability to target non-x86 platforms. The reality of the matter is that interacting with non-java linked libraries is a rea…

Why not use the Java LLVM bindings? They are usually in sync with the LLVM release.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#56

Post by pjmlp » Sun, May 05, 2013, 5:33 AM UTC

saosebastiao wrote: post #37

So if I wanted to write CLI applications in Clojure, is this my best bet? Cause the JVM is about the least suitable platform I have ever worked with for CLI apps...which is most of what I do. I'm constantly in this pickle of wanting to use Clojure but defaulting to Ruby because the JVM is so terrible at it.

Get one of the many AOT compilers for Java. No more JVM startup time to worry about.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#57

Post by pjmlp » Sun, May 05, 2013, 5:35 AM UTC

jgalt212 wrote: post #34

As someone who doesn't use Clojure, but watches it fairly closely, I'd say the least appealing part of Clojure is its reliance on the JVM. As such, I'd say efforts such as these are greatly welcomed.

> As someone who doesn't use Clojure, but watches it fairly closely, I'd say the least appealing part of Clojure is its reliance on the JVM.

Like it or not, this is what made Clojure successful in the enterprise, at least when compared against other Lisps.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#58

Post by pjmlp » Sun, May 05, 2013, 5:37 AM UTC

This is quite nice, on the other hand, one could just use one of the many Lisp compilers existing since years.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#59

Post by abraininavat » Sun, May 05, 2013, 5:38 AM UTC

pat_punnu wrote: post #13

coldtea wrote: post #10

Earlier quoted context omitted.

Nonsense?! Outputting text to be interpreted as code is far more low level and error prone than targeting an AST via an API like LLVMs. And you loose a lot of high quality tooling that you could take advantage of.

"more ... error prone" Can you prove that? If not, it's just a baseless opinion.

Can you prove that? If not, it's just a baseless opinion.

You are wrong here. Unproved statements are not necessarily baseless opinions. They may be well supported opinions.

I think you meant to ask him, "Can you support that?"

Re: ClojureC, a compiler for Clojure that targets C as a backend

#60

Post by nimrody » Sun, May 05, 2013, 5:52 AM UTC

mullr wrote: post #26

This is neat. What worries me about this and similar efforts (like https://github.com/takeoutweight/clojure-scheme ) is that clojure's standard library design assumes that the underlying runtime will be do some kind of polymorphic method inlining. For example: the sequence library is all defined in terms of ISeq, which basically requires a "first" and "rest" to be defined for the data structure in question. These are…

Perhaps you could overcome some of these programs with whole-program-optimization. E.g., the "Stalin" Scheme compiler.

It might be interesting to translate Clojure into a subset of Scheme that is widely supported -- and use one of the mature Scheme -> C compilers (Gambit, Chicken, Bigloo) to generate the target executable.