Earlier quoted context omitted.
When you spend a few years speculating about what it would take to efficiently compile Ruby as statically as possible (I love Ruby, but I hate moving parts), devious becomes second nature... The idea of speculatively looking at method names comes from testing that to create vtables ahead of time for Ruby classes, to avoid hash tables in the common-case. As it turns out, most method on most Ruby classes are the ones i…
Out of interest, are you actually working on something like this for MRI? As you say, Ruby is in desperate need of optimization.
ClojureC, a compiler for Clojure that targets C as a backend
71–80 of 89 posts
Re: ClojureC, a compiler for Clojure that targets C as a backend
#72Earlier quoted context omitted.
Out of interest, are you actually working on something like this for MRI? As you say, Ruby is in desperate need of optimization.
Just use Crystal instead, https://github.com/manastech/crystal
That said: It looks like a really interesting project. I do wish they would phrase the project description as a "Ruby VM" instead of a separate programming language, through. There should not be any need to fork the entire language just to provide better performance.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#73This 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…
Re: ClojureC, a compiler for Clojure that targets C as a backend
#74Earlier quoted context omitted.
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 pr…
We work in a technical field. We call ourselves engineers. The academic version is computer SCIENCE. Unsupportable opinions and opinions presented as facts are inexcusable.
I don't see any proof fot that. Where's your proof?
Re: ClojureC, a compiler for Clojure that targets C as a backend
#75Earlier quoted context omitted.
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 pr…
Not everything can (or should) be proved of the drop of a hat in a discussion list If you say something that doesn't make sense, you're saying that one shouldn't have to back that up? 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. It is in fact the equivalent of asking you to prove that an XML parser a…
Read what you quoted from me, and what you ask. Where do I say that people should not back up things they say that "don't make sense"?
Where do I even say they do not have to "back up" the things they say? I merely say that they do not have to PROVE everything. You can back stuff up with some arguments and counterargurments, you don't need to provide some "proof".
>I think the reason pat_punnu is balking at what you have said is because of this: You can think of C as a serialized form of an AST. In order for parsing to produce a non-equivalent AST to the one used to serialize it, the C grammar must be non-deterministic. The C grammar is not non-deterministic, therefore what you said does not make sense and pat_punnu (somewhat rudely) asked you to back up what you were saying.
And the reason I'm balking at this is that you examine the case AFTER C has been generated. I'm not talking about that stage (when reading back C to generate an AST). I (and pat_punnu) and talking at the previous stage of spitting out the C code to disk in the first place. I'm saying that a structured way to do that (LLVM API) is safer than merely creating strings yourself.
So your: "It is in fact the equivalent of asking you to prove that an XML parser after serializing a DOM tree and then parsing that same document produces a non-equivalent DOM tree to the original"
takes this from several steps ahead. I (and pat_punny) were concerned with the generation of the document in the first place.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#76Earlier quoted context omitted.
> 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 assemble…
> It's not like it's some controversial opinion what he said -- it's both self evident and common place. As someone who has written more than one compiler, I don't see how it is self-evident at all. It's also not at all that common-place compared to generating C or asm output textually. > It's about having more structure and less of an ad-hoc pipeline, which helps with better tooling, error prevention, etc. Those pro…
So portability and less dependencies, plus easier.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#77Earlier quoted context omitted.
More moving parts being more error prone is not generally a controversial opinion.
This argument can just as easily be used to support a claim that generating C via string manipulation can very well be less error prone than relying on a huge, complex API like LLVM. It is not a given that there are "more moving parts" in generating C output from a compiler than in using LLVM.
No, but it's a given that the LLVM moving parts have been already written, and are tested by millions.
Your moving parts in your own solution, you'd have to write yourself.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#78So 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.
I suppose if you're coming from a C-based runtime like Ruby or Python, you have to adapt your workflow. I imagine that a lot of Clojure people come from Java and have already shaped their workflow around the JVM.
Re: ClojureC, a compiler for Clojure that targets C as a backend
#79Earlier quoted context omitted.
Just use Crystal instead, https://github.com/manastech/crystal
To tell me to "just use" it seems a bit glib considering that it's apparently nowhere being ready for production (the current code even has failng tests), let alone available as a swap-in replacement for Ruby. That said: It looks like a really interesting project. I do wish they would phrase the project description as a "Ruby VM" instead of a separate programming language, through. There should not be any need to for…
I just wanted to raise your attention to it, but you are right, it would be better to have a proper Ruby compiler available instead.