3 ms·

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 bee

by mthom 8y ago

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

elcritch 8y ago
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!
- mthom 8y ago
  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.

by mthom 8y ago

elcritch 8y ago

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!

mthom 8y ago
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.