Proposal: Make the Package Manager Target General Prolog Compatibility

[constraintAutomaton]

From my understanding, Scryer Prolog aims to adhere closely to the ISO Prolog standard. In that spirit, I believe the package manager should be designed as a general Prolog package manager, not tied to a specific implementation. It’s true that some Prolog systems offer more features than others, but the package manager could handle this by checking whether a package conforms to the ISO standard and advertising that fact in its manifest. It could also indicate which Prolog systems a package is compatible with. Of course, things could get more complicated if a package includes a "compatibility" layer for different systems, but I still think this approach would encourage greater portability and reuse.

[triska]

Very interesting proposal, thank you a lot!

Regarding this specific part:

things could get more complicated if a package includes a "compatibility" layer for different systems

I would not worry too much about this. A "compatibility" layer in applications and libraries tends to decrease the motivation for convergence between different Prolog systems from system implementers and application programmers. No way to even specify or test different Prolog systems has a greater likelihood to increase compatibility between different Prolog systems.

[bakaq]

I have thought about that extensively before, and I think this would be a whole different level of endeavor. ISO Modules aren't really implemented in any system, and even if they were, the standard gives so much leeway that implementations would probably be different enough to be incompatible. We could make a system that only used 113211-1, and it would have the benefit of being compatible even with strictly conforming mode, but that would be a real pain because most interesting features of Prolog systems would be really hard to access (Scryer has dif/2 behind a module for example).

The reality we have is that each system has it's own module system. Most implementations use a Quintus-style module system like SICStus and Scryer, but there are significant variations even there that hinder compatibility (Scryer's module system has module scoped operators while SICStus doesn't, for example). On top of that, standard libraries often have different names, and some predicates are given by one module in one implementation and another in other.

Like @triska implied above, the right way to do compatibility in this case would be to do feature detection, not specifying the Prolog system. The fact that there is no standardized way to do that complicates this immensely, but I have some ideas. You could make test Prolog programs that try to use the feature (Quintus modules, source module of certain predicates, etc...) and use the standard ISO predicates around it to communicate whether that feature is available. In general this would have to be done in different programs, because many features need to mess with global state to be properly tested. We could then make so that packages announce which processor features they need in the manifest, and then before running the program the "runner" would test for those features in an arbitrary Prolog processor binary provided, create the appropriate shims if necessary, and then run the package in that environment. This gets into reimplementing LogTalk really quickly though, and while I think it's eventually worth doing, making a simpler package manager that is compatible with just Scryer and maybe close systems like Trealla will be much higher impact (by allowing a proper ecosystem to form around things like library(clpz) and library(reif)) for much less upfront work.

I would be interested in hearing any different opinions though.

[triska]

Supporting Scryer and Trealla as a first step seems like a very good and useful start!

[constraintAutomaton]

I'm not very familiar with Prolog systems, so I’m not sure, but I was wondering if it might be possible to automate some rewriting to help with compatibility issues, like handling imports with different style or packages that have different names but provide the same functionality, or combining predicates that are equivalent to a single one in another system. That said, I realize this probably goes beyond just package management. I also understand @triska’s point that this could further entrench the differences between Prolog systems.

But, yes, I think focusing on Scryer and Trealla is probably the best starting point. Since they aim to be ISO compliant, this approach likely stays aligned with the "dream" of creating a general Prolog package manager.