Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Graal and Truffle could accelerate programming language design

medium.com

Post reply on HN
Print view View original

151–160 of 204 posts

Re: Graal and Truffle could accelerate programming language design

#151

Post by Veedrac »

qwertyuiop924 wrote: post #100

Okay, very cute, but what if you want your language to have significant semantic differences from C and the like? What if you want to write a Scheme interpreter, for instance? Can I have Continuations? Can I have Tail Call Optimization? I very much doubt it. If you want to write a language that is semantically like C for the most part, than go ahead and use Truffle, but that's not where interesting language design is…

You can do TCO relatively simply. You throw a special exception class for nonlocal control flow (eg. tail calls, breaks from loops, continues, etc.) and Graal knows how to optimize the cost away to a normal jump.

http://cesquivias.github.io/blog/2015/01/15/writing-a-langua...

ZipPy (an incomplete Python implementation) supports Python's coroutines, which are faster than any other implementation. In theory these might be directly generalizable to get continuations.

http://thezhangwei.com/documents/oopsla113-zhang.pdf

Re: Graal and Truffle could accelerate programming language design

#152

Post by hencq »

kovrik wrote: post #144
hencq wrote: post #133

Earlier quoted context omitted.

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.

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 convent…

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.

Re: Graal and Truffle could accelerate programming language design

#153

Post by nostrademons »

tomphoolery wrote: post #139
Cacti wrote: post #49

Earlier quoted context omitted.

We should be clear here by what we mean by language. It's perfectly possible and manageable to create cross-language VMs and to translate pretty accurately between languages. However, what breaks down, as you alluded to, is that people expect the standard libraries, and the libraries of others, to work interchangeably, and that is orders of magnitudes more complex (mostly because you are, by definition, working close…

> Do we have a grasp on what it would take to treat the stdlib as a "first class" citizen? One of the solutions to this problem could be having package management in your language be a first-class citizen, then treating each part of the stdlib as a separate package. If using stdlib code is just as simple as using 3rd-party libraries, then why need a stdlib at all?

It's because languages are communication tools as well as compilers, and the stdlib is part of the common vocabulary that the rest of the language ecosystem shares.

Without a decent stdlib, you end up with the pre-STL C++ situation, where every library & framework declares its own string, vector, and hashmap classes and you need slow, verbose, and error-prone routines to convert between them. The main benefit of having these in the stdlib isn't that you don't have to re-implement them, it's that every third-party lib knows exactly which class represents the concepts of text, sequences, and dictionaries.

The same goes for many other types, eg. Promises, Paths, URIs, Dates, Input/OutputStreams, Iterators, etc. Indeed, when one of the stdlib types is misdesigned (eg. java.util.Date), you get an utter mess as the community converges on an alternative (eg. JodaTime) and then the alternative API is folded back into the stdlib (Java 8).

Luckily, we're learning just which types need to be in the stdlib and which can be outsourced to a third-party package manager. In particular, a lot of serialization/parsing formats are better off in a package manager, as long as the language defines an annotation system that can be used to define which fields must be saved. And giant systems like webservers, webframeworks, or RPC formats are often better off as a third-party library.

Re: Graal and Truffle could accelerate programming language design

#154

Post by nirvdrum »

vvanders wrote: post #123
grashalm wrote: post #122

Earlier quoted context omitted.

There was a patch for coroutines on the JVM some time ago. Unfortunatly it did not make it into the platform. No reason why it could not be added to the JVM. SubstrateVM solves the embeddability part.

Info out there on SubstrateVM looks a little sparse. For context we use to run VM + tuneable data + game logic code in a 400kb block allocated to Lua on the PSP. I'd love to hear how SubstrateVM compares. Lua has a really rich history of being embedding in some pretty small targets.

400 KB is a very aggressive target. I don't think anything in SubstrateVM would absolutely prohibit that, but currently our images are larger.

Some of this is just simply a design trade-off. E.g., in JRuby+Truffle, we've implemented much of the core library in Ruby. This has allowed us to achieve a high level of language compatibility in a fairly short period of time -- implementing 3,000 core library methods in Java would be quite the undertaking. As a consequence, the static binary must include those full Ruby sources (compressed, but they're not in an optimized bytecode format).

