Scryer Prolog: A modern Prolog implementation written mostly in Rust

Is that a result of the Standard and will Scryer follow those footsteps or are we going to see something closer to Mercury?

I really enjoy your channel and indirectly heard a lot of positive things about Scryer, so of course I'm super interested and would prefer if they don't get too stuck on trying to meet the "status quo". The "status quo" has a lot of room for improvement.

You mention you are a contributor to Scryer Prolog. I am curious about the choice of Rust as the implementation language. There are lots of advantages to using Rust but it does not lend itself easily to self referential data structures, linked lists, recursion (tail and non tail recursion) and other things that are found abundantly in Prolog.

I'm wondering if Rust is the easiest language to implement Scryer Prolog in. I would have much preferred using something OCaml (or similar). You would get garbage collection and tail recursion "for free".

What is your opinion on Rust as Scryer's implementation language?

I hadn't considered that. I've always done bespoke analyses for this.

Do you have any suggestions for a practical intro for someone that wants to add Prolog to their toolbox? I'd love to learn not just how to use it but also how to know when to use it.

Prolog uses backtracking search. Backtracking search is quite a good and generic approach. Its not the only approach. Depending on your problem space you can probably totally avoid Prolog.

When I need to solve a CP problem, I typically do one of the following

* Write a simple model in MiniZinc. This is great for experimentation and testing different solvers to see which kind of solver might be suitable (different CP solvers, MIP solvers, etc)

* For some cases or if I need to integrate with a larger system I write my code using a library directly, such as Gecode, Choco, or or-tools. Using a system directly has the benefit that it is possible to program a custom search heuristic, which I find is often very useful for solving problems in practice.

* Write a custom algorithm. Sometimes the right answer is to just write some code solving the problem directly.

I find models written in a modeling language such as MiniZinc or in a traditional Programming language such as C++, Java, or Python to be easier to read and reason about than Prolog programs that solve constraint problems. That is a personal preference, and varies depending on familiarity.

The only reason I could see ReasonML being called "modern" compared to OCaml would be because of the C-like syntax, but that syntax is very old and would be the opposite of "modern" considering age only.

The main issues are:

- The language is untyped. In some ways you get more power because it it untyped but then it becomes more difficult to build/understand/maintain/refactor larger programs

