ClojureC, a compiler for Clojure that targets C as a backend
1–10 of 89 posts
Re: ClojureC, a compiler for Clojure that targets C as a backend
#2sadly, 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.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#3sadly, 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.
Lack of multithreading seems like a result of the implementation being heavily based on ClojureScript ;) (it's actually pretty cool to see how reusable core.cljs is IMO). I imagine ClojureC will have its uses like ClojureScript does when the JVM is not an option.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#4sadly, 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.
It is quite interesting though as soon as you extend it with calls to C libraries. Like if you want to use Clojure for libavcodec, or many others.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#5Why C but not llvm? Structured code generation is always better than string-based one.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#6Why C but not llvm? Structured code generation is always better than string-based one.
Can you show a proof for that claim?
I believe it to be nonsense.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#7Why C but not llvm? Structured code generation is always better than string-based one.
If you generate C, you can get a C AST from the result easily, which is a structured format...
Re: ClojureC, a compiler for Clojure that targets C as a backend
#8Why C but not llvm? Structured code generation is always better than string-based one.
Can you show a proof for that claim? I believe it to be nonsense.
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...
Re: ClojureC, a compiler for Clojure that targets C as a backend
#9Earlier quoted context omitted.
Can you show a proof for that claim? I believe it to be nonsense.
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 C that you can with LLVM. So the decision between the two is opinion.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#10Why C but not llvm? Structured code generation is always better than string-based one.
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.