So why is Oracle doing this?
Also, anything from Oracle which is partly open and partly closed is scary. They've done that with Java and MySQL, which drives people away from both.
Graal and Truffle could accelerate programming language design
71–80 of 204 posts
Re: Graal and Truffle could accelerate programming language design
#72Funny, 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.
Re: Graal and Truffle could accelerate programming language design
#73Earlier quoted context omitted.
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.
> Because Lisp is homoiconic, you don't code in (what I personally believe to be) reasonable syntax, you code in abstract syntax trees. There's no reason a regular macro couldn't implement a basically C-like syntax (though it would have Lisp, not C, tokenization rules, to the extent that those are different) on what is passed as its argument. The actual call to the macro would have typical Lisp syntax, but what the m…
I've never seen something like this before--do you know of any examples of this kind of macro usage?
Re: Graal and Truffle could accelerate programming language design
#74> Since the dawn of computing our industry has been engaged on a never ending quest to build the perfect language. Except it really hasn't. The industry is going to use whatever language has the bare minimum feature set they value at the moment and no more. Call me cynical but my point of view is: if the industry were really striving for perfection, there would be no COBOL or BASIC, for instance. Lisp had already bee…
The majority never picks the best and markets do not optimize as much as some people think. Whether it's movies, arts, books, music, politicians, keyboards or programming languages, the most popular choices are practically never the best ones. Which is probably why a technocracy in which every voter must pass a fact-based proficiency test before being allowed to vote might trump democracy. Not sure, just wanted to ch…
Who gets to determine which facts?
Why would that group not use that to their advantage, instead of to the benefit of everyone?
> The majority never picks the best and markets do not optimize as much as some people think. Whether it's movies, arts, books, music, politicians, keyboards or programming languages, the most popular choices are practically never the best ones.
The question is not whether the market picks the optimal outcome, but whether a committee of experts would do better. The experience of central planning within the Warsaw Pact should hint at the answer...
Re: Graal and Truffle could accelerate programming language design
#75Earlier quoted context omitted.
> Because Lisp is homoiconic, you don't code in (what I personally believe to be) reasonable syntax, you code in abstract syntax trees. There's no reason a regular macro couldn't implement a basically C-like syntax (though it would have Lisp, not C, tokenization rules, to the extent that those are different) on what is passed as its argument. The actual call to the macro would have typical Lisp syntax, but what the m…
I've never seen something like this before--do you know of any examples of this kind of macro usage?
This article provides a simpler (but conceptually similar, where it comes to implementing syntax different than standard Lisp S-expression syntax) example of using reader macros to implement JSON literals in Lisp.
Re: Graal and Truffle could accelerate programming language design
#76Judging 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 novel control-flow semantics (asymmetric coroutines that can yield across multiple, unadorned function invocation) nor performance capabilities (JIT-optimizing Lua tables is non-trivial).
I'm not even sure LuaTruffle implements Lua's lexical closures or tail call optimization, both critical to Lua's ability to support functional programming patterns.
Of course, it definitely doesn't implement the Lua C API, which is part-and-parcel of what makes Lua preferable as an extension and glue language. But I was willing to overlook that if it could easily implement the former.
The beauty of a good DSL isn't the syntax (I know, hard to believe!), but in novel approaches to code flow execution and other deep semantics. Golang's goroutines are beautiful. Rust's ownership analyzer and prover are what _defines_ the language. Haskell's lazy evaluation open up whole new dimensions for problem solving (and headaches). If your language framework doesn't at least preserve the ability to implement those things cleanly and performantly, it's not adding much value and is basically a toy. It's not like writing a lexer for a DSL is a serious impediment. (Using Lua's LPeg, for example, you can write parsers and build an AST for most major languages in a few hundred lines of code.)
Re: Graal and Truffle could accelerate programming language design
#77Earlier quoted context omitted.
> You cannot. You can. Reader macros let you put whatever syntax you want on top of Sexprs. For example: Welcome to Clozure Common Lisp Version 1.10-r16479M (DarwinX8664)! ? (spark-init) #P"/Users/ron/devel/spark/ergolib/init.lisp" ? (require :parcil) ... ? (in-readtable infix) |NIL| ? infix(x=1.23+4.56) 5.79 ? sin(x*x+1) 0.03341171 ? The code for this is here: https://github.com/rongarret/ergolib
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 concept of "metaprogramming a syntax" (so that you can talk about whether or not a language can "only metaprogram its own syntax") is non-sensical, a category error. Metaprogramming is simply writing programs that write programs. What makes Lisp cool is that it separates the syntax from the program. A Lisp program, unlike all other languages, is not text. A Lisp program is a data structure. Lisp happens to define a textual surface syntax (S-expressions) that allows you to easily convert text into the particular data structures that are Lisp programs (and also incidentally data structures that are not Lisp programs) but you can also produce these data structures in other ways, like, for example, writing programs that produce them. The textual surface syntax is a detail. Writing an infix parser in Lisp is an elementary exercise, and you could use that parser to parse C-like code whether or not you had reader macros. All reader macros let you do is seamlessly integrate that C-like syntax into the Lisp REPL rather than having to embed your new language in strings or read it from files.
Re: Graal and Truffle could accelerate programming language design
#78Earlier quoted context omitted.
To add to the examples, Truffle currently has interpreters for unmanaged languages such as C/Fortran (with Sulong), dynamic languages such as Ruby and JS, statistics/math like R and functional like Clojure. The interopability is done in a way that does not need a common representation or object layout. > I wouldn't use Rust for the syntax; I'd use it because I want properties like complete memory safety, manual contr…
The big question is "Would you want to use this in a mission-critical project?" Emscripten lets you write webapps in C, for example, but outside of sharing common libraries across server/Android/iOS/web clients, few people use it. Pretty much every professional job I've had used polyglot programming of some sort - when I was in financial software it was mixed Java/C/Fortran numerics, when I founded my first startup i…
The idea of Truffle language interoperability is to avoid switching the representation at the language boundary. Objects carry their type information with them that includes the semantics on how to access their properties. This also allows Truffle to fake up the existence of an object without actually performing allocations (e.g., a table in raw buffer format can be interpreted as an array of objects). This clear separation of logical and physical layout enables efficient data representation in the context of higher level languages that typically suffer from pointer chasing and object header overheads.
Re: Graal and Truffle could accelerate programming language design
#79Earlier quoted context omitted.
The big question is "Would you want to use this in a mission-critical project?" Emscripten lets you write webapps in C, for example, but outside of sharing common libraries across server/Android/iOS/web clients, few people use it. Pretty much every professional job I've had used polyglot programming of some sort - when I was in financial software it was mixed Java/C/Fortran numerics, when I founded my first startup i…
The idea of Truffle language interoperability is to avoid switching the representation at the language boundary. Objects carry their type information with them that includes the semantics on how to access their properties. This also allows Truffle to fake up the existence of an object without actually performing allocations (e.g., a table in raw buffer format can be interpreted as an array of objects). This clear sep…
Right, and my point is that this won't work unless you dictate a common memory layout for all Truffle objects. And if you do that, then you lose the ability to make trade-offs about object representation that depend upon access patterns that only the programmer can know. The whole reason we have different programming languages is because not all domains of computation face the same trade-offs.
Re: Graal and Truffle could accelerate programming language design
#80Earlier quoted context omitted.
To add to the examples, Truffle currently has interpreters for unmanaged languages such as C/Fortran (with Sulong), dynamic languages such as Ruby and JS, statistics/math like R and functional like Clojure. The interopability is done in a way that does not need a common representation or object layout. > I wouldn't use Rust for the syntax; I'd use it because I want properties like complete memory safety, manual contr…
The big question is "Would you want to use this in a mission-critical project?" Emscripten lets you write webapps in C, for example, but outside of sharing common libraries across server/Android/iOS/web clients, few people use it. Pretty much every professional job I've had used polyglot programming of some sort - when I was in financial software it was mixed Java/C/Fortran numerics, when I founded my first startup i…
That's exactly how Truffle's cross-language-interface works though. Instead of paying the high cost of conversion, data stays in its existing representation and it is the interface code that is recompiled to fit.
An example is JRuby+Truffle where in its C extensions, pointers to Ruby objects act to the C code as if they are pointers to MRI data structures, but behind the scenes Graal compiles code that accesses them like the JRuby objects that they are.
The C-memory to Java GC transition doesn't work as well, but you can get around that by implementing C-memory using the Java GC like the Managed-C paper does, alternative implementations only have to keep the same behaviour, not the same underlying data representation.