It's an implementation of an ISO-standardised Lisp, pretty much a cleaned up and streamlined ISO alternative to ANSI Common Lisp and the Scheme:s. Aims to be industrially relevant rather than academic, the object system is somewhat simpler than CLOS. More here: http://islisp.org/
The GraalVM is a tool used, among other things, to produce native binaries, and Truffle a programming language for implementing programming languages on Graal.
One could expect pretty good performance, possibly at the price of somewhat slow compilation.
Judging by the name, the exciting part is the framework it was written on. As a habit, I do not use software that relies on code association in the name as a selling point. A lot of new coders use this naming convention, as they've become excited cheerleaders for their platform of choice (especially if it is a recent language or framework). But how much do actual users care about the underlying technicals? Why make the software sound like it is part of the language or framework when it isn't?
Imagine if there was an InlineAsmGrub to compete against that other GRUB. It's just that silly a practice.
I see where you're coming from, and the naming was quite unimaginative, indeed. I saw that "truffle ruby" called itself that and copied it.
However, the fact it's based on truffle is the selling point -- truffle enables interop between languages on the framework. So, for example, you can take truffle JS implementation, import express library or whatever, and then as part of the implementation do
````
let fn = Polyglot.eval('islisp', '(lambda (x) (+ x 1))');
fn(1);
````
(toy example. But this interop can happen in all directions, it's not limited to js but can be used from truffle python, ruby, java, etc; and it also isn't limited to just primitive values, you can pass around functions as well).
If you aren't looking for a specifically a truffle lisp, it would make more sense to use one of the established common lisp implementations.
When building an alternative implementation of a language you're a bit hamstrung by the name. You could come up with something completely novel, but no one is ever going to discover or use your software. So, it's quite common to integrate the language name into your software name somewhere. The next question then is how to differentiate. Oftentimes the underlying framework is really the selling point. JRuby is Ruby on Java. TruffleRuby is Ruby on Truffle+Graal. It's easy for people to quickly identify and understand the difference. Instead of calling it TruffleRuby, I suppose we could call it PartialEvaluationRuby or SuperFastRuby, but those naming conventions have their own flaws.
Do you have a suggested naming convention to follow? There's a rich history of alternative language implementations following the convention you dislike, but I think those involved would be open to an alternative.
cess11|1 year ago
The GraalVM is a tool used, among other things, to produce native binaries, and Truffle a programming language for implementing programming languages on Graal.
One could expect pretty good performance, possibly at the price of somewhat slow compilation.
unknown|1 year ago
[deleted]
BoingBoomTschak|1 year ago
Good joke.
ksaj|1 year ago
Imagine if there was an InlineAsmGrub to compete against that other GRUB. It's just that silly a practice.
arvyy|1 year ago
However, the fact it's based on truffle is the selling point -- truffle enables interop between languages on the framework. So, for example, you can take truffle JS implementation, import express library or whatever, and then as part of the implementation do
````
let fn = Polyglot.eval('islisp', '(lambda (x) (+ x 1))');
fn(1);
````
(toy example. But this interop can happen in all directions, it's not limited to js but can be used from truffle python, ruby, java, etc; and it also isn't limited to just primitive values, you can pass around functions as well).
If you aren't looking for a specifically a truffle lisp, it would make more sense to use one of the established common lisp implementations.
nirvdrum|1 year ago
Do you have a suggested naming convention to follow? There's a rich history of alternative language implementations following the convention you dislike, but I think those involved would be open to an alternative.