2025 Goals for Scryer Prolog!

[jjtolton]

Hello everyone!

The future is around the corner -- so full of possibilities!! It's always much easier to do things next year than it is today. So, fire away!! What are your dreams and aspirations (or wants and desires) for Scryer Prolog in 2025??

[hurufu]

My wish is to have public repository of 3rd-party modules.

[jjtolton]

Me too!!

[jjtolton]

• Finish Embedded Scryer
• Make example libraries for embedded scryer in various languages
• Finish WASM scryer for javascript 🥳
• Come up with some kind of project / lockfile system @bakaq !!
• Use project/lockfile system with 3rd party module system @hurufu !!!
• Get some kind of command line package install tool for scryer
• make a damn video game with Scryer in it!
• Figure out a way to get an async event loop going in Scryer. All we really need are the equivalent of JavaScript promises, I don't think we need full concurrency/parallelism support.

[dcnorris]

• make a damn video game with Scryer in it!

On the Dec 12 Guix London meetup, Christine Lemmer-Webber underscored the value of games as robust and stringent tests. She featured in particular her space-shooter game Terminal Phase built using Scheme to test the Spritely Goblins distributed object framework.

[triska]

Personally, I hope the great ongoing work continues!

I hope, to name a few concrete examples,

• you @jjtolton and @bakaq succeed with the embedded Prolog system
• you @jjtolton find a great way to resolve existing goal and term expansion issues, and find sensible building blocks for the async event loop you mentioned
• you @aarroyoc and @bakaq extend the Scryer Prolog Playground so that it can be used as a substitute for a local installation
• you @bakaq continue thinking about how to best tackle CLP(Q) and possibly CHR with a simple and elegant approach
• you @notoria and @flexoron continue your contributions for CLP(ℤ) and tough arithmetic and logical issues
• new contributors continue to be attracted to Scryer Prolog.

As the foundation for all this, I hope you @mthom fully succeed with finishing and merging the pending rebis-dev improvements and eventually GC!

[triska]

Also, regarding applications of Scryer Prolog, I hope you @dcnorris present your work at one of the category theory conferences in 2025!

[jjtolton]

I forgot about the async event loop!! YES!!! HUGE GOAL/WIN FOR 2025!

[jjtolton]

I forgot about the async event loop!! YES!!! HUGE GOAL/WIN FOR 2025!

(oh wait, no I didn't forget it... I forgot that I mentioned it...)

[bakaq]

I'm obviously interested in finishing the embedding APIs, and then improve the Scryer Playground drastically with a real toplevel and such (which will bring many improvements to the Wasm interface, the embedding API in general, and the toplevel itself). Other things include:

• Improve documentation in general. In particular using the new "learning pages" feature of Doclog to have some "tutorial" and "guide" style pages on stuff such as how to use library(reif) and how to use attributed variables to create constraints.
• More comprehensive testing, ideally at least a few simple ones for every library so that regressions like [Bug] load_html/3 from library(sgml) nonfunctional on macOS #2588 are caught early. Maybe also figure out how to do some fuzz testing.
• Improve performance of Machine initialization. This will probably be hard and may seem a bit misguided when I could focus on improving correctness or other features, but it's related! Currently Machine takes a suspiciously long time to initialize, specially in debug mode, and spectacularly so in Miri, which means that any tests that need to initialize a Machine take a considerable amount of time just turning on. This includes all the Prolog based tests, so it adds up a lot. Improving this even just a bit would allow us to have much more tests, and therefore be more comprehensive with correctness and regressions. If improved significantly this may also make it viable to eventually run a significant part of the test suite in Miri (tokio and crossbeam are still blockers for running the entire suite).
• Migrate to using strict provenance Consider rust's strict_provenance? #2019. It was stabilized in Rust a few weeks ago and will probably be available in the next version. This will allow Miri to analyze deeper for undefined behavior, and possibly catch a few bugs.
• Work on at least a simple package system for Scryer Prolog. Not sure if we can, or should, get to a full package manager in 2025, but starting the work on a manifest and such will already have many benefits and it's comparatively very easy. Ideally we would have a system for ISO Prolog in general, but I don't think that would be very useful or even possible without reimplementing a good chunk of Logtalk (which I actually seriously considered doing a lot of times in a simpler and more extensible way).
• Finally figure out how to put Better line//1 and lines//1 #2260 into a module and upstream it.
• Property Based Testing library. Will also need improvements in rng support.

For the work of other people, I'm very excited for @mthom's rebis-dev to get merged (and also for GC, but I'm not sure we are getting that in 2025), @aarroyoc's work on the JIT compiler, and @jjtolton's C embedding APIs and everything it will enable.

[UWN]

• such as how to use library(reif)

Coincidentally, there is a question exactly about that!

[UWN]

dreams and aspirations (or wants and desires) for Scryer Prolog in 2025??

#16, same as in 2018.

That all (really all) resource errors produce a clean resource_error(Desc). Without this, testing becomes very much restricted. Think of (^)/2 in library(clpz) which now has quite advanced propagation (that is the best so far), but then this often runs into memory overflows. Also the space for bignums is not freed upon backtracking (#1908), again leading to unnecessary aborts ; and making extensive testing impossible.

From my viewpoint this is more important than GC. After all, how will it be possible to test GC if this does not work.

[jjtolton]

Oh I remembered another.

We could totally have a really good Prolog database system. I haven't seen one I like yet. I love Datomic, but we could take it even further by using actual Datalog syntax.

[hurufu]

I think terminusdb has some inspirations from Datalog

[jjtolton]

Yeah but they use JSON not Prolog. If there's anything I learned from Prolog, syntax matters.

[jjtolton]

Ah yes, one more. Project WAMWAM!

I'd like to see a version of the WAM implemented entirely in Pure Prolog!

[hurufu]

GNU Prolog comes to mind 🤔

[jjtolton]

GNU Prolog implements a WAM in Prolog??

[jjtolton]

Oh even better, a WAM implemented in the video game Turing Complete!

[hurufu]

GNU Prolog compiler is implemented in Prolog and it compiles Prolog syntax to WAM instructions (more-or-less in reality it is more complex). Or were you talking about WAM machine itself?

[jjtolton]

Yeah I meant the WAM itself! Although I did not realize that the GNU compiler was also written in Prolog, that's pretty cool :)