Hacker News Reader

Hacker News

Comment by otikik | Hacker News Reader

Full thread

otikik

To me Haskell looks more like “The Good Place” (season 1)

If this was calling Rust from Lisp, on the other hand…

View on HN

Lisp has already walked the 8th circle of hell to write the first Malbolge program.

Calling a C stub written in Rust using Lisp's C FFI is just your average Tuesday in comparison.

Implementing scheme or lisp in rust is probably a path to zero cost data movement between the two. Write the garbage collector in the abstractions rust understands, use roughly the same data types on both sides. That might be worth having.

edit: and there are lots, already, where for each one it is difficult to tell where it lies on the spectrum from vapourware to production

a common lisp implementation in rust wold have potential to be quite the contender to sbcl

Why? I don't think of SBCL's problems as being particularly related to the language it's implemented in, but a lot more related to the complexity of making an optimizing non-JIT compiler for a language as complex as CL.

the codebase is old and in c. a rust version gives new rust devs a chance to cut their teeth on building a lisp and learning about lisp as well. plus we could get a interop with crates. imagine if cl code could call rust crates for instance.

The codebase is old and almost entirely in Lisp; parts of the runtime are in C, but they're also not the parts that are getting worked on, because they're not where the bugs are (because so much of it is in Lisp).

Unless Rust has gotten runtime reflection without me hearing about it, I don't think writing the compiler in Rust gives you any special powers in interfacing with Rust. You'd get a lot more of a win from parsing the DWARF of a library when you dlopen() it, and using the type information that exposes to be able to use the full Rust ABI rather than the C ABI.

EDIT: Actually, no, even with runtime reflection, that would only help an interpreter, not a compiler.

That still wouldn't give you the ability to perform template instantiations at runtime though -- for that, you'd need to ship the Rust compiler with your Lisp _applications_, since you might be able to invoke a Rust template with arguments at runtime that hadn't been seen before.

If you're looking at work on building a more modern Lisp compiler, check out SICL or Clasp, though as far as I'm aware, those are both early-ish projects.

CLASP may be newer, but it is hardly more 'modern'. There is only limited adoption of CLASP in the Lisp community, because its advantage (excellent integration into C++) is only interesting for a small group of users. At the same time its disadvantages (complex implementation, much slower than SBCL in both development and application, less compiler sophistication for the Lisp user, ...) limit its adoption. CLASP is a special purpose CL with the aim to easily interface to large libraries of C++ code. It maybe be newer and also a great piece of engineering, but it is no competitor to faster implementations. SBCL can compile itself in roughly a minute on a current machine - something like CLASP takes a lot longer. With SBCL we'll have already the much faster and more responsive implementation.

why would one implement Common Lisp in Rust? Most implementations are largely written in Common Lisp itself, plus some runtime (memory management, threads, OS interface, ...) underneath. The runtime can be specially written in C (maybe Rust) or it could be an existing VM, like a JVM. Writing Common Lisp itself in Rust or C or whatever makes little sense. For the runtime it makes sense, since it needs to interface to the underlying hardware and the operating system.

Reply on news.ycombinator.com