[racket] Racket in a browser?

2011/4/10 Shriram Krishnamurthi <sk at cs.brown.edu>:
>> Does the current bytecode to JavaScript compiler cover the whole language?
>
> No, we definitely have the "library problem".
>
>> A direct Racket bytecode to JavaScript compiler ought to be
>> faster/smaller/better etc.
>
> I don't understand this.  "direct" = ?  How would it be more "direct"
> than the current one?  You're making a comparative with at least two
> undefined parts.

I am talking about the current one (which I see as a direct compiler, since
there is no LLVM layer). It wil will be both faster and smaller.

>> 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. So compile Racket (with a disabled JIT) to
racket.llvm with GCC, and then compile it with Emscripten.

If I understand the Readme for the Python demo correctly,
then the author of Emscripten did nothing else than change
the build process in order to produce python.ll.

Here is the Readme:
http://code.google.com/p/emscripten/source/browse/#hg%2Ftests%2Fpython

> Would that affect things like tail-calls and continuations?  These are the
> things that Danny has put a lot of effort into in the Racket
> bytecode->JavaScript compiler.

Hard to answer without actually doing the experiement. I suppose it
depends on how well the LLVM is translated to JavaScript.

> Maybe there's a way of doing something complementary, using this to
> obtain the missing primitives?

That might be possible too.

--
Jens Axel Søgaard