Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

11–20 of 89 posts

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

#11

Post by bratsche »

pat_punnu wrote: post #9
bratsche wrote: post #8

Earlier quoted context omitted.

I'm not sure if this is what the previous poster was talking about, but clang has some APIs that let you get access to the AST pretty easily. It's been a really long time since I've looked at it, and at the time I don't think it was exposed as a library API for general consumption. But for example: https://github.com/bratsche/clang/blob/gtkrewriter/tools/cla...

What is his definition of better? It sounds like he thinks it's entirely objective, so he should be able to express it clearly and logically. Does he think that it's technically more powerful? Again he should be able to prove that if that's the case. Otherwise he's just giving a shitty opinion, and should say that. I think the claim is nonsense because with inline assembler there is nothing that you cannot express in…

I don't know what his definition of anything is. I happen to agree with you. The example I pasted above was just from my only experience working with a C AST. In that case I wanted to input C code and then write out a transformed version of it.

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

#12

Post by akkartik »

"Before you can run anything make sure you have GLib 2 and the Boehm-Demers-Weiser garbage collector installed."

Wow, that's a pretty skimpy list of dependencies. But..

"Make sure you're using Leiningen 2."

..argh, installing that on ubuntu that requires 110 packages. All that just for a build system?

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

#13

Post by pat_punnu »

coldtea wrote: post #10
pat_punnu wrote: post #6

Earlier quoted context omitted.

Can you show a proof for that claim? I believe it to be nonsense.

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.

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

#15

Post by coldtea »

pat_punnu wrote: post #9
bratsche wrote: post #8

Earlier quoted context omitted.

I'm not sure if this is what the previous poster was talking about, but clang has some APIs that let you get access to the AST pretty easily. It's been a really long time since I've looked at it, and at the time I don't think it was exposed as a library API for general consumption. But for example: https://github.com/bratsche/clang/blob/gtkrewriter/tools/cla...

What is his definition of better? It sounds like he thinks it's entirely objective, so he should be able to express it clearly and logically. Does he think that it's technically more powerful? Again he should be able to prove that if that's the case. Otherwise he's just giving a shitty opinion, and should say that. I think the claim is nonsense because with inline assembler there is nothing that you cannot express in…

>Does he think that it's technically more powerful? Again he should be able to prove that if that's the case. Otherwise he's just giving a shitty opinion, and should say that.

It's not like it's some controversial opinion what he said -- it's both self evident and common place. It's you who offers the more controversial opinion (and in a rude way, to top).

>I think the claim is nonsense because with inline assembler there is nothing that you cannot express in C that you can with LLVM. So the decision between the two is opinion.

It's not about "expression", and nobody argued that you can express more in LLVM.

This is missing the point by miles!

It's about having more structure and less of an ad-hoc pipeline, which helps with better tooling, error prevention, etc.

(Not only what you wrote is wrong, but even if the original argument was about expression, your opinion would still be wrong. Two things offering equivalent expressive power, does not mean that they are just as good to use in practice at all. Might as well ask "why invent new languages, when assembly can express everything").

The only benefit to using C for something like this is portability, which is something else altogether.

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

#16

Post by zhemao »

akkartik wrote: post #12

"Before you can run anything make sure you have GLib 2 and the Boehm-Demers-Weiser garbage collector installed." Wow, that's a pretty skimpy list of dependencies. But.. "Make sure you're using Leiningen 2." ..argh, installing that on ubuntu that requires 110 packages. All that just for a build system?

Wait, are you trying to install it as an APT package? It's probably easier to just download the script and install it that way. If you do that, it will install all the libraries to a folder in your home directory.

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

#17

Post by coldtea »

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.

What's with this childish "can you prove this, can you prove that" thing? Are you 12 year old?

Not everything can (or should) be proved of the drop of a hat in a discussion list -- that doesn't make everything without a formal proof "baseless" opinion.

If you cannot see the self-evidentness (sic) of a STRUCTURED API to produce an AST makes it easier to avoid mistakes compared to spitting out text to compile as a C program, then I'm not sure any proof would help anyway.

It's like asking me to prove why using an XML processor to crete and save a DOM tree would produce more error free results than manually compiling tags as strings.

Or why parsing a JSON file and working on the nodes is less error prone than using regular expressions to extract values from the JSON as a big string.

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

#19

Post by Tuna-Fish »

akkartik wrote: post #12

"Before you can run anything make sure you have GLib 2 and the Boehm-Demers-Weiser garbage collector installed." Wow, that's a pretty skimpy list of dependencies. But.. "Make sure you're using Leiningen 2." ..argh, installing that on ubuntu that requires 110 packages. All that just for a build system?

It's easier to get Lein as standalone. The Ubuntu package depends on half the build infrastructure of java, using really minimal parts of it here and there. If you just get the shell script and stuff it in your path, it can self-install a 10MB jar that has all it needs.

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

#20

Post by rdmckenzie »

rayiner wrote: post #18
densh wrote: post #5

Why C but not llvm? Structured code generation is always better than string-based one.

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 real pain from every JVM language know of. Two years ago this was posted here [https://github.com/jasonjckn/llvm-clojure-bindings], but since then LLVM has gone through two major restructurings so it didn't work out of the box and I estimated that it would take less effort to build my own naive infrastructure than to patch this one & integrate it.

As a result I'm generating code in terms of lists of newline terminated assembly statement strings that I can just print or write to a file when I'm done. While I agree that C is a sub-optimal output format in that you have to compile the output, it is also the clear lingua franca for systems programming and assembly generation these days. Generating C gives you interesting options like linking to other C codebases or your own C code the same way that cljs gives you the option of interacting with "native" javascript libraries as well as clojurescript toolkits.

Post reply on HN