> 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. > 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. 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. Maybe there's a way of doing something complementary, using this to obtain the missing primitives? Shriram _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
