I’m using: SWI-Prolog version 9.2.9 which I installed from the stable Ubuntu repository. I’m on Linux Mint.
When I simply run swipl and type:
use_module(library(json)).
I’m informed that it doesn’t exist. The docs still say it’s there. Has this been replaced by something else?
In versions prior to 10.0, it is library(http/json). JSON support started in the http package, but has been moved to its own package. library(http/json) also works in > 10.0, though it prints a deprecation message there.
I was asking about library(json). The docs says it includes predicates like json_read and json_write. Is that in a separately installed pack? Should I consider it obsolete?
Apparently I was not clear 
Let me try again. Up to version 10, JSON support (json_read/2, etc.) was provided by library(http/json). This is not library(http/http_json), which contains predicates that simplify JSON handling with HTTP using such as, reply_json/1.
Version 10 introduced a new package called json and the library(http/json) was moved to library(json). So, wherever the current docs talk about library(json), just use library(http/json). The predicates are the same.
So no, package json is not obsolete, but introduced in version 10. With package we refer to extensions bundled with the main source (as GIT submodules). Packages may or may not be activated while compiling the system from source. I.e., the sources allow selecting a set of packages so you can opt for a minimal system, the whole lot or something in between.
Thank You! I get it now and should have got that from your previous post. I think what tripped me up is that I just installed the stable version a few days ago and got confused about versions. I do agree that the predicates in what will be library(json) don’t necessarily involve http.
It does bring up another question. I think it’s related but if it is not considered so, go ahead and move it to a new topic. When will version 10 be in the stable Ubuntu ppa?
That is a little hard. The problem is that stable Ubuntu does not yet support SDL3. That is in the non-LTS releases, so it will be in LTS 26.04 I assume. We cannot provide a full PPA distribution for older Ubuntu (reasonably).
You can build from source, you can use the PPAs for the development series (current devel will be merged into 10.0.1 as all changes deal with portability, stricter C standard compliance and similar changes (no Prolog incompatibilities). Or you can use the flatpak (also only for the SWI-Prolog development series).
Thanks, I can wait. I just thought I’d use library(json) instead of library(http/json) if it’s a simple upgrade, but I definitely don’t require version 10. What’s in the stable ppa works fine.
It appears that something like this is appearing with dcg_basics also. On version 9.2.9, when using:
use_module(library(dcg_basics)).
I’m informed that it doesn’t exist. But, it’s even stranger when I use:
use_module(library(http/dcg_basics)).
I’m told that it was moved to library(dcg_basics) but it still loads. So I guess that means that it was moved in a subsequent version. Still confusing. I guess until I get to version 10, I’ll probably keep running into these things.
This is weird, it has been for a long while
library(dcg/basics)
So, forward slash, not underscore. As documented here: SWI-Prolog -- library(dcg/basics): Various general DCG utilities
The message you get that it was moved is indeed confusing
Thanks, Boris. I didn’t notice that the file name had been changed from dcg_basics to basics. The message did actually say it was moved to library(dcg/basics) which does in fact load.
Whether it’s loaded as http/dcg_basics or dcg/basics, listing(integer) still shows it’s in the dcg_basics module. I’m sure this is for backward compatibility.
Yes, this is correct. The name of the module as defined in its :- module directive is dcg_basics. I now remember I have wondered about it.
The dcg/basics is in fact a path, dcg is a folder containing a file basics.pl. This is inside /library where it can be located when you do use_module(library(...)).
What I have wondered is what liberties I can take in naming my modules and files. It seems that the file name and the module name don’t have to be in any specific relation to each other; but the module names loaded at any time must be globally unique? This is what I found in the docs:
Typically, the name of a module is the same as the name of the file by which it is defined without the filename extension, but this naming is not enforced. Modules are organised in a single and flat namespace and therefore module names must be chosen with some care to avoid conflicts. As we will see, typical applications of the module system rarely use the name of a module explicitly in the source text.
My guess is that for purposes of locating the source, you need a path that can be resolved by file_search_path/2 in your use_module directive; but for the purpose of having a unique module name, you need to come up with a specific enough name to use inside the module directive.
All true. I think there is room for criticism This however was invented by Quintus in the late 80s/early 90s and got from there in SICStus, Ciao, YAP, SWI-Prolog and probably a few more. My rule of thumb for the library is to use X for library(X) and D_X for library(D/X). Unfortunately the history did some tricks …
Important it that the module system is designed to avoid the need for using the module name itself. Calling use_module/1,2 or autoload/1,2 adds all or a selected set of predicates to the namespace of the importing module. For the /1 versions this is a weak import, for the /2 a normal import. The difference is that a local definition conflicts with a /2 import and overrules (hides) a /1 import. The notion of weak/strong imports is AFAIK a SWI-Prolog extension.
This works fine as long as you do not need two predicates with the same name from two different modules. In that case you have the SWI-Prolog/YAP extension to use Name/Arity as LocalName, e.g.,
:- use_module(library(lists), [ last/2 as list_last ]).
The other disadvantage is that reading the code does not tell you were the predicates come from. You need a good editor for that such as GNU-Emacs using sweep mode or the bundled PceEmacs editor. The LSP server by @jamesnvc probably solves the problem for most modern editors. Good hints to find things are
?- edit(Name).
?- explain(Name).
The first will try to locate the object by name and start the editor or provides a menu if there are multiple matches. The second will print found objects and reference locations to the terminal. If you use version 10 swipl-win, these are printed as Ctrl-clickable links. Both edit/1 and explain/1 also take more complete references such as member/2 or lists:member, lists:member/2, member(_,_), etc.