2011/4/10 Shriram Krishnamurthi <s...@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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
