Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can you please elaborate? Because I don't see how it is different.

Are you still using Java stack, Java calling convention, still able to do Java interop?

When you are writing your own language on top of Java (Scheme, for example), you have full control of your lang AST (S-expressions, for example). How does it help to implement TCO and continuations (assuming you don't want to lose Java interop, Java calling convention, Java stack and performance)?



I'm definitely not an expert on this, but how the article describes it is you basically implement an AST with "execute" methods on its nodes. So that's just an interpreter that happens to use the Truffle framework to implement that AST. You can then implement continuations or TCO however you see fit. As I understand it, Graal is able to 'magically' turn that into a JIT. Again, I'm not an expert (I just read the article), but that seems very similar to how PyPy does it. The actual optimizations are different; PyPy uses tracing, while Graal uses Hotspot I think.

Now, as you point out, you lose Java interop that way. However, you can imagine using Truffle + Graal to also build a similar interpreter for Java. For interop, your interpreter 'simply' has to merge in the AST for the Java interpreter (with its own 'execute' methods). As I understand it the RubyTruffle project uses a similar trick to do C interop.


But if the calling and stack semantics are different from Java's (and the kind of have to be), than you can't just merge the ASTs. Ruby, provided you don't implement callcc, is almost, if not entirely identical in calling convention to C. So if truffle supports magical AST merging, as described, I don't think you can implement anything with a different set of conventions to C/Java.


Wait, nevermind. See above.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: