scryer-prolog
scryer-prolog copied to clipboard
mthom
scryper-prolog as a library
I was wondering if it's possible to use scryper-prolog as a library such that it can be embedded into other applications as a backend for solving certain logic puzzles.
Is there a reason to use a library for this? One very good solution for such use cases is often to use well-established interface mechanisms such as pipes, files or sockets to communicate between the two processes. This allows easier coupling and debugging, and also keeps the core small.
One important feature to easily communicate between processes is described in #187 (update: and it is now already available). With this command line option, you can dynamically specify a goal, and get the output via standard mechanisms directly from the Scryer process.
I'm considering using Prolog inside SGX, a hardware feature available for some Intel CPUs. In SGX mode, performing I/O is expensive and can be extremely insecure. That's why a library is more desired.
You could always package the machine submodule as a library, sure. I'm not thrilled with the way expansions and the toplevel interaction are currently handled, though. I would want to revise them to be faster and more Prolog- rather than Rust-based, as they now are. Their current form is a holdover from the early days of the project.
I am considering using scryer as a parser frontend for a JIT interpreter (the parser is written in prolog). Would be great if it's embeddable.
I also think this is a great idea - I would like to use some prolog-like machine for type resolution for experimental language (and this is exactly what Rust is doing with chalk, so it's tested idea). Communication via pipes/sockets kills performance.
A start solution would be to write a src/lib.rs with all the modules, then the visibility/privacy problem can be solved later with an example/reason to use a data structure, function, ...
Yeah, that'd be a great start! I wonder if it would also make sense to fold #765 and #570 and this into a single issue (or, rather just pick one and close the other two?) That'd would help the conversation around this be less fragmented.
In case it's useful context, I was considering using an embedable prolog as an alternative to sqlite (nice properties, like being able to write the database to a file in a readable way, and commit that to git, easily defining transitive closures, etc.). Of course, I could communicate through system calls, and manually implement de/serialization for data etc., but that's more over-head and requires an external dependency.
Making a new issue to track the progress once all the others are closed is a possibility to better organize. For now the library doesn't exist yet.
A heads up for anyone subscribed to this issue - the initial work is here https://github.com/mthom/scryer-prolog/pull/838
@triska I performed some initial experiments to communicate via scryer-prolog via STDIO or TTY - in both cases I encountered some difficulties, one case might even be a bug (the panic that happens with STDIO) see details here: https://github.com/mthom/scryer-prolog/discussions/1413
@peschue: If Scryer crashes, then this is definitely a mistake somewhere in the code, please consider filing it as an issue with a minimal example, which ideally only needs a shell invocation or pipe on the command line. Thank you a lot!
@triska I created issue https://github.com/mthom/scryer-prolog/issues/1439 for this.
There is a very promising contribution with the potential to resolve what remains of this issue: #1880.
Please try it and comment if possible!
@uraj: #1880 is now merged and I think it solves this issue. If it solves the issue for you, could you please consider closing it? Thank you a lot!
@triska I think this works. Thanks everyone for working on this over the years. Closing.