Glad to hear that Single Sided Unification rules is not set in stone at this point.
While I don’t have a name to propose at this time, here are some of the thoughts I have when contemplating a name. I am writing this so that others can have a litmus test to see if their thoughts are similar to others, or at least mine at the moment.
Note: I have not used Picat or even used => in SWI-Prolog yet so this is all based on just what I have read.
If we exclude the backtrackable rule (?=>) for now and only consider the non-backtrackable rule (=>) then the properties to consider are
- Is a pattern matching (Pattern matching programming languages)
- Is not backtracking which I will take to mean that it is either determinate or fails.
- Is not unification so is one way, thus the syntax for the operator
=>. - Allows conditions on the left of the operator. While it does remind me of forward chaining, as Jan W. notes,
=>is not forward chaining. I wish I had practical experience with something similar in another programming language so that I can relate but do not. The only thing I know of that adds some clarity to adding conditions on the left of the operator is (ref)
p(V1,V2,...,Vn) :-
Pattern = p(A1,A2,...,An),
Args = p(V1,V2,...,Vn),
subsumes_term(Pattern, Args),
Pattern = Args,
Guard,
!,
Body.
- Pattern matching also reminds me of Algebraic Data Types but I don’t know how this relates to
=>but understanding the relation between Algebraic Data Types and=>could be used as a discriminator for understanding. - This also reminds me of Modus ponens. Something more to be used as a discriminator for understanding.
- The description for Picat uses the phrase Implicit pattern-matching but does the adjective Implicit have meaning with the SWI-Prolog operator
=>? - Is like a rabbit hole in that once you use
=>for a predicate or rule (which I am using liberally at present) you are committed to using it for the remainder of the predicate or rule. (ref)
A predicate either uses :-/2 for all its clauses or =>/2 . Mixing is not allowed and raises a permission error for a clause that does not use the same neck as the first clause.
- Results in errors instead of silent failures. (ref). Which IMHO takes us out of the land of logic and into the land of procedural programming and possibly functional programming.
Unlike Picat, it is an error if no clause matches.
At present the idea that keeps popping into my head about this is F# pattern matching. When I get some time I will do comparisons as test cases but this is not even on the short list.
The other thing that keeps popping into my head about this is that one should look at ways to track the errors yet continue processing, think monads. In my mind once one starts using the SWI-Prolog operator => they are going to want a way to work with the errors that does not kill the process.
In F# the answer is Railway Oriented Programming, in Prolog the closest thing I know is DCGs or open list.
If others are wondering why I seem to have a fixation with a name for this operator it is that if you don’t have a meaningful and easily searchable name for something, it makes it much harder to learn about it and if you can’t learn about something because you can not find information about something, then it will be lost to the sands of time. Have you ever tried to search for the . operator when first learning about object-oriented modules, knowing the name makes it so much easier.