Chesterton's Fences in Scryer Prolog

[triska]

Chesterton's Fence was mentioned in a recent discussion (#2564), and I think this is worth thinking about.

Speaking for me personally, there are definitely things I am deliberately not doing. A few examples:

• I deliberately don't mention the time complexity of constraints in the documentation of library(clpz), because the implementation of constraints is meant to remain flexible, and future versions may become faster or slower as needed. I also would like to encourage trying different constraints.
• I deliberately don't document labeling options that result in random behaviour, because I would like to encourage thinking about better formulations instead of leaving it all to chance.
• I deliberately don't produce an exhaustive list of impure predicates, because such a list would only needlessly draw further attention to these predicates. The interesting question is: What is a minimal set of constructs we need to know to write useful Prolog programs?

Personally, I think it's great that Scryer is lacking certain features, such as a tracer, which I think does not help to reason about Prolog code and would only detract us from finding and using better approaches for reasoning about programs. I think it's great that Scryer does not announce its presence in any way to Prolog programs, in this way programs will become more portable, and this also has an aspect of noble restraint to it.

People who first see Prolog may feel lost, because things that they expect to be present are not present. They ask for more documentation, more examples. But what can we truly say at this point when so much is still unclear? Take for instance as basic a mechanism as term and goal expansion, recently mentioned again in #2604. It's currently completely unclear how term and goal expansions should work so that they satisfy all desiderata mentioned in #2532. Newly available or envisaged features such as library(lambda) and library(diadem) reveal the true extent of the current mechanisms' inadequacy.

On the SICStus Prolog homepage, there is a page titled Coming Features, and the page simply states: "What would you like to see in SICStus Prolog? Please let us know!" For Scryer Prolog, I think a suitable phrasing would be: "What would you like to see in Scryer Prolog? Please help us with your ideas!" Imagine how awesome it would be if tomorrow someone filed an issue outlining exactly how goal and term expansion should ideally behave, or a mechanism whereby different constraint solvers can work together etc.

We also see the opposite of Chesterton's fences (what is the opposite of a fence?): Things that I, at least, always do without even thinking about it. For instance, when I mention Scryer Prolog in Internet discussions, I always try to mention at least one other Prolog system too in a flattering way, out of respect and admiration for other systems and also to encourage more cooperation between systems. We are now in the great position that other new Prolog systems such as Trealla Prolog and ichiban also aim for strong ISO conformance and share also other attractions with Scryer, even though none of them can yet match established Prolog systems such as for example SICStus Prolog in terms of reliability, speed and sophistication.

[hurufu]

I think if we would have an open repository of modules¹ (like CTAN, CPAN, CRAN) that were interoperable between different ISO compliant implementation, then that would foster development of good ideas.

Footnotes

1. Which was also mentioned in "50 years of Prolog" ↩

[jjtolton]

People who first see Prolog may feel lost, because things that they expect to be present are not present. They ask for more documentation, more examples. But what can we truly say at this point when so much is still unclear?

This is one area where I think documentation could really help, and this is exactly what the "fences" are all about: for experienced developers coming to Scryer Prolog AND Prolog, many things are new. We have the ability to contribute ideas and change things! However, we don't know which things are intrinsic to Prolog, what is the difference between Prolog and "pure" Prolog, and which things are new or experimental and could use fresh perspective and input. Unfortunately, we don't have a good way to differentiate which ones are which yet.

I would love it if I could wave a magic wand and do a set difference of the features of "pure" Prolog and Scryer Prolog, so that I can spend time learning the former and contributing to the later, because doing the opposite wastes a lot of time and energy for everyone! 😅

You see the "opposite" of a Chesterton's Fence is a Monkey Ladder (full story), where you don't question something because you falsely identify something as a Chesteron's Fence!

[triska]

Regarding purity in particular, we already have a nice overview!

[hurufu]

For instance, when I mention Scryer Prolog in Internet discussions, I always try to mention at least one other Prolog system too in a flattering way, out of respect and admiration for other systems and also to encourage more cooperation between systems.

This is very important point indeed, actually that comment of yours inspired me to publish my old idea, to create an easy environment to test any Prolog program on as much engines as possible.

Sorry, for shameless self-promotion, but I've started reconciling assorted scripts on my laptop and created https://github.com/hurufu/prolog-docker

In the future I anticipate something like all-prologs -g test myprog.pl and it will start a docker container that in a matter of seconds will run your code on all Prolog implementations.

You can already test it if you use archlinux, I will publish packages in the future (no estimates may be tomorrow or may be next year), I need to decide on a good hosting provider.