Very interesting, thank you for sharing this!

Knowing the history of Prolog can be very useful to make progress in this area, because quite often, progress in this area means returning to what earlier systems already did.

For instance, already in the very first Prolog system, Marseille Prolog, a string like "hello" was treated as a list of characters, i.e., [h,e,l,l,o]. This was great for usability, as one would expect from a language that was designed for natural language processing.

Later systems switched this to lists of character codes, denoting code points in the used encoding. For instance, when using ASCII or one of its supersets, "hello" would then mean [104,101,108,108,111], which is much less readable in answers.

Still other systems introduced their own ad hoc types that were not lists and therefore could not be handled with Prolog's built-in mechanisms for reasoning about lists, most notably Definite Clause Grammars (DCGs), and thus even required their own dedicated and usually moded predicates for reasoning about them, thereby severely limiting their generality while increasing the complexity of application code.

Only the most recent Prolog systems, such as Tau Prolog and Scryer Prolog, are now doing what Marseille Prolog did, namely treating strings as lists of characters, and are also beginning to combine this with efficient internal representations to finally get all advantages at once: usability, generality, simplicity and efficiency.

Type checks are another example where Prolog systems are now going back to the solid foundations of Marseille Prolog, after decades of errands. For instance, to preserve monotonicity of Prolog programs, type checks must raise instantiation errors or delay the check if no decision can be made, e.g., the following would be a logically well-justified response because X can still become an integer:

    ?- integer(X).
    ERROR: Arguments are not sufficiently instantiated

This is also what Marseille Prolog did, for very solid reasons that were very clearly outlined by Battani and Meloni. Prolog vendors soon found out that Prolog systems would sell better to customers who did not care about logical properties if such — to them strange and likely worrying — errors were not shown, and opted to instead answer such queries with silent failure, which is logically wrong and prevents for example declarative debugging techniques and different execution strategies such as iterative deepening:

    ?- integer(X).
    false.

Now, logically sound type tests are appearing again in Prolog systems. For instance, Scryer Prolog already ships with library(si), where we have:

    ?- integer_si(X).
       caught: error(instantiation_error,functor/3)

This is correct: We get an instantiation error, because no definite answer can be made at this point. X can become an integer, or a term that is not an integer, so answering either "yes" or "no" would not be appropriate, because the type of X cannot yet be determined.

A third example for this are constraints like dif/2, which is a relation with very desirable logical properties, denoting syntactic disequality of terms, i.e., it is true if and only if its arguments are different, and it delays checks until a definite decision can be made. This was present even in the predecessor of Marseille Prolog, Prolog 0, and then treated at best as a strange curiosity or not present at all in many later systems before it became more widely available again.

Using constraints also enables an even more elegant solution for the above cases. For instance, using CLP(ℤ), constraint logic programming over integers, we can constrain a variable to integers in the most general way:

    ?- X in inf..sup.
    X in inf..sup.

Another very interesting aspect is the commercial context in which these systems were developed. There was a lot of money involved, Prolog vendors would give you a licence for thousands and tens of thousands of dollars, and still do today. Not that long ago, when you did a research project as a university student in cooperation with one of the Prolog vendors, the vendor would personally fly over and hand you a hardcopy of the system manual. Then, after you finished the project, the vendor would visit you again to take away the manual.