mthom

thank you! the scryer community deserves much of the credit too. everyone is welcome and encouraged to join us at https://github.com/mthom/scryer-prolog! some exciting plans in the pipe

I've spinning up a new Shen implementation from scratch, in Racket, which integrates directly with my Prolog implementation, Scryer Prolog:

https://github.com/mthom/scryer-shen/

Several innovations are documented in the README. Both the Prolog implementation and the type checker are written in / hosted by Scryer (Prolog implementation is done, the type checker is in progress). Scryer has many powerful constructs for monotonic reasoning which should help to take Shen's type checker in particular to new heights of power!

not interested unless it is about the 80s indie pop band

The cat that pamphlet is about, Nightlife Mingus: http://achewood.com/?date=06202003

The ISO standard does not yet say anything about FFIs. I've heard that SWI's FFI is hampered by its garbage collection somehow. Since I'm working on a GC for Scryer now, it's probably a good idea to consider FFI concurrently. "A beginning is such a delicate time." I remember reading that somewhere.

No FFI yet, no. I'll first try to adapt LispWork's Foreign Language Interface by writing a compatibility layer for Rust. If that goes well, I'll begin to explore writing a Common Lisp FFI to Scryer, which may give insights on how to interface Scryer to languages like C and Java.

I'm planning version 0.9.0 soon. From there I hope to get back to a regular release schedule.

You don't mind if I port Thun to Scryer Prolog, do you? With full credit to you, of course. I'd like to include it as an example.

Scryer is not yet as fast or feature-rich as SWI. SWI has been in business for about 30 years longer, so that shouldn't surprise anyone. Also, Scryer is committed to strict conformance to the ISO Prolog standard, which SWI has disregarded for a while now.

Yes, thank you for the Power of Prolog! Scryer was and is being written under its influence.

Decently, I'd say. It is a single executable that you have to build yourself. If you want a recent build, there are a few extra steps, but they're nbd. There are build instructions in the README ("Installing Scryer Prolog") at:

http://github.com/mthom/scryer-prolog

Some coming features of Scryer Prolog for those interested:

- Automatic detection and compilation of partial strings

- Streams, including sockets

- Garbage collection in anticipation of very fast yet logically pure I/O

- Improvements to the instruction dispatch loop (many opportunities for enhancement there, probably a good place to start for a beginning contributor)

In the past few months, we've added delimited continuations, tabling, partial strings, and Markus' CLP(B), CLP(ℤ) and format libraries. For a hobbyist project I'd say we're moving at a fairly quick pace!

Longer term, we're interested in:

- JIT compilation to native code (Cranelift seems a good candidate?)

- Low-level integration with Common Lisp environments

I'd love to have system-level contributors, although library contributions are always very welcome!

To be clear, the "automatically caught" exception Markus lists in his integer_si example was caught and displayed by the Scryer toplevel.

I'm not sure what's more amusing/depressing: that these people believe any shift on the order of magnitude the book described in the article predicts will permit continued functioning of society in a way that supports these individuals' wealth, or that these individuals believe that their wealth puts them in a "cognitive elite."

It's a tautology of modern western culture that if you're rich, you must be smart, so.. yes.

Thanks!

I'm guessing the Prolog compiler is super complex compared to, say, a C compiler to be able to give developers that much power.

They're not that complex. I'm writing one from scratch right now:

http://github.com/mthom/scryer-prolog

Speaking of constraint solvers, the author of Power of Prolog, Markus Triska, is now in the process of porting his clp(ℤ) constraint solver over to my system, having already ported his boolean constraint solver, clp(B). They are quite complex, but it helps that they're written entirely in Prolog.

No, and I have no idea what sort of legal can of worms that might open.

I took a break from working on it over the summer, and am about to start again. If anyone would like to pay me to work on it full time, do let me know.

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.

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.

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.

Wonderful and inspiring work! I wonder if it would be possible to create a similar interop story with the Rust programming language, which also targets LLVM -- ideally without having to redo all the hard work that went into Clasp. I have a Prolog interpreter/compiler I'm developing in Rust right now. One of my aims (eventually) is to compile Prolog to fast native code with it. It would be nice to have convenient access to it from a Common Lisp environment.

It is almost as though, prior to blockchain, nobody had conceived the idea of a distributed spreadsheet.

The title could really benefit from an Oxford comma.

I don't know enough about answer set programming to give much of an answer. Sorry.

New language constructs. The 'WAM' in the name refers to the Warren Abstract Machine, one of the more efficient ways to implement Prolog in a procedural language.

Also, using the SICStus interface and semantics for attributed variables should make for some very general constraint solvers, yes.

I'd venture to say.. Prolog and Shen. Specifically, I am implementing a modern Prolog in Rust that will encompass the results of some more recent (ie. current century) research within the logic programming/Prolog community. It's here:

http://github.com/mthom/rusty-wam

You're on HN, my man, the solution is never not an app!