I just made a 2 step Non-Monotonic Example. It worked only in
marking the first program code cell as background knowledge and
the second program code cell as query specific.
How would I do a 3 step Non-Monotonic Example?
https://swish.swi-prolog.org/p/tweety_still_fly.swinb
See also:
Tweety - still Flying
Some Remarks on Abnormal Birds, Applicable Rules and a Default Prover
Gerhard Bewka - 1986
https://cdn.aaai.org/AAAI/1986/AAAI86-002.pdf
I did a quick test, now I think you should mark the second program cell as âused for all queries in the notebookâ
If I do what you suggest, the 2 step example gets wrong. The first
query should give true. I gives true the way I did it. But in your way
it gives false. The two queries now give the same result, whereas the
Tweety example is about showing that they give different results.
Twice the same result is not what is expected for the Tweety example:
But my question was rather how I do a 3 step example as a SWISH
Notebook with SWI-Prolog pengines. The 2 step example is fine.
But how do I extend it to a 3 step example?
Like this example here:
:- dynamic(abnormal1/1).
:- discontiguous(abnormal1/1).
:- dynamic(abnormal2/1).
:- discontiguous(abnormal2/1).
feathers(tweety).
flies(X) :- feathers(X), \+ abnormal1(X).
walks(X) :- \+ flies(X), \+ abnormal2(X).
?- walks(tweety).
false.
abnormal1(tweety).
?- walks(tweety).
true.
abnormal2(tweety).
?- walks(tweety).
false.
I see. You would need something more like a simulation of REPL, keeping into account the relative order od cells. Sorry for the noise, I donât know if its feasibleâŚ
Yeah, the SWI-Prolog top-level can do a 3 step example. It just
linearily accumulates knowledge so to speak. But how wrap the
same into a SWISH Notebook?
Not really. Try this example:
:- dynamic(abnormal1/1).
:- discontiguous(abnormal1/1).
:- dynamic(abnormal2/1).
:- discontiguous(abnormal2/1).
feathers(tweety).
flies(X) :- feathers(X), \+ abnormal1(X).
flies(X) :- feathers(X), \+ abnormal2(X).
?- flies(tweety).
true ;
true.
abnormal1(tweety).
?- flies(tweety).
true.
abnormal2(tweety).
?- flies(tweety).
false.
I guess we would need a third class of program cells that is like global, but only applies to query cells below it? Shouldnât be too hard to implement. So the question is whether it is worthwhile? Be aware that everything we add also complicates things for the user 
Opinions?
Such cells exist somehow already, probably serving certain
user needs that gave rise to this mechanism. But their logic is
exclusive (first below) and not inclusive (all below).
I made a SWISH notebook:
https://swish.swi-prolog.org/p/tweety_still_fly2.swinb
You see that the query specific program code is switched on
on a case by case basis and not accumulated:
But maybe there is a way to do the 3 step example with
the existing SWISH implementation nevertheless?
Ah, I understand the problem now, thank you.
Turns out I have also noticed this when I tried to translate a blog post to a swish notebook and thought exactly the same thing as @jan :
And so my opinion is that it would be very worthwhile. I would even go as far as saying that the current local cells are rather counterintuitive if you have already used python or any other language notebooks.
In jupyter notebooks, any cell evaluation adds to the current state of the notebook.
But, after the initial wonder, you often realize that the state of the notebook can quickly become an unmaintainable mess.
So, after the original confusion when meeting the local cell type in swish, I really liked this implementation.
But, I think that adding a third type of program cell as described by @jan would be useful to make notebook where the state of the program progresses from top to bottom, like a linear story ?
So that we could describe user interactions ? or blog post ? or tell a story ?
Finally, the remaining question would be, should we make the local, global or semi-global type the default ?
If you ever manage to implement that third type of cell, Iâll make sure to convert one of my blogpost with that new type of cell to test it 
I gave it a shot. The new version also gives much clearer feedback on the program cells that are going to be used for a particular query. I left the default to be ânext queryâ. For compatibility reasons and because Iâm not convinced the other alternatives are better defaults.
Please give it a try. You may need a shift-reload of the SWISH page to make sure everything is updated. Enjoy and please report whether you like it.
Thank you so much !
Here is an updated version of the notebook using the new cell type which is now exactly the same as the original blog post !
It is really amazing for translating the blog post.
One of the most amazing thing is that we can still use the next query type of cell to show code that we donât actually want to be part of the general state, so a kind of a parallel branch in the linear flow of the notebook.
BTW: Can we question whether the old modes are still needed?
Ok, the new mode are green rounds with a white down arrow.
The non-monotonic example here works fine, see below.
<begin side quest>
Now I have a new feature request: Can I have a ârun untilâ as
well. Some notebooks such as Jupyter feature that. So pressing
run on a current cell could run all cells until the current cell?
<end side quest>
Nice!
Disclaimer: I donât now what the current state of Jupyter is,
I find a dozen different menu screenshots and feature requests
on the web. âRun untilâ seems nevertheless to be useful, just
to avoid Repetitive-Strain-Injury by clicking millions of cells.
But I donât know what caching is exactly needed to not make
it quadratic. I guess Jupyter works differently since it has a
notion of server session.
Yes. IMO though, they all have a meaning.
There is already an option on a query cell for running it on page load and at the top there is a play button that runs all queries. Typically the thing is a bit orthogonal to SWISH though as SWISH is stateless. Actually, if you run it locally it can deal with state, making this more useful. The quest for a stateful mode has come up multiple times. It is not impossible; Pengines can be kept alive and maintain state. Still, I think the stateless behaviour raises far fewer surprises (and requires less resources)
Its doing 3 creates and runs the queries in parallel.
The parallel makes it less obvious that it does
the execution with quadratic effort.
What happens if I have 30 cells, 10 times more?
I think browsers limit parallelism in requests to
like 5 or 6. I think it will not work very good anymore.
What about interleaving Prolog code send, Prolog
query send, Prolog result receive, along all cells,
with only one create. Its not stateful, only a session
to fill the cells. The session can be removed afterwards.
Disclaimer: Although for plotting the parallelism can
be sometimes good. Just like progressive parallel loading
of images, it could have a similar effect. I also
saw that queries might wait for user response.
