Assertz in SWISH

I am using swish

assertz/1 does not seem to work. Could you confirm?

:- dynamic p/1.
?- assertz(p(a)).
true
?- p(a).
false

Works fine for me:
a

It works with swipl but not with swish.

The picture above is from swish, not swipl.

ok sorry. there is something I misunderstand then. The use of ?- in the prolog program. I ran assertz(p(a)) as a query.

usually you would use assert/1 within a predicate, something like:

store_my_value(Value) :-
   assert(value(Value)).

do_something_with_values :-
   value(V), 
   format('got value ~w',[V]).

remove_values :-
   retractall(value(_)).

then, you could query like this:

?- store_my_value(a), store_my_value(b), do_something_with_values.
got value a
true ;
got value b
true.

?- remove_values, do_something_with_values .
false.

Thank you for your patience.

What am I doing wrong ?

image

ohh I think you’re right, assert is limited within swish programs (but for some reason allowed as a query). I don’t use swish much, perhaps someone can help out.

Yes that was my conclusion as well :slight_smile:

I hope that this limitation will be lifted soon.

In fact I want to use swish because It is really a great tool for teaching Prolog (I teach an introductory course on Prolog).

The reason is that in SWISH, each query is isolated from all others. So, the assert and lookup query are executed in isolated environments. Using the dynamic database works fine, but it must all be a activity that results from the same query.

1 Like

Thank you Jan for your answer.
Are there any plans to change this? It is difficult to show the value of assertz/1 to students with this behavior.

Not really. There is also a great advantage in not having persistent state. Besides making resource management in the server a lot simpler it guarantees that computations repeat consistently.

As for students, just create examples where a single query both asserts and uses the clauses. Besides the fact that most Prolog programmers think you should not teach the dynamic database at all :slight_smile: I think there surely is value in the dynamic database, mostly when using Prolog as deductive database (often with tabling) or for ILP (Inductive logic programming) or other techniques where rules and/or facts are generated dynamically.

My aim was to reproduce the behavior of a relational database with query and updates and also extend the database with some deductive capabilities.
But I got your point. Thank you.

1 Like

I have been droning on about this on this forum and here I go again :slight_smile:

(SWI-)Prolog is not a replacement for a relational database without a lot of additional effort, and that’s a pity, but it is how it is. The opposite is also true, a relational database is a terrible replacement for a high-level general purpose language like SWI-Prolog. Of course experience with both is a great exercise.

What makes you say so? Surely it is a different beast with very different properties. There are a lot of applications that could perfectly well use SWI-Prolog for storing and querying data though. The lot of additional effort is typically setting up some way to access it and setting up some way to make the data persistent (if that is required).

Take a SWISH installation with a small bridge to library(persistency) and you’ve got a database with some cute properties such as being able to write and share programs that are close to the data and access through HTTP from several languages. I have used that setup a couple of times.

You can also take TerminusDB, which runs in SWI-Prolog :slight_smile: Yes, it does confirm your claim that it is a lot of work :slight_smile:

2 Likes

Is that possible with the online SWISH or are you implying a different instance?

I would like to use library(persistency) with SWISH online for demonstrating some examples. In particular the loading of an existing persistency file, updating the facts with assert, then saving the file. I think this would also dove tail in with the desires of @albangabillon

If it can’t be done because of the sandbox, perhaps a special predicate that is safe for the sandbox that loads the persistency file.

I don’t see it that way. When I think of a relational database I also think of it bringing along SQL because that is how many people are introduced to relational databases and access the data in them.

If one removes the SQL baggage and replaces that with Prolog queries life is better. As you know I am a fan of library(persistency) and data normalization and while I do know SQL, given the choice I would much rather use Prolog. Also when I use Prolog with normalized data like an SQL database I don’t pull the data from an SQL database but use library(persistency) instead. While I have not tried moving the persisted data into an SQL database, from my experience with using Prolog with ODBC it does not seem like a road block or even a lot of additional effort.

One point of note with library(persistency) that seems like a pit fall until you are aware of it is that Prolog terms like blobs don’t persist until they are converted to atoms.


EDIT

For the sake of completeness: Introductory Prolog tutorial for SQL programmers on Swish

Note: I don’t do Prolog queries exactly the same as in the tutorial (think refactoring) but many of the underlying concepts from Finding all Solutions to a Goal are essential.

The public SWISH instance is by design stateless. If you want to use it as a statefull database you need to write a library that provides the necessary persistency and declare the interface of that library as safe (possibly with checks and balances such as testing the user is authorized).

Public SWISH has a notion of a data source

1 Like

What are your thoughts on using something like prolog/0 or interactor/0 or a new predicate to open a new REPL in online SWISH that can hold state and accept assert/0 while it is running and then when the REPL ends the state is destroyed. I am thinking something like Windows Sandbox that creates an isolated sandbox that can be updated but when the sandbox is closed all in the sand box is destroyed.

Well you answered your question in the next sentence.

Absolutely. Those applications probably don’t need a relational database (Oracle/Postgres/MariaDB) anyway, and probably don’t benefit from using SQL.

This is a very important point that I have also made before: based on my experience, Prolog (Datalog) is a far superior data query language than SQL.

I have my doubts about TerminusDB in terms of what problems it is supposed to solve. But I haven’t had the chance to evaluate it in practice so my opinion is useless.

The only reason I made my off-hand (and probably unnecessary) comment: in the long term, technology adoption is rather hampered by promising too much upfront and failing to deliver. This is my opinion on the matter.

PS: I definitely wasn’t attempting to troll or flame but it seems this is how it turned out, sorry. I will not delete stuff so that it doesn’t look like I am trying to hide something.