Can I call use_module/1 with a module created using PL_new_module?

Help!
1

I have the following C code, which creates two modules, m1 and m2, and attempts to call use_module/1 to import m2 into m1:

// main.c
#include <SWI-Prolog.h>
#include <stdio.h>

int main(int argc, char **argv) {
    // Initialize Prolog
    PL_initialise(1, (char*[]){ argv[0] });

    // Create modules m1 and m2
    module_t m1 = PL_new_module(PL_new_atom("module_1"));
    module_t m2 = PL_new_module(PL_new_atom("module_2"));

    // Fetch and store m2's name inside m2_name_t
    // (Reusing the atom created above gives the same result.
    // This is just to show how the error actually happens in my real code.)
    atom_t m2_name_a = PL_module_name(m2);
    term_t m2_name_t = PL_new_term_ref();
    PL_put_atom(m2_name_t, m2_name_a);

    // Create a term for "use_module(m2_name_t)"
    term_t use_module_f = PL_new_functor(PL_new_atom("use_module"), 1);
    term_t use_module_t = PL_new_term_ref();
    PL_cons_functor(use_module_t, use_module_f, m2_name_t);

    // Call "use_module(m2_name_t)" inside m1
    PL_call(use_module_t, m1);

    // Fetch the exception generated by PL_call
    char *exception_msg;
    term_t exception = PL_exception(0);
    PL_get_chars(exception, &exception_msg, CVT_WRITE | REP_UTF8 | BUF_MALLOC);

    puts(exception_msg); // Prints "error(existence_error(source_sink,module_2),_)"
}

CMake File:

cmake_minimum_required(VERSION 3.10)

project(test_use_module C)

set(CMAKE_C_STANDARD              99)
set(CMAKE_C_STANDARD_REQUIRED     ON)

add_executable(test_use_module main.c)

find_package(SWIPL REQUIRED)
target_link_libraries(test_use_module PRIVATE swipl::libswipl)

As you can see, this code raises an error(existence_error(source_sink,module_2),_) exception. This does not happen when importing a traditional file-based module, so it looks like use_module/1 does not handle modules created with PL_new_module properly.

Is this intentional? Am I doing something wrong?

Thanks in advance.

I’m using SWI-Prolog version 9.3.9 for x86_64-linux.

2

The argument of use_module/1 is a file, not the module name. If you create a module dynamically, you can export from it using export/1 and you can import into another module using import/1. All this is barely used though. What do you really want to achieve?

1 Like
3

Thanks for the reply. I’ll give it a try, but in the meantime, I agree it would be wise to explain what I’m trying to do.

I’m using C and SWI-Prolog to create something akin to a package manager or a dependency resolution system. Throughout my program’s runtime, it loads dependency rules from build files and stores them inside “database” namespaces (i.e., modules). Think of rules like “Chromium needs libxml2” or “pulseaudio-daemon cannot be installed alongside pipewire-daemon.”

Eventually, I want to spawn temporary “query” namespaces to prescribe dependencies requested by the user (e.g., “give me Chromium and VLC”) and probe for solutions or conflicts. It’s important that this step happens inside a different context than the database because later on (or maybe even at the same time), the program will open more queries with different requirements, and I don’t want queries to contaminate each other.

What doesn’t change is that all these queries must import the database, which is why I was trying to call use_module/1 on a module created with PL_new_module.

However, that’s not the only issue I’ve run into. I’m also concerned about memory leaks from creating too many queries, and I can’t find a C function or a Prolog predicate to clean up modules.

The reason I decided to use modules is the signature of PL_assert(term_t t, module_t m), which led me to think that modules would be the easiest way to separate database rules from query prescriptions. Truth be told, I’m a Prolog noob, and I’m not sure if I’m going the right way.

4

As said, use_module/1 is for loading files. For your scenario, SWI-Prolog -- Dynamic importing using import modules might be a solution.

Modules cannot be deleted and are not garbage collected in the current system. Best you can do with an ordinary module is to abolish/1 all its predicates. There is however a notion of temporary modules. See in_temporary_module/3

Neither do I. Queries do not leak memory. Dynamic predicates can be updated and do not leak memory. Dynamic predicates can have multiple versions using thread_local/1. Typically, that is enough. Otherwise, predicates and modules are not reclaimed (except for temporary modules) and can only be made “empty”.

I understand you need a database with packages and the rules that describe their dependencies and conflicts. At first sight I’d say that on top of that you have queries that resolve certain package combinations. I could imagine you want a service to which you upload your current package selection and asks questions about it. I’d consider using threads (or engines), load the package selection into a thread_local/1 predicate and run your queries.

I’d consider avoiding embedding into C(++) if you can. If you can’t, don’t try to make all kinds of detailed changes and queries from C(++). Instead, ask high level queries and do the low level stuff in Prolog. But again, the details depend on your overall goals. Is this supposed to be a web service? A local program? What else?

