Note that SWI-Prolog GUI capabilities are (nowadays) first an for all for supporting the (GUI) development tools. My question was more, are (GUI) development tools still worth focussing on? I think the answer is mixed. On the one hand, coding agents allow talking English (or some other natural language) and end up with a Prolog program, fix a bug, etc. On the other hand, many of us still distrust this and either like the coding or like to carefully review what the agent has been doing. I’m now in the latter category for critical code. That said, the current XPCE moved to version 8 as it is now pretty capable of rendering nice interactive graphics with little Prolog code after adding 2D transformation matrices and opacity. Better yet, coding agents can write such code.
I’m now working on a SWI-Prolog MCP server framework and an MCP server that makes most of the development tools accessible for coding agents. That is based on the data collection that underpins the GUI tools, but now generating terse reports suitable for coding agents. Claude code wrote 95% of it. I’m now reviewing it and cleaning up some the Prolog APIs to extract the data.
I wonder whether you have anything specific in mind? I was under the impression SWI-Prolog is doing pretty well in this area with good C(++), Python, Java, Rust (external) and JavaScript (WASM) bindings as well as dealing with HTTP services, JSON-RPC (recent), STOMP (Message brokering), SWISH/Pengines, etc.
I think you are right. Multi-moded and determinism handling as well as terms that may either be of some type or be compatible with some time (e.g, [a,b|X] is not a list, but is compatible with a list) all makes this a real challenge though. I’ve played with the Hindley-Milner based type system by Tom Schrijvers. To me it feels too much like crippling the language. More elaborate is the Ciao assertion language. This too comes with a lot of restrictions, is complicated and doesn’t scale too well in its ability for static analysis of complicated real-world code. I’m still looking for something lightweight that merely finds pretty trivial bugs.
Regarding GUI, I long ago considered the debugger and profiler top-notch, except for their use of clunky UI elements. The editor to me was irrelevant.
Regarding language integration, I only know the old C and C++ bindings. They work well enough, but it was very very clear you’re stepping out of the C realm to manipulate these external objects.
pytorch manages to make it feel like you’re manipulating python variables. You npm install pytorch, import pytorch, ask for new variables, and you immediately start constructing vectors and doing arithmetic. Backpropagating gradient descent improvements are automatically happening.
Does Swipy do anything like that? Can a JS program easily import { stuff } from swi? Is there automation behind the scenes like React gives JS programs?
I read Jan’s post and completely share your wishes. I want to join in your words of support: I wish Jan a speedy recovery and strength. His contribution to the development of SWI-Prolog and the popularization of the language is enormous, and I am immensely grateful for the work he has done over many years.
I’d also like to share my personal experience using AI in Prolog development. Over the past six months, with the help of AI, I’ve accomplished things I previously simply couldn’t bring myself to do due to a lack of time and energy. I’ve written tools I’d been putting off for years.
The most striking example is that I created a native PostgreSQL driver, which I’d been missing for so long. I couldn’t use ODBC for a number of reasons, but now I have a full-fledged stack for writing Prolog code. With the help of AI, I’ve automated the build and configured deployment to servers—before, I’d only gotten around to the basic configuration. Now I can deploy my code to production servers with a single command. It’s not just a time saver; it’s an opportunity to tackle tasks that previously seemed insurmountable.
I love Prolog and use it in my daily work. What Jan did gave us developers a foundation on which to build real projects. I’m incredibly grateful to him for that.
Swipy (Janus) provides you with a pretty comfortable way to access Python, as well as accessing Prolog from Python. There are some issues that e.g., numpy numbers are objects that are currently not mapped naturally to Prolog numbers. We probably need to find something better for that. The JS binding to call WASM Prolog uses comparable abstractions. Notably in the browser things are a little more complicated as we have to deal with asynchronous processing. There is a pretty high level of abstractions to deal with Promises in either direction though. There is no React kind of abstraction. It is probably possible to layer that on top.
Anyway, these interfaces are much more comfortable than the C interface. That is ok; the C interface aims at completeness and performance. The current C++ interface is not bad, but pretty verbose. Python and JavaScript both being dynamically typed languages make the interface much more concise, while shared garbage collection comes for free.
Likewise. AI managed where I failed: create a proper signed MacOS installer. It also did most of the preparing work to get to a signed Windows installer, notably wire building the Windows installer using GitHub actions which is required by SignPath. It also did most of the work writing the MCP server framework and giving that access to the Prolog introspection tooling. The MCP server framework implementation produced by the AI was pretty good. Access to the introspection tools less so. This is defensible as it had to separate the date collection from the GUIs. These interfaces are not all very clean and typically barely documented. It managed to get everything working, but I’m in the process of making it more elegant.
