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!
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
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.
Not at all, that would be awesome. It's GPL'd, have at it. (^_^)
I typically use SWI Prolog but I hope the code is mostly portable. The
parser uses a couple of DCGs from the "basics" lib but I think those are
also portable or at least simple to re-implement.
The tricky bit might be the semantics of math (and comparison) ops. I've
tried two other sets of semantics, one that attempts to perform math
operations (and catch the errors if e.g. an arg is a logic var rather
than an int) as you go, and another that just builds expression trees
(evaluation is delayed) like so:
func(+, [int(A), int(B)|S], [int(A + B)|S]).
Just to point out, in SWI Prolog the ints are "BigNums" while in GNU
Prolog they're machine words (so modular arithmetic, mod 2^32). You
could use Rationals or make up some other semantics. This all gets into
Categorical paradigm programming. http://conal.net/papers/compiling-to-categories/
The same (point-free) expression can be used to develop concrete programs
over various categories: Hardware circuits, partial evaluation,
differentiation, dataflow graphs, and so on.
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!
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.
Thank you a lot Mark for participating in this discussion, and for all your work on Scryer Prolog during the last few years!
In the hope to attract further contributors to Scryer Prolog, especially with interest in Rust, I have now created a GitHub issue that collects a few self-contained features that could be interesting to look into for Rust programmers:
I hope that's OK, and I invite everyone who is interested in these topics to contribute to this very innovative new Prolog system! Already in this early stage, it provides several important features that no other system currently has. Thank you again!
From the interface (mostly yes, that, is apart from the impure extensions added later, and that chars are used and not codes) it is the same. But from the implementation behind it´s different. In particular from the space requirements. A text of n characters requires 3 * 8 * n bytes in SWI, but n + 2 * 8 bytes in Scryer. So there is a factor 24 in space requirements (on 64bit).
Also, there is now ample room for input that SWI once almost offered.
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:
> 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.
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!