Can you tell us more about these libraries and their functionality.
My idea is basically that deep down it can be a hybrid of strings/3
FFI and the Prolog ISO knowledge bases, since strings/3 is multifile
but not necessarily dynamic. Namely the primary use is as a static
predicate, and for example use consult/1 or use_module/1 can even
load strings/3 definitions on demand. It basically utilizes the multifile
feature as defined in the ISO core standard. So it is a solution
that is portable, would work everywhere where you find a ISO
processor, and currently it requires also format/[2,3] and memory
streams to do the reification. There is a PIP now for format[2,3],
but I don’t see a PIP for memory streams yet:
Draft PIP-0110-format
https://discourse.prolog-lang.org/t/draft-pip-0110-format/170Draft PIP-???-memory
https://discourse.prolog-lang.org/t/draft-pip-???-format/???
What is possible with the strings/3 approach to make a hybrid or
even drop strings/3 consulted from some Prolog texts altogether,
by tapping into some FFI. Namely you would to:
/**
* strings(K, L, V):
* The predicate succeeds in V with the value for the key K and the local L.
*/
% strings(+Atom, +Atom, -Atom)
:- multifile strings/3
strings(K, L, V) :-
ffi_lookup_string(K, L, V).
You can mixin multiple resource bundle oracles via FFIs, since
the predicate is defined using the ISO core multifile directive.
The strings/3 predicate works with first argument indexing
in primitive Prolog systems already quite well, I use compressed
atomified key such as ‘time.fields’. It works a little better with
more advanced Prolog systems that have multi argument indexing,
since it would then also index the local. The challenge for a FFI is
to retain these Prolog traits, give ffi_lookup_string/3 a similar nice
performance profile, and extensibility as found via consult/1.