Having said that, if we wanted to optimize for size over a restricted subset of the language (think mruby), that would be straightforward to do.

Re: Graal and Truffle could accelerate programming language design

#155

Post by qwertyuiop924 »

pnathan wrote: post #149
qwertyuiop924 wrote: post #119

Earlier quoted context omitted.

Why compile to lisp in the first place? Build a nanopass framework ( https://www.google.com/url?sa=t&source=web&rct=j&url=http://... ) that acts on sexprs, and then emit the thing to a target of your choice. The advantage is that Lisp is really good at transforming sexprs, and macros make writing the infrastructure for that sort of compiler just that much easier.

SBCL can compile lisp to native code. :-)

Well, yeah, but as you said, you have to haul the runtime around with you.

Re: Graal and Truffle could accelerate programming language design

#156

Post by qwertyuiop924 »

hencq wrote: post #152
kovrik wrote: post #144

Earlier quoted context omitted.

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 convent…

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 artic…

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.

Re: Graal and Truffle could accelerate programming language design

#157

Post by qwertyuiop924 »

Veedrac wrote: post #151
qwertyuiop924 wrote: post #100

Okay, very cute, but what if you want your language to have significant semantic differences from C and the like? What if you want to write a Scheme interpreter, for instance? Can I have Continuations? Can I have Tail Call Optimization? I very much doubt it. If you want to write a language that is semantically like C for the most part, than go ahead and use Truffle, but that's not where interesting language design is…

You can do TCO relatively simply. You throw a special exception class for nonlocal control flow (eg. tail calls, breaks from loops, continues, etc.) and Graal knows how to optimize the cost away to a normal jump. http://cesquivias.github.io/blog/2015/01/15/writing-a-langua... ZipPy (an incomplete Python implementation) supports Python's coroutines, which are faster than any other implementation. In theory these might…

The TCO sounds like an ugly hack to me, but I'll take it. How would this interact with the magical AST merging? I would assume that languages with different calling conventions can't just merge like that.

Re: Graal and Truffle could accelerate programming language design

#158

Post by [deleted] »

qwertyuiop924 wrote: post #105
wcrichton wrote: post #59

Before anyone gets too excited, make sure you look at what a compiler using Truffle actually looks like, and remember that Java is far from an ideal language for writing a compiler. I'll use their SimpleLanguage (their primary tutorial lang) as an example. Parser [1] shows how lack of sum types makes code messy. Lots of "factory.createStringLiteral" kind of calls. At least Java has a mature parser generator. Implemen…

Urrgh. This just reminds me of why I gave up on android app development, and the JVM ecosystem as a whole: it tests my ability to put up with bullshit.

[deleted]

Re: Graal and Truffle could accelerate programming language design

#159

Post by [deleted] »

dkarapetyan wrote: post #48

Doesn't RPython do all the same things? Also there are language workbenches ( http://www.languageworkbenches.net/ ) that allow one to get a bunch of things like IDE support and even basic compilers by properly expressing the language syntax and semantics. I agree there is a lot of interesting stuff going on here but lets not forget the prior art. Even OMeta I think already did a lot of these things way back when. Goi…

[deleted]

Re: Graal and Truffle could accelerate programming language design

#160

Post by Veedrac »

dkarapetyan wrote: post #48

Doesn't RPython do all the same things? Also there are language workbenches ( http://www.languageworkbenches.net/ ) that allow one to get a bunch of things like IDE support and even basic compilers by properly expressing the language syntax and semantics. I agree there is a lot of interesting stuff going on here but lets not forget the prior art. Even OMeta I think already did a lot of these things way back when. Goi…

RPython is very similar to Graal+Truffle, except that RPython is based on tracing and Graal+Truffle is based on partial evaluation.

There's a nice paper comparing the two approaches and their relative merits:

http://stefan-marr.de/papers/oopsla-marr-ducasse-meta-tracin...

Post reply on HN