Anybody tried to combine raylib with SWI-Prolog.
Like programming snake or something? Like here:
Raylib bindings to Scryer Prolog using library(ffi)
https://github.com/aarroyoc/raylib-prolog
Strange: Somehow I have the feeling Scryer Prolog is
in a hybernation now, they sit on 270 issues and there
are no code changes anymore? Is it dead now?
Iāve started making swi-prolog bindings to the SDL multimedia library and started to make a pong. I still did not put the code on github but will do it if you are interested ?
Scryer Prolog is not abandoned. Not all issues can be solved right now, some require heavy changes. In my case Iām working on new features when I have time, which are on another branch. I know other contributors are also working but maybe itās true that the project a bit quiet right now.
Maybe you should think about involving @j4n_bur53 in the project to get it back rocking at full gasā¦but who knows maybe the people at scryer prefer ambient musicā¦Brian Eno, Robert Frippā¦who knows
Iām sad to hear thatā¦maybe you flooded a little bit too much with sequent calculi and Gentzen tableaux even there?!
Scryer Prolog is not the only dead Prolog around.
Like 12 months ago or so, I mentioned in passing
to @joseph-vidal-rosset , because he used Tau Prolog
on his web site, that Tau Prolog will be dead as soon
as the authors get their academic merits. And I guess
this is indeed the case, their GitHub is inactive
for at least 12 months now. But then some people still
include it in their testing, maybe this is a sign of a little
desperation, of finding Prolog system interested
in ISO nonsense?
Modified: Samstag, 6. Juli 2024, 07:53:05
phrase/2/3 comparison
The main problem with ISO Prolog is, that it is not
enough reduced to the max.
Another issue is that ISO Prolog doesnāt have a reference
implementation 100% written in Prolog itself. Like for example
the term reading and writing. Now we have the situation that
no Prolog system can do these TPTP modal logic operators
and TPTP first order logic quantifers at the same time:
/* Segerberg Models */
:- op( 600, fy, !). % universal quantifier: ![X]:
:- op( 600, fy, ?). % existential quantifier: ?[X]:
:- op( 600, fy, []). % necessity
:- op( 600, fy, <>). % possibility
But the above works in Dogelog Player. It doesnāt work
in SWI-Prolog, neither in Trealla Prolog, neither in Scryer
Prolog. Some Prolog systems have problems with !,
other Prolog systes have problems with []. The parsing is
admittedly a little tricky but after some thinking it turns out
relatively straight forward doable.
I thought you said you didnāt want to use the forum to chatā¦no more than half an hour agoā¦
PS: itās a two liner
Loads fine and seems to do its job. Note that !x at the toplevel is trapped by SWI-Prologās history mechanism. You need to disable that or write ! x (with a space).
Doesnāt work on my side:
/* SWI-Prolog 9.3.8 */
?- X = ! [Y]:p(Y).
ERROR: Syntax error: Operator expected
ERROR: X = ! [Y]
ERROR: ** here **
ERROR: :p(Y) .
?- X = [] p.
X = []p.
To allow the TPTP first order quantifier (!)/1, I have to remove the
TPTP modal operator ([])/1. Only then it works again:
?- op( 0, fy, []).
true.
?- X = ! [Y]:p(Y).
X = ![Y]:p(Y).
?- X = [] p.
ERROR: Syntax error: Operator expected
ą¼ERROR: X = []
ERROR: ** here **
ERROR: p .
But how can I have both at the same time, The TPTP first order
quantifier AND the TPTP modal operator?
Ah yes. Defining [] as an operator effectively defines any list to be an operator. That allows for making e.g. A[1] valid syntax. That extension is also shared by Ciao and I think ECLiPSe.
Beware of incoming operator headaches.
This here goes also wrong:
/* SWI-Prolog 9.3.8 */
?- X = -([Y]).
X = -[Y].
?- X = -[Y].
ERROR: Syntax error: Operator priority clash
In the above you get output that cannot be read back.
You donāt have this behaviour in Ciao Prolog.
Edit 24.07.2024
And Scryer Prolog is so desperate to impose:
?- op(600, fy, []).
error(permission_error(create,operator,[]),op/3).
These are unfortunate and known problems. ISO is demands parenthesis in most of these cases. Traditional systems were more relaxed and most of these systems have maintained this relaxed behaviour. Unfortunately they are all different. Iāve once ported a SICStus project using lots of operators. SICStus uses Prolog backtracking to find valid parse by turning operators into operants. I tried to replicate that, but even with their help I failed. SWI-Prolog has other rules that is also very hard to explain 
Bottom line seems to be that (fy600 fy600), where fy600 means an operators of type fy with priority 600, does not parse. It probably should. Just tried GNU-Prolog. That loops ā¦
I think this aspect of ISO needs to be rediscussed ā¦ Iām inclined to keep things as they are until there is some wide agreement. Changing quite likely breaks code that was designed to live with the oddities of operator resolution.
This was indeed a bug. Fixed.
Possibly the nightly was not yet updated? Using my current source this parses fine.
50 ?- X = ! [Y]:p(Y).
X = ![Y]:p(Y).
51 ?- X = [] p.
X = []p.
Beware the error is fairly difficult to spot!
The error doesnāt appear if you donāt hoist the
operator definitions. i.e. if you donāt move the operator
definitions to the top of the test file. At the moment
you execute the test cases you have to have both
operator defintions already in the operator table,
the TPTP modal opartor and the TPTP first order operator.
Or did you use an other operator priority? I can still not validate it.
I am now using build #22 and not anymore build #20. Maybe
I have to wait one more day?
Edit 25.07.2024
Some Prolog systems might already fail, in that this
directive does nothing:
:- op( 600, fy, []). % necessity
Because they are trimmed to accept op( L, M, [O1, ..., On]),
and then the empty list of operators does nothing.
But I think this is not the case for SWI-Prolog, since
the second test case passes. So I guess [] got registered
as an operator.
I see. During one of the tests I changed the definitions to (500 rather than 600):
:- op( 500, fy, !). % universal quantifier: ![X]:
:- op( 500, fy, ?). % existential quantifier: ?[X]:
:- op( 500, fy, []). % necessity
:- op( 500, fy, <>). % possibility
Note that : is 600 xfy. So, it is correct that ![Y]:p(Y). does not parse as : says its left hand must have priority < 600, which is not true for ![Y]. Possibly Ciao inherited the algorithm from SICStus (they share a common early history AFAIK), which is much more relaxed than ISO to find a sensible parse. So is SWI-Prolog, but less relaxed than SICStus.
It has nothing to do with []. Try ā! ? :p(Y)ā. It parses if you try !a:p(Y). It fails to parse if the argument of ! is an operator with priority >= 600. That is because the first thing it tries to resolve is how ? and : may be combined. So, it reduces ? to an atom if it is a prefix operator with lower priority. Otherwise it does not know. If nothing follows the :, it parses ![]: into !([](:)). The SWI-Prolog operator resolution does not look ahead, unlike the SICStus/ciao ones that probably reason that : must be infix because its has a term at both ends and this ![] must be a term, which can only be !([]). So, in fact all priorities are ignored.
But still, this is invalid under ISO and the result is dubious as, as a result, : has a left hand side term with an invalid priority.
As said. I looked into reproducing the SICStus parser by doing the operator translation using a non-deterministic Prolog program. I failed. Various terms could be parsed in multiple ways and it remained unclear why SICStus choose some specific one.
SWI-Prologās approach is to drop the operator property of an atom if it can be decided unambiguously (based on the operator before or after) that this cannot be an operator. Next, the whole thing nicely has to reduce, obeying all priorities.
I donāt see a bug. Yes, SWI-Prolog is non-standard in that defining [] as an operator also defines [X] as one. And yes, it has operator resolution that is more relaxed than ISO and less relaxed than SICStus/Ciao.
That is it. I donāt know the details of the syntax you want to define. It is not unlikely that you can define operators that make it work as you want. Bottom line is that this is system dependent. In ISO compliant systems you definitely need a lot of parenthesis, In other systems you get along with fewer or none and depending on the system you have to tweak the priorities.
It is what it is. I consider things a bug if [X] behaves different from another symbol that has the same operator properties (as was the case). I would be in favour of a wider agreement on a specification for operator resolution that is not as restricted as ISO. SICStus is also wrong as it comes with unpredictable results for ambiguous situations. I suspect Ciao to do the same, given these results.
It concerns non standard compliant code that only worked on some systems.
The usage as yf is an example. Of course, the relation between [] and [X] fot operators is the same regardless of the priority or type.
Iāll stop responding. All is said.