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

91–100 of 204 posts

Re: Graal and Truffle could accelerate programming language design

#91

Post by wcrichton »

lisper wrote: post #77
wcrichton wrote: post #69

Earlier quoted context omitted.

For sure, I was just considering normal macros.

No, you were just flat-out wrong. > Lisp can only metaprogram its own syntax, you can't introduce a C-like syntax. This is a flat-out false statement, and it reflects a deep but sadly common misunderstanding of how Lisp works and why it's cool. Even if Lisp did not have reader macros as a standard feature, you could still write a C compiler in Lisp more easily than you could write one in any other language. The whole…

Yes I agree with you, I am not trying to say it is impossible to write a C interpreter/compiler in Lisp. Any Turing-complete language can do that. I'm more so interested in the built-in metaprogramming capabilities, and it's evident that reader macros go far in that direction.

On a different note, would you say that Lisp's syntax is better because it makes an easy compile target (i.e. it's easier to compile C into Lisp instead of x86) or because it makes writing macros/AST transformations easier? I ask because my biggest beef with Lisp has always been that I thought its S-expressions to be less readable than other languages, but if you're arguing for Lisp's value as a compile target, then that makes a lot of sense.

Re: Graal and Truffle could accelerate programming language design

#92

Post by chrisseaton »

wahern wrote: post #76

Judging by LuaTruffle, the Lua example, then this framework is useless. LuaTruffle appears to implement the syntax of Lua but none of the semantics. For example, no metatables and no coroutines. Lua is unparalleled in its support of coroutines, and metatables are what make optimizing Lua _difficult_. Without implementing either of those things you've neither demonstrated the ability of the framework to implement nove…

LuaTruffle has a few hours work by an casual non-expert external person.

If you want to know about how well we can implement the semantics of an existing language then look at JRuby+Truffle - it passes more Ruby language tests than any other alternative Ruby implementation. The only stumbling block is co-routines as the JVM doesn't have these and they're hard to implement efficiently with other constructs.

Re: Graal and Truffle could accelerate programming language design

#93

Post by wcrichton »

alehander42 wrote: post #89
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…

Well can't we just use another language for JVM (e.g. Kotlin or Scala)

Hopefully! I would love to see a Truffle language written in Scala, although some of the DSL stuff I've seen in Scala (e.g. Delite) is still pretty verbose. I feel like the missing piece is quasiquotations--writing the code generation step would be a lot easier with those.

Re: Graal and Truffle could accelerate programming language design

#94

Post by chriswarbo »

wcrichton wrote: post #44
chrisseaton wrote: post #28

Earlier quoted context omitted.

Do you mean macros? Could you re-implement a language such as C as a macro? And have it be about as fast as GCC? I didn't think they were that sophisticated.

You cannot. Because Lisp is homoiconic, you don't code in (what I personally believe to be) reasonable syntax, you code in abstract syntax trees. Lisp is so easy to metaprogram because everything is parentheses and the burden is on the user, not the parser, to determine the program's abstract syntactic structure. So, Lisp can only metaprogram its own syntax, you can't introduce a C-like syntax.

If you want to handle a C-like language, you just need to make a parser; once you've got an AST, that is your "Lisp syntax", so you can do all of your fancy metaprogramming, interpretation, compilation, etc.

Using a parsing framework (e.g. parser combinators, parser generators, ometa, etc.) to parse a language which has a well-specified syntax (e.g. a BNF grammar) is pretty routine and mechanical; usually it just requires a one-to-one translation of the BNF form into the parser framework's syntax, then fiddling with ordering and precedence rules until your tests pass.

Starting from scratch, I could knock out a C-like parser in maybe half an hour, e.g. using parsec or ometa. I'm sure Lisps have equivalents (I know Racket has built in support for defining new concrete synax)

Re: Graal and Truffle could accelerate programming language design

#95

Post by chrisseaton »

ilostmykeys wrote: post #72

Funny, I posted this yesterday and got no up votes. Can you post a duplicate of some post and get up voted? I didn't realize that was possible.

Take a look at the Medium URLs and you'll see they have a fragment ID and so count as different submissions.

Re: Graal and Truffle could accelerate programming language design

#96

Post by lisper »

wcrichton wrote: post #91
lisper wrote: post #77

Earlier quoted context omitted.

No, you were just flat-out wrong. > Lisp can only metaprogram its own syntax, you can't introduce a C-like syntax. This is a flat-out false statement, and it reflects a deep but sadly common misunderstanding of how Lisp works and why it's cool. Even if Lisp did not have reader macros as a standard feature, you could still write a C compiler in Lisp more easily than you could write one in any other language. The whole…

Yes I agree with you, I am not trying to say it is impossible to write a C interpreter/compiler in Lisp. Any Turing-complete language can do that. I'm more so interested in the built-in metaprogramming capabilities, and it's evident that reader macros go far in that direction. On a different note, would you say that Lisp's syntax is better because it makes an easy compile target (i.e. it's easier to compile C into Li…

> Lisp's syntax is better because it makes an easy compile target

Not quite. Lisp's syntax is (mostly) irrelevant. Lisp's design is better because you don't have to worry about syntax to use Lisp as a compile target.

There's a huge conceptual difference between

    (eval '(some code))
and (using Javascript or Python as an example)

    eval("Some code")
In JS/Python case you are passing a string to EVAL. In the Lisp case you are passing a data structure to EVAL. That data structure has been generated by the reader (by virtue of using QUOTE) but that is not the important part. You could as easily have written:

    (eval (cons (quote some) (cons (quote code) nil)))
or

    (eval (some-function-that-generates-code))
with the point being that some-function-that-generates-code does not return a string, it returns a data structure, so there is no syntax. The whole concept has evaporated because you're not dealing with strings any more. Syntax is for humans. When you have programs writing programs, syntax just gets in the way. But when your EVAL function takes a textual representation of a program as a string you have no choice but to muck with syntax. This is the reason that the misconception that syntax is essential is so widespread. It seems essential only because most programming languages don't distinguish between READ and EVAL.

Re: Graal and Truffle could accelerate programming language design

#97

Post by thomaswue »

nostrademons wrote: post #90
thomaswue wrote: post #86

Earlier quoted context omitted.

It works without common memory layout between Truffle languages. It even simplifies the ability to use diverse physical memory layouts within the same language. The programmer specifies the logical layout based on the semantics of a language. The runtime decides how to map this logical layout onto the physical hardware. It can take into account the trade-offs the programmer decided to choose.

Right, and my point is that the reason people continue to use C++ or Rust over JVM languages is because there are some use-cases where the JVM's decision about how to map the logical layout onto physical memory causes unacceptably high memory usage and/or cache misses, or prevents them from taking advantage of clever serialization formats (Cap'n Proto, for example, loses much of its performance benefits on the JVM wi…

The default when running static languages like C++ or Rust or Go via Sulong is to stick to the memory layout chosen by the programmer. There is no conversion to typical JVM memory layouts. Nor does running on the JVM has major restrictions for the framework (we are working on a version that does not run on the JVM in the SubstrateVM project). What Graal+Truffle allows is for library writers and language designers to invent new representations without any restrictions on the layout and have them interact with the rest of the system. We want programmers to use the best language for the task. And even combine multiple languages within one program. Foreign objects can be passed around freely as parameters and local variables, but there are restrictions when building combined data structures - e.g., if you have a highly optimized native data structure, it is not possible to install a pointer to a JavaScript object in it without performance loss.

Re: Graal and Truffle could accelerate programming language design

#98

Post by qwertyuiop924 »

nostrademons wrote: post #17

There's actually a fairly long history of cross-language VMs, with various degrees of success. What usually happens is that they work fine for languages that look, semantically, basically like the native language on the VM. So LLVM works well as long as your language is mostly like C (C, C++, Objective-C, Rust, Swift). Parrot works if you language is mostly like Perl 6 (Perl, Python, PHP, Ruby). .NET works if your la…

Indeed. What if you're writing a Scheme interpreter? You're screwed.

Re: Graal and Truffle could accelerate programming language design

#99

Post by kbenson »

zzzcpan wrote: post #84
kbenson wrote: post #41

Earlier quoted context omitted.

> It's a great tool if you work in the JVM ecosystem and want to play around as a language designer. Except that it's not really exposing much of the JVM from what the article mentions, it just uses the JVM as a base. That is, Truffle languages can talk to other truffle languages, but I'm not sure how easy it is for a truffle language to talk to a JVM language. From everything I read, it seems like people thought Par…

I liked Parrot, but it didn't move in the right direction. No useful AOT and JIT from the start kind of turned me down.

Well, those were always planned features, they just never got around to them, or they never got enough attention before the project basically died out.

As for not moving in the right direction, it was probably far too ambitious to try to develop something like Parrot and something like Perl 6 at the same time, with dependencies on each other. Both projects would have been better served if they did their own things, and Parrot was just seen as "a good candidate for a second implementation" from the Perl 6 perspective, rather than the primary target. It's hard to target a VM that's not done, and it's hard as a VM to support a language that isn't finalized (and has crazy requirements).

Re: Graal and Truffle could accelerate programming language design

#100

Post by qwertyuiop924 »

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 happening. Show me that Truffle's Ruby implementation hasn't removed callcc (yes, Ruby has callcc), and maybe I'll reconsider.

Post reply on HN