Reconsult about sandbox HOT 15 CLOSED

You can compare with GNU Prolog, what one gets there.
The ISO core standard sections is 8.9.1 asserta/1
8.9.2 assertz/1 . The example from the ISO core standard
is assertz((foo ....), which would dynamically add foo/0.

from sandbox.

Oho, its even worse. assertz/1 doesn't work at all. When
trying to retrieve the facts via normal Prolog execution.
Is it required to do dynamic/1 ? I am confused.

from sandbox.

P.S.: I am fully aware that these details might take months if
not years. I just wanted to document my findings. With dynamic
database a lot of examples become available. For example NLP.
I will do some more testing, maybe dynamic/1 is required.

Natural Language Processing Techniques in Prolog
Patrick Blackburn and Kristina Striegnitz
http://cs.union.edu/~striegnk/courses/nlp-with-prolog/html/index.html

from sandbox.

Ok, I tried the dynamic/1 directive, it didn't change anything:

from sandbox.

I guess it stopped working when we added threads. I'll check it. Thanks for the report.

from sandbox.

Predicates are fine. It's a problem of the sandbox. When you run a goal, the session restarts, loads the program and runs the goal.

from sandbox.

from sandbox.

SWISH has the same problem. Thats a little strange:

from sandbox.

But with Tau Prolog there might be less problems. You could
keep the session in the browser. Also some of the NLP examples
might go on that you run multiple queries and have a session state.
Thats actually the natural expectation, and not what SWISH does.

from sandbox.

The Webassembly Prototype of SWI-Prolog can do it:
http://demos.rlaanemets.com/swi-prolog-wasm/example/

from sandbox.

In the sandbox, we consult the program each time the user runs a goal. If we don't restart the session, the clauses of the predicates will be duplicated.

We should put explicit options to load programs and goals, ask for answers and restart the session.

from sandbox.

You could reset the sesssion when the end-user presses the Browser
reload button. But otherwise the session should persists.
Also the program should not be consulted but reconsulted. In

a reconsult clauses don't get duplicated. You could reconsult
when the program text field was changed by the enduser. So
it would be a toplevel with an automatic make/0. Here is an

example where you see that reconsult doesn't duplicate
clauses, I start with this file:

I am consulting an running it in SWI7:

Now I change the file:

And I ask SWI7 for make/0 and rerun:

The documentation says consult, but consult always means reconsult:
http://www.swi-prolog.org/pldoc/doc_for?object=make/0

from sandbox.

The session and the consulted code should be 2 different states.
In the above this is easy, really new predicates asserted would go
into the session which is the pseudo module user, and the code

was named foo. In Tau Prolog you don't have a name for the program.
But since it is a program, and not ?- [user], it has an independent state,
which can be reconsulted. Except if you consider it a ?- [user]. But

you could consider it the single SWISH notebook, hence a program.

from sandbox.

Take your time, this can be kind of difficult under the hood. There
was a many decades long evolution of Prolog systems concerning
reconsult. Reconsult gets tricky when multifile predicates are involved.

In as far the reconsult policy, also in Prolog systems such as SWI7
has slightly changed. Typically you consider all predicates as multifile,
and for changed files you first remove the clauses which were consulted

from the changed file. And you do not really abolish predicates during
reconsult, only if they get really empty. This is to allow reconsult also
of multifile predicates. The SWI7 toplevel doesn't do it, but I guess the

SWI7 consult works like this, and I have also implemented it like that
in my system. Even in SWI7 there were still changes to this mechanism
over the last years, and SWI7 adds a lot of tracking information to their

clauses, thats why they can report -1 clause here:

In my system I am not going that far... :-( :-)

from sandbox.

I'll add information about the parsed program (#52).

from sandbox.