4 ms·

Don't know why you get downvoted. That's exactly what I thought. Java is my main lang and currently I'm working on my hobby project - implementing Scheme r5rs

by kovrik 10y ago

Don't know why you get downvoted. That's exactly what I thought. Java is my main lang and currently I'm working on my hobby project - implementing Scheme r5rs in Java. That is hard! And I doubt I'll be able to implement full r5rs even close. I have no idea (yet) how to implement Continuations: In theory yes, you can implement Continuations in any lang which has Exceptions (the only way in Java to unwind a stack). Like: https://www.politesi.polimi.it/bitstream/10589/108685/3/2015_07_Bernardini.pdf https://www.politesi.polimi.it/bitstream/10589/108685/3/2015... Proper TCO: AFAIK it is impossible in general case in object-oriented lang. That is one of the reasons why Rich Hickey decided to have explicit recur in Clojure, Yeah, you can implement your own stack and stop using Java's stack, but then you lose performance and interop: "Interop, speed, TCO -- Pick two." Rich Hickey See https://news.ycombinator.com/item?id=4922848 https://news.ycombinator.com/item?id=4922848 Then Full Numeric Tower is hard! Mostly due to the fact that Java's type system is not strong enough. I think Kawa is the best implementation of Scheme for JVM you can get now. But even Kawa has some limitations (due to JVM limits): https://www.gnu.org/software/kawa/Compatibility.html https://www.gnu.org/software/kawa/Compatibility.html

hencq 10y ago
You're not compiling to Java though. You're writing an AST walking interpreter, so you should be able to implement continuations and TCO just fine.
- kovrik 10y ago
  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)?
  - hencq 10y ago
    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.
    - qwertyuiop924 10y ago
      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.
      - qwertyuiop924 10y ago
        Wait, nevermind. See above.

by kovrik 10y ago

hencq 10y ago

You're not compiling to Java though. You're writing an AST walking interpreter, so you should be able to implement continuations and TCO just fine.

kovrik 10y ago
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)?
- hencq 10y ago
  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.
  - qwertyuiop924 10y ago
    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.
    - qwertyuiop924 10y ago
      Wait, nevermind. See above.