> Interop with other truffle implementations such as java, python, javascript, llvm, and more.
Maybe "interop" is too weak a phrase for the incredibly powerful cross-language tooling that is allowed with GraalVM (ISLISP implementated on GraalVM's Truffle framework, ref OP link). For example of what is really possible, see "Ten Things You Can Do with GraalVM (2018)" [0][1]
I remember a weird misconception floating around "back in the day" that ISLisp restricted the cdr fields of cons cells to be either nil or cons. Or some sort of claim along those lines. But I see from even the 1997 draft that this is not true. I don't see anything that could be easily misread that way, either.
Where did that come from?
In fact, quite the opposite: ISLisp requires all atoms to be considered list terminators. It is documented for the length function that (length '(a b . c)) => 2.
I remember someone making that claim about Racket. Turned out they were using a very restricted subset of Scheme intended to be used for a particular introductory programming book, not the actual Racket language.
I see ISLisp fixed a huge 1997 gaffe in 2007. (Or perhaps earlier; these are all drafts).
1997 draft: "For eq, the consequences are undefined if either obj1 or obj2 is a number or character."
2007 draft: "For eq, the consequences are implementation defined if both obj1 and obj2 are numbers or both are characters."
They are still neglecting the possibility of cleaning up the language here by not allowing that much implementation latitude. All Lisps should have a range of fixnum integers which are unboxed, and comparable with eq. Characters should also be unboxed and comparable with eq.
It's also buggered in the following way: eq should be required to yield false if the arguments are such that eql would yield false. If the arguments are different numbers, or the same numeric value but of a differnt type, they cannot be the same object; eq should yield false.
Also, what is "implementation defined"? Unfortunately, it is vague: "feature, possibly differing between different ISLISP processors, but completely defined for every processor". How is it defined, if this document doesn't define it?
Every language spec that doesn't completely define everything should have both implementation-defined and unspecified behaviors. It should spell out that in those situations, failure is not an option: the behavior is chosen by the implementor from a set of possibilities. There should be a requirement that the implementation must be accompanied by a document which describes the implementation-defined choices. (For unspecified behavior, how the choice is made need not be documented.)
What eq does with numbers is a great candidate for unspecified behavior. At least, if we accept the idea that two small integers like 1 and 1 could be different objects. If you give implementations that much latitude, just let it be unspecified so they don't have to commit to the details.
Today, I would specify that the implementation must provide a range of integers called fixnums, and that two fixnums of equal value compare true under eq. I would also require that characters be comparable with eq. There is no need to cater to toy implementations which make every object a pointer to a boxed value in the heap. I would specify that fixnums go from at least -8192 to 8191. That allows for 16 bit objects to have 2 bit type tag, for really small systems.
As a matter of orthography, the compound adjective implementation-defined should be hyphenated.
Performance concerns are WIP, it's too early to meaningfully benchmark. I did some napkin benchmarking against sbcl for curiosity and it was ~7 times slower
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.
"In ISLisp, language specifications are separated from processor specifications. ISLisp forms after macro expansion and other pre-processing are called "prepared form" and ISLisp does not define preparation procedures."
The text you're quoting implies the language has a macro expander. There are arrays and vectors, so you could implement hashmaps, and I think some of the implementations of the language already does.
That exact text is not found in the spec; it's from the ISLisp page. ISLisp does have the concept of "prepared form" it refers to, but you have to look at the spec to understand what that means.
It looks to me that this "prepared form" is the same as in other traditional Lisps: that the source code of the program is defined in terms of nested lists, but may undergo a transformation into an undocumented form (for instance ARM machine language) in preparation for execution. E.g. in Steel Bank Common Lisp, everything you type into the REPL is first transformed into machine code and then run. Common Lisp doesn't define the details of such a thing, but does have a lot to say about compilation.
The actual ISLisp says:
An object is prepared for execution; this might include transformation or compilation,
including macro expansion. The method of preparation for execution and its result are not
defined in this document (with exception of the violations to be detected). After successful
preparation for execution the result is ready for execution.
Obviously, the macro expansion parts are defined at least to some extent because it interacts with user macro definitions. (Perhaps even when it comes to macro expansion, ISLisp doesn't nail down the exact semantics, like when exactly is it done. It's possible for a pure Lisp interpreter to work with unexpanded code and continuously re-expand any macro call that it encounters, in the latest dynamic environment. That allows for macros to be fixed on-the-fly.)
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.
I think the name is good. It took me a whole second to figure out its selling point, especially since there is a new "lisp" being made every day. Fancy names are exciting for like a millisecond. Good luck with the project! Im a Common Lisp user but this seems like a plausible alternative to Clojure and even ABCL
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.
Maybe "interop" is too weak a phrase for the incredibly powerful cross-language tooling that is allowed with GraalVM (ISLISP implementated on GraalVM's Truffle framework, ref OP link). For example of what is really possible, see "Ten Things You Can Do with GraalVM (2018)" [0][1]
[0] https://gist.github.com/chrisseaton/535e0e80ea19803d5529c623...
[1] https://news.ycombinator.com/item?id=36723587