Re: [racket-users] racket virtual machine
You might have a look at Whalesong. It is a racket-js compiler that, IMO, was headed in a good direction. It's not a small thing, however. Robby On Thu, Jun 4, 2015 at 11:37 PM, Neil Van Dyke n...@neilvandyke.org wrote: Thanks, Jens Axel, Raoul, and Robby. Different question... For support for writing polished Web browser (and PhoneGap) apps in Racket, any comments on which of the following two options is better (viable, easier to implement and maintain, better performance, etc.)? 1. Implement Racket VM in JS, along with implementing support libraries in JS, and interpret `.zo` files at runtime. 2. Forget about `eval`, require apps to be compilable on development host (but not necessarily runnable there), implement compiler from `.zo` to JS (managing TCO, etc.), implement small Racket runtime library in JS, implement browser facilities and/or GUI libraries in JS. Later think about `eval`.[*] [*] I've only done a very brief peek at sample `zo-parse` and `decompile` output, so I don't know how tricky it can get, but the little I saw looked like a static translation to JS wouldn't be too difficult. I don't know how necessary `eval` is if you have bytecode, nor how much of the primitives would have to be implemented manually rather than translated from `.zo`. Neil V. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket virtual machine
2015-06-05 6:37 GMT+02:00 Neil Van Dyke n...@neilvandyke.org: 2. Forget about `eval`, require apps to be compilable on development host (but not necessarily runnable there), implement compiler from `.zo` to JS (managing TCO, etc.), implement small Racket runtime library in JS, implement browser facilities and/or GUI libraries in JS. Later think about `eval`.[*] This approach seems to be what Whalesong does. I agree that `eval` is unimportant for most programs - and when a Racket version of the new macro expander is available it ought to be reasonably easy to implement `eval`. [*] I've only done a very brief peek at sample `zo-parse` and `decompile` output, so I don't know how tricky it can get, but the little I saw looked like a static translation to JS wouldn't be too difficult. I don't know how necessary `eval` is if you have bytecode, nor how much of the primitives would have to be implemented manually rather than translated from `.zo`. There are a few complications. It is hard to use the native JavaScript stack to represent the Racket stack. Some byte codes like with-cont-mark manipulate the stack in ways JavaScript doesn't support. Some primitives (call/cc and friends) are also problems unless an explicit representation of the Racket stack is used. Whalesong compiles zo-bytecode into JavaScript that manipulate an explicit data structure representing the Racket stack. The alternative approach is to compile fully expanded Racket into JavaScript. The trio of TCO, contination marks and continuations will most likely turn out to be the trickiest to get right. Even with an explicit control stack for Racket care is needed to avoid hitting the stack ceiling in JavaScript (why was `goto` left out in the cold?) Finally - a small runtime library is probably unrealistic. Racket has a huge number of primitives. Relevant paper on continuation marks and continuations from exceptions: http://cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-cont-from-gen-stack-insp/paper.pdf Note: The paper Implementing Continuation Marks in JavaScript shows how to add continuation marks to an existing JavaScript engine (Rhino), but unfortunately that won't help in a general context. Implementing Continuation Marks in JavaScript John Clemens, Ayswarya Sundaram, and, David Herman http://www.ccs.neu.edu/home/dherman/research/papers/scheme08-stack-marks.pdf -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket virtual machine
On Fri, Jun 5, 2015 at 11:40 AM, Jens Axel Søgaard jensa...@soegaard.net wrote: 2015-06-05 6:37 GMT+02:00 Neil Van Dyke n...@neilvandyke.org: 2. Forget about `eval`, require apps to be compilable on development host (but not necessarily runnable there), implement compiler from `.zo` to JS (managing TCO, etc.), implement small Racket runtime library in JS, implement browser facilities and/or GUI libraries in JS. Later think about `eval`.[*] This approach seems to be what Whalesong does. I agree that `eval` is unimportant for most programs - and when a Racket version of the new macro expander is available it ought to be reasonably easy to implement `eval`. [*] I've only done a very brief peek at sample `zo-parse` and `decompile` output, so I don't know how tricky it can get, but the little I saw looked like a static translation to JS wouldn't be too difficult. I don't know how necessary `eval` is if you have bytecode, nor how much of the primitives would have to be implemented manually rather than translated from `.zo`. There are a few complications. It is hard to use the native JavaScript stack to represent the Racket stack. Some byte codes like with-cont-mark manipulate the stack in ways JavaScript doesn't support. Some primitives (call/cc and friends) are also problems unless an explicit representation of the Racket stack is used. Whalesong compiles zo-bytecode into JavaScript that manipulate an explicit data structure representing the Racket stack. The alternative approach is to compile fully expanded Racket into JavaScript. The trio of TCO, contination marks and continuations will most likely turn out to be the trickiest to get right. Even with an explicit control stack for Racket care is needed to avoid hitting the stack ceiling in JavaScript (why was `goto` left out in the cold?) Finally - a small runtime library is probably unrealistic. Racket has a huge number of primitives. Relevant paper on continuation marks and continuations from exceptions: http://cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-cont-from-gen-stack-insp/paper.pdf Note: The paper Implementing Continuation Marks in JavaScript shows how to add continuation marks to an existing JavaScript engine (Rhino), but unfortunately that won't help in a general context. Implementing Continuation Marks in JavaScript John Clemens, Ayswarya Sundaram, and, David Herman http://www.ccs.neu.edu/home/dherman/research/papers/scheme08-stack-marks.pdf My thesis ( http://jeapostrophe.github.io/home/static/students/2012-ms-kgermane.pdf) shows how to combine CM and continuation management with a CPS-like transformation. I applied it only to a really simple language, but I think the technique can apply to bigger languages. If you don't mind opaque, heap-allocated continuations or trampolines, that might conquer the trifecta. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket virtual machine
I recall Whalesong, and was hoping something simpler would work. Robby Findler wrote on 06/05/2015 08:21 AM: You might have a look at Whalesong. It is a racket-js compiler that, IMO, was headed in a good direction. It's not a small thing, however. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket virtual machine
On Fri, Jun 5, 2015 at 12:37 AM, Neil Van Dyke n...@neilvandyke.org wrote: Thanks, Jens Axel, Raoul, and Robby. Different question... For support for writing polished Web browser (and PhoneGap) apps in Racket, any comments on which of the following two options is better (viable, easier to implement and maintain, better performance, etc.)? 1. Implement Racket VM in JS, along with implementing support libraries in JS, and interpret `.zo` files at runtime. This is, as I understand, roughly the approach that Whalesong takes. I think that this is unlikely to produce good performance without heroic effort, such as writing a JIT compiler for the bytecode to more efficient JS. Additionally, implementing the runtime library is a lot of work. 2. Forget about `eval`, require apps to be compilable on development host (but not necessarily runnable there), implement compiler from `.zo` to JS (managing TCO, etc.), implement small Racket runtime library in JS, implement browser facilities and/or GUI libraries in JS. Later think about `eval`.[*] This is roughly the approach that ClojureScript takes -- it's a somewhat different language than Closure, and compiles directly to JS. Figuring out how to handle tail calls, continuations, and arbitrary-depth recursion will be the hard part. To my knowledge, no one has tried this, but I think you could get it going with less effort than your option 1. However, you would not be able to cover the full Racket language without effectively writing a whole-program compiler to a low-level subset of JS. [*] I've only done a very brief peek at sample `zo-parse` and `decompile` output, so I don't know how tricky it can get, but the little I saw looked like a static translation to JS wouldn't be too difficult. I don't know how necessary `eval` is if you have bytecode, nor how much of the primitives would have to be implemented manually rather than translated from `.zo`. There are 1000 primitive functions, and implementing them is most of the work of implementing a Racket VM. Some of them you won't need, and some won't make sense in Web-facing JS (such as file access). As for `eval`, it's pretty rarely used in Racket programs, but `dynamic-require` is commonly used, and that's effectively `eval`. Sam -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket virtual machine
Ah, sorry. I think it would be a great thing if it were possible to have something simpler that did Whalesong's job. I feel like this is possible and something we're moving slowly towards as we chip away at moving parts of the runtime system up into Racket proper. Robby On Fri, Jun 5, 2015 at 9:53 AM, Neil Van Dyke n...@neilvandyke.org wrote: I recall Whalesong, and was hoping something simpler would work. Robby Findler wrote on 06/05/2015 08:21 AM: You might have a look at Whalesong. It is a racket-js compiler that, IMO, was headed in a good direction. It's not a small thing, however. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket virtual machine
Thanks, Jens Axel, Raoul, and Robby. Different question... For support for writing polished Web browser (and PhoneGap) apps in Racket, any comments on which of the following two options is better (viable, easier to implement and maintain, better performance, etc.)? 1. Implement Racket VM in JS, along with implementing support libraries in JS, and interpret `.zo` files at runtime. 2. Forget about `eval`, require apps to be compilable on development host (but not necessarily runnable there), implement compiler from `.zo` to JS (managing TCO, etc.), implement small Racket runtime library in JS, implement browser facilities and/or GUI libraries in JS. Later think about `eval`.[*] [*] I've only done a very brief peek at sample `zo-parse` and `decompile` output, so I don't know how tricky it can get, but the little I saw looked like a static translation to JS wouldn't be too difficult. I don't know how necessary `eval` is if you have bytecode, nor how much of the primitives would have to be implemented manually rather than translated from `.zo`. Neil V. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] racket virtual machine
How hard is it to implement the Racket virtual machine (no JIT) for a single target architecture one knows? Say, is this a one-weekend task, or a one-month task? Neil V. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket virtual machine
Depends. If you count all the primitives - then one-month won't be enough. The actual operations of the virtual machine are certainly doable in a reasonable amount of time. A Racket VM written in Racket: https://github.com/soegaard/meta/blob/master/runtime/racket-eval.rkt (submodules not supported yet, but it is a relatively small change). /Jens Axel 2015-06-04 0:59 GMT+02:00 Neil Van Dyke n...@neilvandyke.org: How hard is it to implement the Racket virtual machine (no JIT) for a single target architecture one knows? Say, is this a one-weekend task, or a one-month task? Neil V. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- Jens Axel Søgaard -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket virtual machine
Evil question: Has anybody ever looked at how the bytecode could be interpreted on another VM e.g. JVM? -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] racket virtual machine
Just because no one has mentioned it yet: there is a C implementation of the VM (and the primitives) so if you have a C compiler and an OS for that architecture, it shouldn't be too hard. Robby On Wed, Jun 3, 2015 at 5:59 PM, Neil Van Dyke n...@neilvandyke.org wrote: How hard is it to implement the Racket virtual machine (no JIT) for a single target architecture one knows? Say, is this a one-weekend task, or a one-month task? Neil V. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
