Addition of single sided unification and committed choice rules
(=>, named after Picat). Used for several predicates in library(lists)
that are single-moded.
The state of the new Head, Condition => Body rules/clauses is a bit
unclear. Considering how simple they are and how useful they are for at
least some tasks I expect them to stay and do not expect any more
changes to the semantics, possibly excluding the exact exception. If
they prove to be useful enough they are likely to be optimized further.
Docs at SWI-Prolog -- Manual
Enjoy --- Jan
SWI-Prolog Changelog since version 8.3.18
MODIFIED: Use SSU rules for some of the library(lists) predicates:
max_member/2, min_member/2, sum_list/2, max_list/2, min_list/2,
intersection/3, union/3, subset/2 and subtract/3. This causes errors
if the input arguments are non-lists or insufficiently instantiated.
ADDED: Single sided unification with commit clauses using =>.
DOC: get_prolog_backtrace/3: wrong doc for options.
DOC: Fixed “Predicate behaviour and determinism” table. Jan Burse.
FIXED: If we normal incremental re-evaluation considers a monotonic
table valid again we must clear force_reeval to avoid a second
re-evaluation.
CLEANUP: Move implementations from deprecated library(oset) to
library(ordsets) and make library(oset) a thin wrapper.
DOC: del_vertices/3 wrong argument order. Moved LaTeX docs completely
to PlDoc for this library. Nicos Angelopoulos
FIXED: We should not decrement the falsecount on incomplete tables
that are created while reevaluating incremental tables.
FIXED: reevaluation completion may be in a merged SCC. In that case
we must be careful not to propagate falsecount through re-evaluating
nodes by setting the reevaluating status to FALSE after completing
all reevaluated tables.
MODIFIED: extend_goal/3 from library(prolog_code) to return the
goal using call/N in case the callable to extend is insufficiently
instantiated.
TEST: Fixed user defined arithmetic tests. Rick Workman.
ADDED: More statistics/2 keys to SICStus emulation, especially ones
introduced in SICStus 4 and later.
ADDED: library(sockets) to SICStus 4 emulation. The server
socket-related predicates are not emulated yet.
ADDED: Prolog flag max_char_code and updated docs wrt. A is "a".
FIXED: Issue#772: tmp_file/2 not to generate the same name in two
threads.
ADDED: Partial library(sets) to SICStus 4 emulation.
ADDED: ordsets:ord_member/2 to SICStus emulation.
ADDED: More library(lists) predicates to SICStus emulation
remove_dups/2, rev/2, same_length/3, shorter_list/2,
append_length/[3,4], [proper_]prefix_length/3,
[proper_]suffix_length/3, cons/3, last/3, head/2, tail/2,
[proper_]prefix/2, [proper_]suffix/2
FIXED: Possible crash in PL_get_dict_ex() if the dict data contains
a duplicate key.
ADDED: win_module_file_names/1 to enumerate the Windows DLLs used by
the process.
Picat’s single sided unification rules (“pattern matching” and Neng-Fa Zhou refers to them) looks a quite interesting addition! We also considered adding them (or some similar mechanism) to Ciao Prolog but we were a bit unsure about syntax and semantics, specially because we already cover some of their uses (moded rules) using predicate assertions and runtime-checks.
Do you think that this may become a more or less standard Prolog feature (clear and stable syntax and semantics) a-la DCGs? There has been a number of syntax extensions in the past that unfortunately didn’t materialized as a standard, despite being extremely useful. The fact that Neng-Fa’s invention seems useful outside Picat is a good sign (which is not a surprise given that it evolved from B-Prolog and that it looks like a simplified case of Action Rules?).
The subsumes_term/2guarantees the clause head is more generic than the goal term and thus unifying the two does not affect any of the arguments of the goal.
I reread this many times and can not make sense out of this — what is the “goal term”, and what “affecting” does this aim to avoid …
I’m afraid I don’t have a crystal ball We’ll see. I’m quite definitely going to be a serious user. Considering likes and some private discussion I won’t be the only one. I’m sure there are also people furiously opposing this idea. As far as I’m concerned, you don’t have to use this and the impact is rather minimal, so there is not much reason not to support this.
If other Prolog systems start promoting this it will surely help!
It is likely that in due time significant parts of the libraries will be migrated to use SSU rules, turning many silent failures on type errors into errors.
As I am one who does look at the source code for SWI-Prolog for examples, upon reading that I can fully understand how much => has the potential to impact the actual code. Perhaps the version of Prolog just before this should be archived for historical purposes because once => starts to creep in I think many who are not up with the current code will be lost when looking at the new code using =>. When I note archived, I don’t mean be aware that it can be pulled from GitHub but that it should be pulled as a complete and separate set of code and sent to Prolog and Logic Programming Historical Sources Archive.
Unless this turns up serious problems, I can be considered one who likes this change and looks to make use of =>.
The code most recently before => was introduced is IMHO the last version of the SWI-Prolog code that was built using classic Prolog, e.g. syntactic unification (Yes I know SWI-Prolog uses cuts and other things that are not pure but it is mostly classic Prolog that if your read the classic books you should be able to understand). Now with => available, much of the code will change and as time progresses become less familiar to those who can understand Prolog from reading one of the classic books.
When others go to look at the SWI-Prolog source code on GitHub they will now see the use of => and as I.I. Rabi asked
Thus answering questions about => in SWI-Prolog will become a cottage industry. Maybe someone should write a new book for SWI-Prolog so that we can just reference it in the book and not have to answer each question as it arises.
In other words, the version before => started creeping in, which has now changed as you so nicely linked to, was the last classic version and as such should be archived for historical purposes.
Something in 3.8.19 has broken my code that works with 3.8.18.
I will try to isolate the change using binary search on the commits, but it’ll take a while. (I don’t think it’s the Picat-ish changes to lists.pl because the problem shows as a failure deep inside processing a complex data structure and not as throwing an error.)
It is archived, all the source code and the docs are kept in git. You could check out the last commit before => was introduced and fork it for posterity.
And ordsets.pl was modified here (along with the the VM changes that added SSU) - warning: Discourse mangles the URL, so you’ll have to search down the page for ordsets.pl:
So, it should be fairly easy for @EricGT to archive those two library files if he wants. (The other changes in that CL appear to add functionality without changing anything.)
Update: my code broke because of the change of ord_union/2 to use the single-sided unification. I haven’t yet determined whether this subtle change to the semantics is incorrect or my code is incorrect, and it’ll take me a while to figure it out (probably my code is wrong, but there are some other things that aren’t working the way they used to that I need to investigate first).
We’ll see. I’m quite definitely going to be a serious user. Considering likes and some private discussion I won’t be the only one. I’m sure there are also people furiously opposing this idea. As far as I’m concerned, you don’t have to use this and the impact is rather minimal, so there is not much reason not to support this.