Modern Prolog Implemented in Rust | Hacker News Reader

Modern Prolog Implemented in Rust

github.com

93 pointsxvilka20 comments

This has made me aware of the WAM book (http://wambook.sourceforge.net/wambook.pdf) [PDF], which I didn't know about up to now. I'm intrigued.

Why do $EXISTING_THING Implemented in Rust stories get so much attention here? It feels like I see one or two of these show up every week.

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).

"Reimplement an existing thing" is a decent way to learn a new language/system. People want to learn Rust.

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.

It's also a way to learn more about the thing being reimplemented.

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.

I think because it's interesting to hear what people have experienced when moving existing thing to Rust.

How hard was the task? My personal experience has been that it's often hard

What performance benefits did you get? Insane drop in resource usage is what I've seen

What did you contribute to the young Rust ecosystem? Many people end up fixing existing weaknesses or problems to get existing thing rebuilt.

I think these and others, get many of us interested in these types of submissions.

There's three just today:

- https://news.ycombinator.com/item?id=19545994

- https://news.ycombinator.com/item?id=19540845

And this one.

Next up: building a Rust compiler in Prolog.

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.

https://github.com/rust-lang/chalk

https://rust-lang.github.io/rustc-guide/traits/chalk-overvie...

There needs to be a pronunciation guide for: Scryer.

I can think of several alternatives. I'm currently thinking of: s-crier. Rhymes with cryer. But it would be nice to know for sure.

I'd suspect "scry-er", based on the word "scry", but I don't know either.

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.

Also see https://github.com/rust-lang/datafrog .

I tried to use it but wasn't able to understand how to keep the original Prolog/Datalog syntax, rather than describe it in Rust syntax.

Reply on news.ycombinator.com