>>> 3) Unless you plan on staying strictly AOT, and igoring the REPL, then
>>> we're going to need a JIT, that's not exactly something you can hack
>>> together in an afternoon
>>
>> I don't follow.
>
> With a AOT compiler like this project, you don't have the ability to
> play at a repl. I guess i
>> 3) Unless you plan on staying strictly AOT, and igoring the REPL, then
>> we're going to need a JIT, that's not exactly something you can hack
>> together in an afternoon
>
> I don't follow.
With a AOT compiler like this project, you don't have the ability to
play at a repl. I guess if you don'
On Wed, Jul 11, 2012 at 3:05 PM, Timothy Baldridge wrote:
>>> I've been debating on working on a native Clojure
>
> I've also been debating this for over two years now,y but I keep
> coming back to the same problems over and over again:
>
> 1) A from-scratch native Clojure either needs to be just
> You don't really need a JIT for those things, smart compile time analysis
> can get as good or better results. See Stalin scheme:
>
> http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)
True if you don't want a repl or eval, then you need a JIT. Notice it
is also a "full program optimize
You don't really need a JIT for those things, smart compile time analysis
can get as good or better results. See Stalin scheme:
http://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)
On Wednesday, July 11, 2012 3:05:50 PM UTC+2, tbc++ wrote:
>
> >> I've been debating on working on a native
>> I've been debating on working on a native Clojure
I've also been debating this for over two years now,y but I keep
coming back to the same problems over and over again:
1) A from-scratch native Clojure either needs to be just a compiler
(as this project is), or you're going to need a decent GC
On Wed, Jul 11, 2012 at 11:57 AM, John Szakmeister wrote:
> Nice work! Are you looking to support multiple threads, STM, agents,
> etc.? I've been debating on working on a native Clojure
> implementation for a while, and that was one of my goals... I'm
> interested if it's one of yours.
Yes, it
On Mon, Jul 9, 2012 at 7:03 AM, Mark Probst wrote:
> Dear Clojurians,
>
> I'm excited to announce ClojureC, an effort to produce a Clojure
> implementation that targets C:
>
> https://github.com/schani/clojurec
>
> My personal goals with this are to be able to write self-contained
> (command-lin
Looks like a lot of people are excited about this.
For the specific purpose of cocoa apps, can someone explain how this
is better/different than the other approaches?
There are at least 3 other projects that promise some kind of
c/objective-c interop,
https://github.com/takeoutweight/clojure-sche
I would take a look at bigloo and gambit, those implementations produce
solid C code from a Scheme base.
On 07/09/2012 08:50 AM, Baishampayan Ghose wrote:
>> I'm excited to announce ClojureC, an effort to produce a Clojure
>> implementation that targets C:
>>
>> https://github.com/schani/clojure
Man- the day there's a mature, production-ready C(something) compiler, I'm
going to flip out. Can't wait.
Thank you for working on this!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
No
> I'm excited to announce ClojureC, an effort to produce a Clojure
> implementation that targets C:
>
> https://github.com/schani/clojurec
>
> My personal goals with this are to be able to write self-contained
> (command-line) Clojure programs that have (essentially) zero start-up time,
> as well
Dear Clojurians,
I'm excited to announce ClojureC, an effort to produce a Clojure
implementation that targets C:
https://github.com/schani/clojurec
My personal goals with this are to be able to write self-contained
(command-line) Clojure programs that have (essentially) zero start-up time,
13 matches
Mail list logo