1 Like
5

At the highest level, I’m going to make a GUI application either in C++ or Python using Qt, or in JavaScript/HTML using Electron.

I don’t know which option to choose yet, so I’m starting with a shared C library to handle the underlying logic, which can be loaded from any of these languages.

I chose to embed Prolog because I had issues interacting with it through stdin/stdout and because I personally avoid dealing with inter-process communication when embedding is an option.

That’s pretty much what I’m going for. The core logic is written in Prolog in a way that all that’s left to do is:

  1. Assert package candidate and the dependency between them, creating a database.
  2. Assert user-specified dependency, creating a query.
  3. Query the selected/1 and conflicted/1 predicates, creating the final solution.

However, preventing queries from leaking facts back into their associated database, along with reclaiming the resources taken by these queries, are hard requirements for my application. Discarding databases would be nice too, but I don’t think it will happen often enough to justify putting much thought into it.

(Reporting regarding import/1 and export/1)

I’ve tried using import/1 and export/1, which work for importing and exporting predicates from modules created with PL_new_module. Unfortunately, a predicate imported from module X into module Y appears to leak back into module X when asserted into module Y using PL_assert.

If I understand correctly, from your reply and my test, I should instead be using in_temporary_module/3 or thread_local/1. Given the context I provided, do you feel one option is better suited than the other for my use case? Or are my requirements too strict and hindering more ideal approaches?

6

Thanks for the clarification. As for the overall design, I’d first decide on the platform. Notably if the final platform will be Python, Janus provides a great high level interface to SWI-Prolog (and XSB Prolog). If you go C(++), I’d go for the excellent C++ binding by @peter.ludemann that is the currently bundled one. I’m not sure about the JavaScript approach. You can use the WASM version, which has a quite nice high level binding, but the WASM version is over 10 times slower than the naive version. Possibly we should develop a JavaScript native interface that is functionally equivalent to the WASM interface and can be used with Node.js?

Given this overall design I’d answer a query by

  1. Create a temporary module
  2. Add the background knowledge as import modules to this module
  3. Add your facts to this module
  4. Run your query.

But again, asserting to an imported predicate asserts to the thing you import as you noticed. So, you need the background knowledge and case knowledge and then use a predicate on top of these to combine them. That also holds if you use thread_local/1 predicates.

One final way around is to store all background knowledge as dynamic predicates and use snapshot/1. Inside the snapshot you can modify the background knowledge (adding, deleting) and run your query. The changes are only visible inside the snapshot. That is a quite simple design that should work pretty well if the change set is small compared to the background set. It is relatively new though and not extremely thoroughly tested.

All three approaches should be valid. With some care it should be feasible to write a little wrapper that has the same external API regardless of this choice.

You probably want to use tabling in your reasoning. That avoids recomputation, avoids cycles and provides sound negation.

Success and keep us posted!

7

I’ve read the link you shared and reached a conclusion.

Unfortunately, I can’t use thread_local/1 because it implies volatile/1, which would prevent my predicates from being saved in a state file for debugging.

However, snapshot/1 accomplishes what I’m looking for, and this nifty website even pulled up some good examples:

The only downside is that, unlike with modules, I can’t keep a snapshot “open” and progressively assert new prescriptions one by one. Instead, I’ll have to store them manually and then feed them all at once when I want to call selected or conflicted, but that’s simple enough to solve.

I made a quick program to test the feature, and everything seems to work, even qsave_program/1:

:- dynamic song/1.

print_list([]).
print_list([H])   :- write(H), nl.
print_list([H|T]) :- write(H), write(", "), print_list(T).

print_all_songs :-
	findall(S, song(S), Songs),
	print_list(Songs).

song("Sultans Of Swing").

:- snapshot((
	assert(song("Money For Nothing")),
	qsave_program("query"),
	% Print "Sultans Of Swing, Money For Nothing"
	print_all_songs
)).

qsave_program("database").
% Print "Sultans Of Swing"
:- print_all_songs.

I’m sold on that option!

I’m not sure if tabling (or, to my uninformed understanding, memoization) would help. The actual logic is quite susceptible to backtracking (i.e., going back and downgrading one or several package versions on conflict to see if a working solution comes up), so a candidate selected at one point could become invalid later on.

Or maybe it would actually help - I need to read up on it and try it.

Many thanks, Jan. It’s a complex project that has been in the works and under research on and off for six years, but now that I’ve found Prolog and your help, I’m starting to see it all come together.

If something does come out of it, I’ll make sure to spread the news and extend my thanks to the SWI-Prolog community. :wink:

8

Not sure why that bothers you. I’d not rely on qsave_program/2 for such tasks. Possibly on just saving the predicate itself using e.g., listing/1.

Note that snapshots basically operate in threads, isolating the changes from other threads. These rules also apply to engines though. Unfortunately I’m afraid that an engine cannot yield from inside a snapshot. That should be fixable …

Success!