Hello,
On bigger Projects, the resulting output executable can be very big for small Solutions.
As this reason, I have look to an alternative, and found one of them:
that I can load external Files, and execute them with Prolog Interpreter or the virtual zip maschine.
and I could get the Code from a Data Base System like MySQL
But the question will be: Can I load such kind of Code into Memory, to unload it at later Time ?
e.g. when the Code is never be relevant or is not need anymore ?
For some of the Programmers is this fact know a GC - gabarge collector.
On bigger Projects, the resulting output executable can be very big for small Solutions.
There should a topic or post on this site that talks about using tell/1 and told/0. The example would look something like
?- tell('fiilename.pl'),goal(1,2,3),told.
such a file can then be loaded with IIRC include/1.
While that is very fast and effective, it is a manual process each time.
For something more persistent consider library(persistency). This requires a bit of learning up front and creating predicates for each clause you want to persist. The first time using it can be hard to grasp but I do use enough that I might be able to help.
For the real bleeding edge there is the SWI-Prolog interface for RocksDB. I know of only 3 of us here that have used it and it is not even alpha quality, only works on Linux, not Windows unless you want to use WSL and is missing so many features beyond the basics that anything you do would be of interest to others here. I think it is great and hope it eventually makes it into the standard build or is at least a build option.
As for using an SQL database for persistence, I am not the one to ask. I do not like that way of solving the impedance mismatch problem. More commonly seen as Object–relational impedance mismatch
If you do any work on this, please coordinate with me. I started extending it but got sidetracked into improving the C++ interface (SWI-cpp.h).
I’m also wondering whether RocksDB or redis, or something else fits better with the use cases I’m envisaging - it might make sense to have an over-all interface that can work with a variety of database-ish “engines”.
Please don’t. I would hate to lose efficiency for the sake of a unified back end. SQL, Redis, RocksDB, RDF and network databases are each so different that it could wind up being the worst of all choices.
Please sorry, the Subject has a little Typo: “…big Projects…small Solutions”.
This is Paradox/Type, so the Admins can replace “small Solutions” with empty gap.
I am not on the state, to foreign function calls (FFC).
I have thinking about the PCE/XPCE to have a own Qt 5 or Delphi VCL like interface implementation.
Because the PCE is very limited (for me).
But like i said: I have to learn more Basic’s about SWIPL.
For me, msys2 is not new to me.
I use the the mingw32, and mingw64 very often with fpc.
But the data base RockDB is new to me.
And I don’t know, if it has SQL facilities, so I don’t need learn C/C++ Library calls (okay, some background in it are useful. But it is not the actual problem in using SQL. Because nearly all SQL-Data base’s has SQL industrial standard).
Not sure what you are after. You can load code from anything that can be turned into a stream, which is basically any source. You can also unload code. For temporary reasoning there is in_temporary_module/3.
As is, there are a few objects that are not subject to GC. These are
functors (name/arity pairs)
predicates, unless in a temporary module. Note that the clauses are subject to GC, but the (small) structure that represents the predicate is not.
modules, again unless it is a temporary one. They may be emptied, but the module structure with the (undefined) predicates it once held remain.
Possibly that will be improved in the future. Notable functors and atoms are united in some systems. We can probably GC modules and predicates if we wanted to.
If there is a lot of data, you can of course consider to use an external DB. Which one depends a lot on the data and what you want to do with it. Typically it is more hassle and slower than using predicates. Still, sometimes needed for scale, communication, persistency, features, etc.