Implementer here. I haven't set out to "implement an existing thing." Rather, the project is a combination of certain existing things that up to now haven't been available together in a single open source Prolog environment, SWI included. Some of these choices have far reaching implications in terms of what can/cannot be easily implemented -- see https://www.metalevel.at/prolog/attributedvariables. SWI is much more monolithic, slow moving and not particularly ISO compliant. I don't want to reproduce the entirety of SWI and its huge ecosystem. I want a trimmed down set of features that are core to what I want out of a Prolog system, which does not include 95% of SWI. I suppose it could, but I will leave that up to others, if that's what they want.
Originally, the project started because I wanted a Prolog that could talk to Common Lisp. Prolog powers the type inference engine of the Shen programming language, a Lisp with optional static type checking. Implementing Shen in CL was something of a no-brainer, because I knew I wasn't going to beat SBCL for Lisp performance. Plus, I wanted to learn the ins-and-outs of Prolog implementation and also retain some of my sanity during the Prolog-to-CL FFI part. That meant avoiding existing Prologs.
Intriguing project! I think you've settled on a useful set of tools as Rust can be embedded readily in another language or runtime system while still providing memory safety with a modern language features without dealing with C++ or impossible FFI scenarios. Personally I see the "X in Rust" of a lot of projects of late as a "oh I could be reasonably confident in building something solid on top of that quickly without shooting myself in the foot by messing up a C library API". It seems Rust provides a good ecosystem to implement reusable core primitives. I've been exploring how to use some simpler parts of Prolog/DatalSC in a library, which this project targets almost perfectly. Looking forward to reading how you implemented the core prolog algorithms!
Definitely, yeah. I'd hate to be tasked with creating an interface between SWI and SBCL. I would quickly go mad. Not that it will be a cakewalk with Rust, necessarily, but Scryer is much smaller, and Rust is way better behaved than C.
Furthermore, programming in Rust has some unique challenges (like the borrow-checker) that make traditional line-for-line or function-for-function re-writes unfavorable. The average Rust re-implementation tends to do more re-architecture than the average $FOOLANG re-implementation, which tends to make them more education.
There's also an aspect that Rust is still seen as "unproven," compared to its rather bold goals and claims. A re-implementation of something existing is a good opportunity to see how well Rust-in-practice manages to approach Rust-in-theory, and in some ways is better for that purpose than a green-field Rust project.
Personally I prefer post-mortem write-ups rather than links to an active code-base, but you take what you can get.
reimplementing is interesting and definitely cool, but what i really want to see is what NEW previously-almost-impossible-to-achieve products/artifacts we can create with these new languages...
I think we’ll definitely see that, but I we’ll see that after people get comfortable with the language, and doing rewrites is one way people get comfortable with a language.
I agree. Kudos for starting this project but Swi-Prolog sets a very high bar for implementation quality and a huge ecosystem (given the size of the Prolog community).
Chalk is a PROLOG-ish interpreter written in Rust, intended eventually for use in the rustc compiler. Chalk recasts Rust's trait system in terms of logic programming. Its goal is to be an executable, highly readable specification of the Rust trait system.
Yes, that's right. Scryer as in scry-ing, the practice of gazing into crystals to communicate with spirits. I wish I'd thought of a better name but it's too late now.