- Debugging the language is quite difficult. There are some really interesting videos/resources at the "Power of Prolog" [1] that give you tips on how to debug. IIRC many of those tips only apply to "pure" Prolog (a certain class of Prolog programs that don't do things like modify global state etc). Essentially you can keep making your Prolog goals more and more general to home into the bug.

But to answer your question, I am not aware of any "ReasonML" equivalent of Prolog. ReasonML just differs on the "surface" level with OCaml. The internal type system, compilation pipeline etc. is all OCaml. ReasonML as a project makes sense for the OCaml ecosystem because OCaml is typed language and has a sophisticated syntax. Prolog's syntax is SUPER simple. So its not really possible to have too much of a different take on syntax when it comes to Prolog.

In Prolog essentially we have

Head :- Body

This could become transformed to:

if Body then Head

In other words, there is not much room for syntax innovation as there existed in OCaml when ReasonML came out as alternate (surface) syntax.

You have other languages like Mercury which try to be a typed version of Prolog. They are significantly different languages in their own right so I wouldn't classify them in the "ReasonML" equivalent category.

[1] https://www.metalevel.at/prolog by Triska (I highly recommend this resource)

Compiling prolog to abstract code and running it on a VM written in Rust? Yeah its probably close to the language's target use cases of Rust but it lets people see if such functionality is reusable as a library (in this case found out its not) and how its implemented.

I don't know what's with all the Rust hate these days. It's just another language nothing to get fired up about a tag line appended to the title.

https://github.com/mthom/scryer-prolog/blob/master/src/lib/c...

Note that many of these predicates are only wrappers for internal implementations that use the Rust crates. In fact, these existing Rust crates (notably ring) made it especially easy and convenient to add this functionality. library(sgml) is another example of this approach:

https://github.com/mthom/scryer-prolog/blob/master/src/lib/s...

On a general note, it is often an advantage to implement functionality in Prolog, because it helps to improve robustness and efficiency of the underlying engine, and makes changes easier.

A Prolog meta-interpreter is a Prolog program that interprets Prolog programs. With this facility, you can dynamically extend your programs, by reading code and executing it as if it were part of the original program. But not only that, you can also reason about it, and execute it in different ways than a regular Prolog engine would do it. You can analyze it, and execute only safe parts. You can remove fragments, and show explanations why specific phenomena occur. You can debug it declaratively by constructing generalizations and specializations. You can add features to the language that are not present in its actual implementation, but only in the programs you interpret.

No other programming language provides this ability to such an extreme extent as Prolog. For example, how much C++ code would it take to write an interpreter for a sensible subset of C++? How much Lisp code would it take to interpret the most essential aspects of Lisp? It takes only 3 lines of Prolog code to interpret the essence of Prolog.

Most programmers may currently not "miss" this ability, because what they think of when they think of a "program" is in comparison quite static: The idea that they could interpret external code dynamically as part of their programs is alien to them because the languages they are using either does not allow it, or only allows it in a sense "blindly", by not truly looking into the code and interpreting it in flexible ways, or by making the analysis of given code too hard. Yet, the ability to conveniently adapt and augment the logic of an existing program is a fundamental necessity for truly general and flexible programs that must dynamically take into account changing requirements.

Prolog is a declarative, logic language - we tell the compiler what the goal is, and the compiler works out the steps to take in order to complete that goal.

  :- use_module(library(clpfd)).

  valid(Num) :-
      Num in 100..150,
      Num mod 5 #= 0,
      label([Num]).


  # Python
  def valid(num):
    return (num in range(100, 151)) and (num % 5 == 0)

len(some_list) in Python can tell you the length of a list. length(Somelist, Len) in Prolog can tell you the length of a list, check if a list is the given length, generate a list of a specified length containing placeholders, or generate lists of increasing lengths containing placeholders. All languages can do what all other languages can do with enough effort; Prolog brings to the foreground relations and constraints and patterns instead of state manipulation and variable assignment.

Since Prolog is a logic-based and declarative programming language, if you're dealing with goal reduction or backwards chaining, then Prolog is a excellent fit and will probably be easier to both write and maintain compared to other languages. Theorem proving, automated scheduling and querying data stores are also excellent use cases for Prolog and Prolog-like languages.

For example, "I already have Machines A and B with control system S, but now I want to add Machines C and D from another vendor and I need the control systems to work together, what are my options?"

It would query the configuration rules about products and compatibility with the 'knows' that you tell it and find options for the 'unknowns' and tell you something like, "then you can buy X, Y or Z, but if you chose Z you also need to buy an external temperature control from the Foobar 800 series with the D-bus adapter".

In practice, it is often even more complex.

Logic programming is great for this, and I find that using it in small subsystems of a larger application is a super powerful tool.

For interactive systems, a fast implementation is really important. The CLP aspects of Scryer Prolog would also be very helpful.

For example, it is very useful for e.g. generating test cases to hit every state transition in a complex business process state diagram.

There are numerous examples where Prolog itself was used, for instance, every instance of Windows NT contained a Prolog implementation to handle the details of network configuration.

    items = fetch_list_from_db()
    for item in items:
      if item.match(param):
         ..
      elif item.whatever > param2 || item.override:
         ..
      else:
         some_default_behavior()
    return custom_sort_thing(results)

Prolog allows me to very easily state these rules in a way others can understand at a glance and keep them separate from the operational code. Best of it all, it solves for all possible answers (or all inputs for a given answer) without implicitly stating very much looping or recursion - even less so than functional languages in some cases.

EDIT: IMHO one should learn it just to get introduced into the mindset of declarative programming. You can implement a sufficiently fast and complete prolog easily in any language if that allows for a clearer solution to a specific problem than explicit specification of control flow.

Though I would say it’s easier that C++ to deal with and would expect this would help it win a larger share in systems programming. Eventually

https://4e6.github.io/firefox-lang-stats/

What makes you think this is the case? That's not my impression at all (for reference, I develop software in Rust professionally).