Hi,
Is there an easier certification with a Prolog
system that is written 100% in Prolog itself. Maybe
or maybe not, I don't know, it feels a little bit
like having implemented a Prolog system by taking
the declarative specification of in the appendix
of the ISO core standard, except I didn't use the
always declarative style of the ISO appendix. It
doesn't make any sense practically for a declarative
style and have later some Prolog system which is either
inefficient because the choice points explode or
something impractical without I/O effects like the
html//1 thingy in SWI-Prolog.
Bye
Mild Shock schrieb:
Hi,
Shocking revelation, I found two significant
bugs in my age old indexer code base yesterday.
How can an eGovernment ever trust any Prolog
system? These were bugs that typically go
unnoticed by lets say a Rust type system.
Would possibly require deep axiomatization
or heavy fuzzy testing of the code, or a
combination of both.
LoL
Bye
Mild Shock schrieb:
I made the observation while looking at
debugger traces, choice point elimination,
driven by indexes, also determines what
FAIL/REDO ports a debugger shows.
What is amazing Scryer Prolog, which has
a tamer version of multi-argument indexing, a
kind of skip indexing, they describe
it on their GitHub homepage, can do it:
/* Scryer Prolog 0.9.4-415 */
?- app(X,Y,[1]).
X = [], Y = [1]
; X = [1], Y = [].
And the ghost from my cabinet, formerly
Jekejeke Prolog, which does a little bit more
than skip indexing, but still not the same deep
indexing as in SWI-Prolog can also do it:
/* Jekejeke Runtime 1.7.3 */
?- app(X,Y,[1]).
X = [], Y = [1];
X = [1], Y = [].
Mild Shock schrieb:
I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,
or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:
app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).
ECLiPSe Prolog gives me, only one redo question
in the top-level:
/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).
X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;
X = [1]
Y = []
Yes (0.00s cpu, solution 2)
In SWI-Prolog I find, two redo questions
in the top.level:
/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.
I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.
ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.
Hi,
Most of the libraries and the system are design so
that native is a last resort. So most functionality is
Prolog and in a few instances there is a native call:
- Main Design:
Prolog (a lot of it) --> Native (very little)
This design, concerning the call control flow, is only
broken in the top level, and in very few places, like the
browser and a web server. The top-level is a native entry
point and it needs to reach into Prolog, and the
libraries library(react) and library(spin) provide call
back facilities for the browser and a web
server event handlers:
- 2nd Design:
Native (top-level, react and spin) --> Prolog
There is no idea at all that the Prolog system supports
any iterators. I did this in the past. But the Prolog
system gets simpler without the viewpoint that the
interface should support iterators. SWI-Prolog always
invests heavily to support iterators. Based on the
rather negative experience with formerly Jekejeke Prolog
we tried to completely avoid any iterator interface.
Bye
Anyway, I have no idea what "choice point
elimination" is supposed to refer to in literature.
Literally, "choice point elimination" should mean
something related to: a choicepoint was created
some technique eliminates that choice point
Hi,
There is one thing that currently causes me headaches.
So far the Dogelog Player design didn't have a big
ping pong from Prolog to Native and back.
It has the Main Design with Prolog --> Native, and
the 2nd Design with Native --> Prolog. We also managed
to do some clause indexing preparation
in the Main Design, so we have this separation of concerning
currently for first argument indexing:
- Computation of Clause Key Value: Prolog
The computation of the Key Value of a clause is done
at compile time in pure Prolog. There are two strategies,
for dynamic predicates the key is directly taken from
the first argument of the head.
For static predicates the body of the claue is also
analyzed, and this can also give a key, like for
exaple if the body as a unification X = C, and X
appears as first argument, the the key can be taken from C.
- Computation of Goal/Head Key Value: Native
The clauses are supplied with their Key Value, and
Native code does add them with indexing. Or update the
index when a clause is removed.
The computation of the Key Value of a goal or clause
head is done a runtime in Native. And then the lookup
is done natively as well.
Now I wonder how I can bring multi-argument JIT Indexing
from formerly Jekejeke Prolog into the picture, and still
have a high degree of 100% Prolog code. Some hurdles:
- Clause Key Value on Demand: Native -> Prolog
So if I would keep the scheme that Prolog determines the
clause Key Values. And if I would do this on demand,
I would have a Native -> Prolog call.
- Clauses would need decompile:
Even if I implement such a Native -> Prolog hook,
the problem is Clauses have not the compile time format
at runtime. So the my old 100% Prolog code for Clause
Key Value will not work, requires first decompilation.
- YAP approach:
I have an old paper from YAP. For the indexing they
are scanning the native clause code. I didn't double
check yet what SWI-Prolog (has JIT-ing) or Scryer Prolog
(doesn't do it JIT style?). Etc...
- What else?
Well its not a big headache, but a kind of blocker,
before I decide what to do. There are a couple of options
to get out of the dilemma, and turn the Prolog systems
around, and make it 100% Prolog again. Its like the
big beautiful bill by Donald Trump. Make Prolog
100% Prolog again!
LoL
Bye
Mild Shock schrieb:
Hi,
Most of the libraries and the system are design so
that native is a last resort. So most functionality is
Prolog and in a few instances there is a native call:
- Main Design:
Prolog (a lot of it) --> Native (very little)
This design, concerning the call control flow, is only
broken in the top level, and in very few places, like the
browser and a web server. The top-level is a native entry
point and it needs to reach into Prolog, and the
libraries library(react) and library(spin) provide call
back facilities for the browser and a web
server event handlers:
- 2nd Design:
Native (top-level, react and spin) --> Prolog
There is no idea at all that the Prolog system supports
any iterators. I did this in the past. But the Prolog
system gets simpler without the viewpoint that the
interface should support iterators. SWI-Prolog always
invests heavily to support iterators. Based on the
rather negative experience with formerly Jekejeke Prolog
we tried to completely avoid any iterator interface.
Bye
gives me the feeling that "choice point elimination" is
something jb coined, and does not belong to traditional
Prolog implementation terminology.
Hi,
I have really interesting ghosts in by cabinet.
Not only old software, also crazy people like
Bart Demoen. And the good thing everything is
still available through Google Groups that
has nicely preserved comp.lang.prolog. According
Barty Boy the term "Choice Point Elimination"
didn't really exist:
Anyway, I have no idea what "choice point
elimination" is supposed to refer to in literature.
Literally, "choice point elimination" should mean
something related to: a choicepoint was created
some technique eliminates that choice point
https://groups.google.com/g/comp.lang.prolog/c/qnwD_TEG4xg/m/LMiDtFY1dQIJ
Well he is somehow right if "elimination" is
interpreted as creating and then destroying.
But it could also mean preventing the creation
of a choice point. You never know from the
far of a the flemish / dutch mountains what a
term means. Even if somebody presents a corpus
resarch as I did.
Bye
Mild Shock schrieb:
Hi,
There is one thing that currently causes me headaches.
So far the Dogelog Player design didn't have a big
ping pong from Prolog to Native and back.
It has the Main Design with Prolog --> Native, and
the 2nd Design with Native --> Prolog. We also managed
to do some clause indexing preparation
in the Main Design, so we have this separation of concerning
currently for first argument indexing:
- Computation of Clause Key Value: Prolog
The computation of the Key Value of a clause is done
at compile time in pure Prolog. There are two strategies,
for dynamic predicates the key is directly taken from
the first argument of the head.
For static predicates the body of the claue is also
analyzed, and this can also give a key, like for
exaple if the body as a unification X = C, and X
appears as first argument, the the key can be taken from C.
- Computation of Goal/Head Key Value: Native
The clauses are supplied with their Key Value, and
Native code does add them with indexing. Or update the
index when a clause is removed.
The computation of the Key Value of a goal or clause
head is done a runtime in Native. And then the lookup
is done natively as well.
Now I wonder how I can bring multi-argument JIT Indexing
from formerly Jekejeke Prolog into the picture, and still
have a high degree of 100% Prolog code. Some hurdles:
- Clause Key Value on Demand: Native -> Prolog
So if I would keep the scheme that Prolog determines the
clause Key Values. And if I would do this on demand,
I would have a Native -> Prolog call.
- Clauses would need decompile:
Even if I implement such a Native -> Prolog hook,
the problem is Clauses have not the compile time format
at runtime. So the my old 100% Prolog code for Clause
Key Value will not work, requires first decompilation.
- YAP approach:
I have an old paper from YAP. For the indexing they
are scanning the native clause code. I didn't double
check yet what SWI-Prolog (has JIT-ing) or Scryer Prolog
(doesn't do it JIT style?). Etc...
- What else?
Well its not a big headache, but a kind of blocker,
before I decide what to do. There are a couple of options
to get out of the dilemma, and turn the Prolog systems
around, and make it 100% Prolog again. Its like the
big beautiful bill by Donald Trump. Make Prolog
100% Prolog again!
LoL
Bye
Mild Shock schrieb:
Hi,
Most of the libraries and the system are design so
that native is a last resort. So most functionality is
Prolog and in a few instances there is a native call:
- Main Design:
Prolog (a lot of it) --> Native (very little)
This design, concerning the call control flow, is only
broken in the top level, and in very few places, like the
browser and a web server. The top-level is a native entry
point and it needs to reach into Prolog, and the
libraries library(react) and library(spin) provide call
back facilities for the browser and a web
server event handlers:
- 2nd Design:
Native (top-level, react and spin) --> Prolog
There is no idea at all that the Prolog system supports
any iterators. I did this in the past. But the Prolog
system gets simpler without the viewpoint that the
interface should support iterators. SWI-Prolog always
invests heavily to support iterators. Based on the
rather negative experience with formerly Jekejeke Prolog
we tried to completely avoid any iterator interface.
Bye
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 48:58:37 |
| Calls: | 12,115 |
| Calls today: | 6 |
| Files: | 15,010 |
| Messages: | 6,518,530 |