Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsult #5

Closed
ghost opened this issue Jul 17, 2018 · 15 comments
Closed

Reconsult #5

ghost opened this issue Jul 17, 2018 · 15 comments
Assignees

Comments

@ghost
Copy link

ghost commented Jul 17, 2018

According to the ISO core standard, it is allowed to dynamically
create clauses of a predicate, even if it doesn't have a dynamic
declaration. assertz/1 and friends are allowed to do this.

But since it is implicit dynamic, it should then be retrievable
via the clause/2 builtin. Currrently I get the following:

grafik

@ghost
Copy link
Author

ghost commented Jul 17, 2018

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.

grafik

@ghost ghost changed the title clause/2 doesn't work clause/2 and assertz/1 don't work Jul 17, 2018
@ghost
Copy link
Author

ghost commented Jul 17, 2018

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.

tau

@ghost
Copy link
Author

ghost commented Jul 17, 2018

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

@ghost
Copy link
Author

ghost commented Jul 17, 2018

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

dyn_no

@jariazavalverde
Copy link
Contributor

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

@jariazavalverde jariazavalverde self-assigned this Jul 17, 2018
@jariazavalverde
Copy link
Contributor

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.

@jariazavalverde
Copy link
Contributor

assert

@ghost
Copy link
Author

ghost commented Jul 17, 2018

SWISH has the same problem. Thats a little strange:

swish

@ghost
Copy link
Author

ghost commented Jul 17, 2018

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.

@ghost
Copy link
Author

ghost commented Jul 17, 2018

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

session_webassm

@jariazavalverde
Copy link
Contributor

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.

try

@ghost
Copy link
Author

ghost commented Jul 17, 2018

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:

unbenannt

I am consulting an running it in SWI7:

grafik

Now I change the file:

unbenannt2

And I ask SWI7 for make/0 and rerun:

grafik

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

@ghost
Copy link
Author

ghost commented Jul 17, 2018

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.

@ghost
Copy link
Author

ghost commented Jul 17, 2018

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:

swi7_tracking

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

@jariazavalverde jariazavalverde changed the title clause/2 and assertz/1 don't work Reconsult Jul 17, 2018
@jariazavalverde
Copy link
Contributor

reconsult

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

@jariazavalverde jariazavalverde transferred this issue from tau-prolog/tau-prolog Oct 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant