[racket] Racket in a browser?

2011/4/10 Eli Barzilay <eli at barzilay.org>:
> 25 minutes ago, Jens Axel Søgaard wrote:
>> 2011/4/10 Shriram Krishnamurthi <sk at cs.brown.edu>:

>> >> One advantage with the LLVM solution is that one is sure that the
>> >> semantics of the parts of Racket that are implemented in C will
>> >> be preserved. I am thinking such things as the numerical tower,
>> >> whose C implementation contains quite a few functions that are
>> >> non-trivial to implement directly in JavaScript.
>> >
>> > I don't know what the porting effort is to get Racket to LLVM.
>>
>> I hope that's not neccessary. Here is what I had in mind: GCC has an
>> LLVM backend.
>
> (Last time I checked it was the other way around: LLVM had a GCC
> front-end.)

You are right.

>> So compile Racket (with a disabled JIT) to racket.llvm with GCC, and
>> then compile it with Emscripten.
>
> ... and this doesn't help with the runtime support that you need.

> Here's a concrete example: that code will also have a GC in it, and
> you'll end up running an emulated piece of code in JS to do the GC,
> spending a good number of layers on work that JS already does.

As I see it, I am getting the runtime without any effort at all :-)
On the other hand it will be slow (but there are no free lunch).

> In any case, there's nothing really special about LLVM in this context
> other than the fact that someone wrote such a compiler.  It doesn't
> change much how "direct" things are, because it's at a low enough
> level that there's not much difference.

Just to make sure: I never meant to argue that an Emscripten Racket
would be practical solution. It was more along the line of: Hey, here
is a fun project idea. And my quick estimate of the effort needed
was that it shouldn't take that long to get a demo running. Thus
it is no catastrophe if it turns out to be too slow to use. That is
I do not see it as a replacement of the current compiler.

--
Jens Axel Søgaard