From Newsgroup: comp.lang.prolog

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024 https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf

Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

The paper mentions: "Huge computing power
of our modern laptops". If I look at my
new iPad Pro M4 2024, I would say

"Huge computing power of tablets", measurement
have shown it is almost twice as fast as my
laptops form ca. 2020. So lets do the following:

Bring LPTP to Dogelog Player?

Bye

P.S.: This would give a new spin of Alan
Key's vision of Dynabook. Can we run the
Dynabook idea on Prolog?

Joe Armstrong interviews Alan Kay
https://www.youtube.com/watch?v=fhOHn9TClXY

Mild Shock schrieb:

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024 https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf

Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog


Hi,

A Prolog appendix could give a nice boost
to your Edge Device Artificial Intelligence, possibly
not having much problems with Zebra puzzles:

A week ago, I posted that I was cooking a
logical reasoning benchmark as a side project.
Now it's finally ready! Introducing 🦓 𝙕𝙚𝙗𝙧𝙖𝙇𝙤𝙜𝙞𝙘,
designed for evaluating LLMs with Logic Puzzles. https://x.com/billyuchenlin/status/1814254565128335705

LoL

Bye

Mild Shock schrieb:

Hi,

The paper mentions: "Huge computing power
of our modern laptops". If I look at my
new iPad Pro M4 2024, I would say

"Huge computing power of tablets", measurement
have shown it is almost twice as fast as my
laptops form ca. 2020. So lets do the following:

Bring LPTP to Dogelog Player?

Bye

P.S.: This would give a new spin of Alan
Key's vision of Dynabook. Can we run the
Dynabook idea on Prolog?

Joe Armstrong interviews Alan Kay
https://www.youtube.com/watch?v=fhOHn9TClXY

Mild Shock schrieb:

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024
https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf >>

Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

Although the work itself might be solid work.
the appeal to fixpoints should already ring a
bell. What I wish from a logic framework and

what would attract me is:
- includes the concept of a model finder,
to show things unprovable.
- indeally a model finder, that can also
find functions as counter models.
- allows to express things in non-classical
logic and can make good use of non-classical logic.
- allows to express things in constructive
function spaces and can make good use of constructive function spaces.

Currently with fixpoints and classical logic,
the approach is not enough advanced, doesn't
utilize what type theory could offer.

Bye

Mild Shock schrieb:

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024 https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf

Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog


Karel Gott - Rot und schwarz
https://www.youtube.com/watch?v=R3qAGDchWWM

So whats the fallacy in Robert Staerks modality?
It has to do with the difference between computation
and derivation, don't confuse the two!

What also helps nowadays, don't take a philosopher
on board who is totally clueless about non-classical
logics. I don't want to say names, but being that

ignorant is quite a feat. So how did Robert Staerk
start? Well he possibly had first the problem
that this here simple logic program:

p :- \+ p.

when classically translated is unsatisfiable, and
therefore in classical logic, leads to Ex Falso
Quodlibet. So they went with non-classical logic,

but a cheap one, i.e. 3-valued logic, so that
we have these two modalities:

p_s : p succeeds
p_f : p fails

The fallacy is now to think a total computable
function is the same as BIVALENCE, expressed here,
using the further modality in the game:

p_t -> p_s v p_f

non-constructive logics would immediately see
that p_s v p_f is problematic, since the above
intoduces a disjunction, without a disjunction

property. Now there is possibly the surprise
with this overall fixpoint juggling we might
have derivations that say p_t, but not in this sense:

p_t : p terminates

Just try an example with a non-continous fixpoint
operator, derived from a Clark completion. I don't
see in the slides that it is excluded?

Might even try to provide a concrete example myself...

Mild Shock schrieb:

Hi,

Although the work itself might be solid work.
the appeal to fixpoints should already ring a
bell. What I wish from a logic framework and

what would attract me is:
- includes the concept of a model finder,
  to show things unprovable.
- indeally a model finder, that can also
  find functions as counter models.
- allows to express things in non-classical
  logic and can make good use of non-classical logic.
- allows to express things in constructive
  function spaces and can make good use of constructive function spaces.

Currently with fixpoints and classical logic,
the approach is not enough advanced, doesn't
utilize what type theory could offer.

Bye

Mild Shock schrieb:

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024
https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf >>

Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog


Here is a challenge that might appeal
to all fixpoint lovers and non-classical
logic lovers. Althought I expect them

to be a rather rare species. Take the
Clark completion and the 3-valued semantics.
Then this logic program:

foo(n)
foo(s(X)) :- foo(X).

bar(n).
bar(s(X)) :- bar(X).
bar(w) :- \+ (foo(X), \+ bar(X)).

Here the quizz that makes up the challenge:

- Whats the least fixpoint of bar/1,
giving bar a domain that makes
bar bivalent?

- Does bar/1 have finite derivations, i.e.
terminates, for each element taken
from that domain?

Have Fun!

The exercise is inspired by this quote and paper:

"The finite stages (JnP)n<w have a computational meaning."
The theoretical foundations of LPTP
Robert F. Stärk - 1998 https://www.sciencedirect.com/science/article/pii/S0743106697100139

Mild Shock schrieb:

Karel Gott - Rot und schwarz
https://www.youtube.com/watch?v=R3qAGDchWWM

So whats the fallacy in Robert Staerks modality?
It has to do with the difference between computation
and derivation, don't confuse the two!

What also helps nowadays, don't take a philosopher
on board who is totally clueless about non-classical
logics. I don't want to say names, but being that

ignorant is quite a feat. So how did Robert Staerk
start? Well he possibly had first the problem
that this here simple logic program:

p :- \+ p.

when classically translated is unsatisfiable, and
therefore in classical logic, leads to Ex Falso
Quodlibet. So they went with non-classical logic,

but a cheap one, i.e. 3-valued logic, so that
we have these two modalities:

p_s : p succeeds
p_f : p fails

The fallacy is now to think a total computable
function is the same as BIVALENCE, expressed here,
using the further modality in the game:

p_t -> p_s v p_f

non-constructive logics would immediately see
that p_s v p_f is problematic, since the above
intoduces a disjunction, without a disjunction

property. Now there is possibly the surprise
with this overall fixpoint juggling we might
have derivations that say p_t, but not in this sense:

p_t : p terminates

Just try an example with a non-continous fixpoint
operator, derived from a Clark completion. I don't
see in the slides that it is excluded?

Might even try to provide a concrete example myself...

Mild Shock schrieb:

Hi,

Although the work itself might be solid work.
the appeal to fixpoints should already ring a
bell. What I wish from a logic framework and

what would attract me is:
- includes the concept of a model finder,
   to show things unprovable.
- indeally a model finder, that can also
   find functions as counter models.
- allows to express things in non-classical
   logic and can make good use of non-classical logic.
- allows to express things in constructive
   function spaces and can make good use of constructive function spaces. >>
Currently with fixpoints and classical logic,
the approach is not enough advanced, doesn't
utilize what type theory could offer.

Bye

Mild Shock schrieb:

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024
https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf


Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog


Just look at GitHub issues and sort by "recent update".
I get for the last week the following figures:

- New tickets: 7 new tickets
- Closed tickets: 2 closed tickets

To get a turn around you the the 2nd number bigger
that the 1st number, and not the other way around.

Mild Shock schrieb:

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024 https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf

Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

How many years does Scryer Prolog allocate to
make a turn around? Lets say we have an explosion
of new tickets at the beginning, so the new tickets

history might have this time functions, plus
some parameters that scale it:

n(t) = 1 - exp(-t)

And lets say tickets are closed at a constant
speed, like in this fuction:

c(t) = t

Again c(t) has some parameters not shown, to
scale it. But essently the project is

completed when this one reaches zero:

f(t) = n(t) - c(t)

What can go wrong? Basically onec critical thing
is c(t). If you don't have solutions or resources,
c(t) might look very different, and a zero

might never be reached.

Bye

Mild Shock schrieb:

Just look at GitHub issues and sort by "recent update".
I get for the last week the following figures:

- New tickets: 7 new tickets
- Closed tickets: 2 closed tickets

To get a turn around you the the 2nd number bigger
that the 1st number, and not the other way around.

Mild Shock schrieb:

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024
https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf >>

Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

Some folks from Scryer Prolog asked the following question:

Current plan is to compile WAM using Cranelift.
However, GC must be done first. Maybe Prolog in
the future could be used to analyze Prolog programs
and produce optimizations (Prolog compiler in Prolog?)

https://blog.adrianistan.eu/scryer-prolog-meetup-2023-notes/

There is no maybe, there is already a be, for both
GC and Prolog compiler in Prolog. But you have to start
with the idea, otherwise you probably cant make it.

Just take Dogelog Player, it has the following:

- Full Sweep Garbage Collector:
In the major metronome tick.

- Incremental Garbage Collector:
In the minor metronome tick.

- Read/Write 100% written in Prolog:
From scanner to parser and unparse its all Prolog.

- Compiler Front End 100% written in Prolog:
This is in albufeira.p, this is a little higher level
code generator that compiles Prolog clauses, including
the cut and if-then-else inlining, some constant term
optimizations and body indexing optimizations.

- Compiler Back Ends 100% written in Prolog
There are cross compiler back ends for JavaScript,
Python and Java. And there is runtime back end,
for the dynamic database and consult at runtime.
The corresponding runtimes have cute neck optimization
and last call optimization.

Bye

Mild Shock schrieb:

Hi,

How many years does Scryer Prolog allocate to
make a turn around? Lets say we have an explosion
of new tickets at the beginning, so the new tickets

history might have this time functions, plus
some parameters that scale it:

n(t) = 1 - exp(-t)

And lets say tickets are closed at a constant
speed, like in this fuction:

c(t) = t

Again c(t) has some parameters not shown, to
scale it. But essently the project is

completed when this one reaches zero:

f(t) = n(t) - c(t)

What can go wrong? Basically onec critical thing
is c(t). If you don't have solutions or resources,
c(t) might look very different, and a zero

might never be reached.

Bye

Mild Shock schrieb:

Just look at GitHub issues and sort by "recent update".
I get for the last week the following figures:

- New tickets: 7 new tickets
- Closed tickets: 2 closed tickets

To get a turn around you the the 2nd number bigger
that the 1st number, and not the other way around.

Mild Shock schrieb:

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024
https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf


Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

Currently I wish to add a C# sharp backend,
and also show some Unity integration.

But I am facing some health problems, some
nasty virus infection, which still persists

a little bit. Either I will be able to do
it in 2024, or you wont here anything

from me anymore...

LoL

Bye

P.S.: Some enemies might be happy if I bite
the dust, so it will be quite funny if

I can make it. But who knows?

Mild Shock schrieb:

Hi,

Some folks from Scryer Prolog asked the following question:

Current plan is to compile WAM using Cranelift.
However, GC must be done first. Maybe Prolog in
the future could be used to analyze Prolog programs
and produce optimizations (Prolog compiler in Prolog?)

https://blog.adrianistan.eu/scryer-prolog-meetup-2023-notes/

There is no maybe, there is already a be, for both
GC and Prolog compiler in Prolog. But you have to start
with the idea, otherwise you probably cant make it.

Just take Dogelog Player, it has the following:

- Full Sweep Garbage Collector:
  In the major metronome tick.

- Incremental Garbage Collector:
  In the minor metronome tick.

- Read/Write 100% written in Prolog:
  From scanner to parser and unparse its all Prolog.

- Compiler Front End 100% written in Prolog:
  This is in albufeira.p, this is a little higher level
  code generator that compiles Prolog clauses, including
  the cut and if-then-else inlining, some constant term
  optimizations and body indexing optimizations.

- Compiler Back Ends 100% written in Prolog
  There are cross compiler back ends for JavaScript,
  Python and Java. And there is runtime back end,
  for the dynamic database and consult at runtime.
  The corresponding runtimes have cute neck optimization
  and last call optimization.

Bye

Mild Shock schrieb:

Hi,

How many years does Scryer Prolog allocate to
make a turn around? Lets say we have an explosion
of new tickets at the beginning, so the new tickets

history might have this time functions, plus
some parameters that scale it:

n(t) = 1 - exp(-t)

And lets say tickets are closed at a constant
speed, like in this fuction:

c(t) = t

Again c(t) has some parameters not shown, to
scale it. But essently the project is

completed when this one reaches zero:

f(t) = n(t) - c(t)

What can go wrong? Basically onec critical thing
is c(t). If you don't have solutions or resources,
c(t) might look very different, and a zero

might never be reached.

Bye

Mild Shock schrieb:

Just look at GitHub issues and sort by "recent update".
I get for the last week the following figures:

- New tickets: 7 new tickets
- Closed tickets: 2 closed tickets

To get a turn around you the the 2nd number bigger
that the 1st number, and not the other way around.

Mild Shock schrieb:

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024
https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf


Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

The C# backend was already planned 3
years ago. But then we gave priority to
a Python backend.

But Python is the worst language on this
planet. Their module approach doesn't
really have export modifiers.

Nevertheless they top TIOBE:

Highest Position (since 2001): #1 in Aug 2024 https://www.tiobe.com/tiobe-index/python/

Superficially even Prolog has a better
module system, although export restrictions
are not enforced, you can pretend to do exports,

via the module/2 directive. After we
completed the Python backend, we recently
did the Java backend. But this was not

only done for the benefit of Java, but
also as an intermediate step for the C#
backend. We are pretty close to that

everything has stabilized, and it would
be a good timing to do the C# backend then.

Bye

Mild Shock schrieb:

Hi,

Currently I wish to add a C# sharp backend,
and also show some Unity integration.

But I am facing some health problems, some
nasty virus infection, which still persists

a little bit. Either I will be able to do
it in 2024, or you wont here anything

from me anymore...

LoL

Bye

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

A few days age we improved the cross referencer,
to deal with the many target platforms. The
old cross referencer for example showed:

xor/3 nova/Eval.java
nova/eval.mjs
nova/eval.py

Meaning the evaluable function xor/3 is
available in Java, JavaScript and Python.
What we now do, we simply show:

xor/3 nova/eval.*

Soon the wildcard will mean C# as well,
and not only Java, JavaScript and Python.
Extending the proof of concept for Prolog

compiler 100% written in Prolog itself.

Bye

Mild Shock schrieb:

Hi,

The C# backend was already planned 3
years ago. But then we gave priority to
a Python backend.

But Python is the worst language on this
planet. Their module approach doesn't
really have export modifiers.

Nevertheless they top TIOBE:

Highest Position (since 2001): #1 in Aug 2024 https://www.tiobe.com/tiobe-index/python/

Superficially even Prolog has a better
module system, although export restrictions
are not enforced, you can pretend to do exports,

via the module/2 directive. After we
completed the Python backend, we recently
did the Java backend. But this was not

only done for the benefit of Java, but
also as an intermediate step for the C#
backend. We are pretty close to that

everything has stabilized, and it would
be a good timing to do the C# backend then.

Bye

Mild Shock schrieb:

Hi,

Currently I wish to add a C# sharp backend,
and also show some Unity integration.

But I am facing some health problems, some
nasty virus infection, which still persists

a little bit. Either I will be able to do
it in 2024, or you wont here anything

from me anymore...

LoL

Bye

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

Generally I don't believe in things like
SWI-Prolog Janus Python integration. This
type of integration has the advantage

that SWI-Prolog can run in full speed,
on the other hand it has the disadvantage
that one cannot take advantage of Python async,

because SWI-Prolog itself has no async. I
am talking about the single threaded async here.
My experience single treaded async and multi-threaded

Prolog are quite different pairs of shoes. So
when doing the C# backend for Dogelog Player,
I will be faced again to provide a complete

async solution for the async part of Novacore.

Woa!

Bye

Mild Shock schrieb:

Hi,

A few days age we improved the cross referencer,
to deal with the many target platforms. The
old cross referencer for example showed:

xor/3        nova/Eval.java
             nova/eval.mjs
             nova/eval.py

Meaning the evaluable function xor/3 is
available in Java, JavaScript and Python.
What we now do, we simply show:

xor/3        nova/eval.*

Soon the wildcard will mean C# as well,
and not only Java, JavaScript and Python.
Extending the proof of concept for Prolog

compiler 100% written in Prolog itself.

Bye

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

Currently I have first hand experience how
difficult it is to model single treaded async
on top of multi-threaded Prolog,

since I want to bring Dogelog Player async
also to formerly Jekejeke Prolog. It wasn't
so much a problem in the Dogelog Player for

Java version, since I could replicate the
JavaScript design. But it is a little
nasty in the formerly Jekejeke Prolog case,

since Thread identity from multi-threaded
Prolog and Task identity from single treaded
async are not the same, you have to dig

deeper into stackfull and stackless coroutines,
to get the Task identity notion correctly.
I wasn't able to do it yet for formerly

Jekejeke Prolog, there is still a pending ticket.

Bye

Mild Shock schrieb:

Hi,

Generally I don't believe in things like
SWI-Prolog Janus Python integration. This
type of integration has the advantage

that SWI-Prolog can run in full speed,
on the other hand it has the disadvantage
that one cannot take advantage of Python async,

because SWI-Prolog itself has no async. I
am talking about the single threaded async here.
My experience single treaded async and multi-threaded

Prolog are quite different pairs of shoes. So
when doing the C# backend for Dogelog Player,
I will be faced again to provide a complete

async solution for the async part of Novacore.

Woa!

Bye

Mild Shock schrieb:

Hi,

A few days age we improved the cross referencer,
to deal with the many target platforms. The
old cross referencer for example showed:

xor/3        nova/Eval.java
              nova/eval.mjs
              nova/eval.py

Meaning the evaluable function xor/3 is
available in Java, JavaScript and Python.
What we now do, we simply show:

xor/3        nova/eval.*

Soon the wildcard will mean C# as well,
and not only Java, JavaScript and Python.
Extending the proof of concept for Prolog

compiler 100% written in Prolog itself.

Bye

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

To stabilize Dogelog Player now, there
are only a few important pending tickets,
but the growing pains are basically

to identify the low hanging fruits. I
do not tend to throw a dice, it might
take some time doing nothing, before a

next important ticket is selected based
on some rationalization of a priorization.

Bye

Mild Shock schrieb:

Hi,

Currently I have first hand experience how
difficult it is to model single treaded async
on top of multi-threaded Prolog,

since I want to bring Dogelog Player async
also to formerly Jekejeke Prolog. It wasn't
so much a problem in the Dogelog Player for

Java version, since I could replicate the
JavaScript design. But it is a little
nasty in the formerly Jekejeke Prolog case,

since Thread identity from multi-threaded
Prolog and Task identity from single treaded
async are not the same, you have to dig

deeper into stackfull and stackless coroutines,
to get the Task identity notion correctly.
I wasn't able to do it yet for formerly

Jekejeke Prolog, there is still a pending ticket.

Bye

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog


But Scryer Prolog must nevertheless have somewhere
some good genes. Even it posted about a Prolog compiler
written in Prolog itself. Lets make some reality check:

/* Ichiban Prolog */
real 0m39.635s
user 0m59.684s
sys 0m7.891s

/* Dogelog Player for Java */
?- time((between(1,6001,_), nrev, fail; true)).
% Zeit 588 ms, GC 0 ms, Lips 5113263, Uhr 11.08.2024 10:47
true.

/* Trealla Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
% Time elapsed 0.549s, 3000503 Inferences, 5.468 MLips
true.

/* Scryer Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
% CPU time: 0.302s, 3_024_526 inferences
true.

/* SWI-Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
% 2,994,499 inferences, 0.078 CPU in 0.089 seconds (88% CPU, 38329587 Lips) true.

Dogelog Player has a Prolog compiler written in
Prolog itself. But the limiting factor is of course
always the runtime engine itself, that executes the

compiled code. You can inline and optimize whatever
you want, if the runtime engine, its architecture,
has some limitations performance wise, you won't

see aby speed. I don't know yet whether I will beat
SWI-Prolog in this test case ever in the near future?
Especially with some cheap effort?

Mild Shock schrieb:

Just look at GitHub issues and sort by "recent update".
I get for the last week the following figures:

- New tickets: 7 new tickets
- Closed tickets: 2 closed tickets

To get a turn around you the the 2nd number bigger
that the 1st number, and not the other way around.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog


But I am nevertheless convinced Scryer Prolog
is dead. These good genes only appeared recently.
But I was comparing oranges and apples.

I compared Dogelog Player which has garbage
collection to a Prolog system like Scryer Prolog
which doesn't have garbage collection.

A Prolog system that doesn't have garbage collection
can run faster. The challenge is a runtime engine
that is fast AND has garbage collection.

Mild Shock schrieb:

But Scryer Prolog must nevertheless have somewhere
some good genes. Even it posted about a Prolog compiler
written in Prolog itself. Lets make some reality check:

/* Ichiban Prolog */
real    0m39.635s
user    0m59.684s
sys     0m7.891s

/* Dogelog Player for Java */
?- time((between(1,6001,_), nrev, fail; true)).
% Zeit 588 ms, GC 0 ms, Lips 5113263, Uhr 11.08.2024 10:47
true.

/* Trealla Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
% Time elapsed 0.549s, 3000503 Inferences, 5.468 MLips
   true.

/* Scryer Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
   % CPU time: 0.302s, 3_024_526 inferences
   true.

/* SWI-Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
% 2,994,499 inferences, 0.078 CPU in 0.089 seconds (88% CPU, 38329587 Lips) true.

Dogelog Player has a Prolog compiler written in
Prolog itself. But the limiting factor is of course
always the runtime engine itself, that executes the

compiled code. You can inline and optimize whatever
you want, if the runtime engine, its architecture,
has some limitations performance wise, you won't

see aby speed. I don't know yet whether I will beat
SWI-Prolog in this test case ever in the near future?
Especially with some cheap effort?

Mild Shock schrieb:

Just look at GitHub issues and sort by "recent update".
I get for the last week the following figures:

- New tickets: 7 new tickets
- Closed tickets: 2 closed tickets

To get a turn around you the the 2nd number bigger
that the 1st number, and not the other way around.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

The test case that crashes all these new
Prolog systems, is for example this one.
It still crashes Scryer Prolog:

$ ulimit -m 2000000
$ ulimit -v 2000000
$ target/release/scryer-prolog -v
v0.9.4-135-g7cfe8ee5

$ target/release/scryer-prolog
?- [user].
app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).
garbage(0, [0]) :- !.
garbage(N, L) :- M is N-1, garbage(M, R), app(R, R, L).
foo :- garbage(12,_), foo.

?- foo.
memory allocation of 2147483648 bytes failed
Aborted

The above preferably runs indefinitely. For
example SWI-Prolog can run it indefinitely.
It also crashes other Prolog systems:

$ ~/go/bin/1pl
Top level for ichiban/prolog v1.2.1
This is for testing purposes only!
See https://github.com/ichiban/prolog for more details.
Type Ctrl-C or 'halt.' to exit.

?- ['bomb.p'].
true.
?- foo.
runtime: out of memory:
cannot allocate 4194304-byte block (802816000 in use)

Mild Shock schrieb:

But I am nevertheless convinced Scryer Prolog
is dead. These good genes only appeared recently.
But I was comparing oranges and apples.

I compared Dogelog Player which has garbage
collection to a Prolog system like Scryer Prolog
which doesn't have garbage collection.

A Prolog system that doesn't have garbage collection
can run faster. The challenge is a runtime engine
that is fast AND has garbage collection.

Mild Shock schrieb:

But Scryer Prolog must nevertheless have somewhere
some good genes. Even it posted about a Prolog compiler
written in Prolog itself. Lets make some reality check:

/* Ichiban Prolog */
real    0m39.635s
user    0m59.684s
sys     0m7.891s

/* Dogelog Player for Java */
?- time((between(1,6001,_), nrev, fail; true)).
% Zeit 588 ms, GC 0 ms, Lips 5113263, Uhr 11.08.2024 10:47
true.

/* Trealla Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
% Time elapsed 0.549s, 3000503 Inferences, 5.468 MLips
    true.

/* Scryer Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
    % CPU time: 0.302s, 3_024_526 inferences
    true.

/* SWI-Prolog */
?- time((between(1,6001,_), nrev, fail; true)).
% 2,994,499 inferences, 0.078 CPU in 0.089 seconds (88% CPU, 38329587
Lips)
true.

Dogelog Player has a Prolog compiler written in
Prolog itself. But the limiting factor is of course
always the runtime engine itself, that executes the

compiled code. You can inline and optimize whatever
you want, if the runtime engine, its architecture,
has some limitations performance wise, you won't

see aby speed. I don't know yet whether I will beat
SWI-Prolog in this test case ever in the near future?
Especially with some cheap effort?

Mild Shock schrieb:

Just look at GitHub issues and sort by "recent update".
I get for the last week the following figures:

- New tickets: 7 new tickets
- Closed tickets: 2 closed tickets

To get a turn around you the the 2nd number bigger
that the 1st number, and not the other way around.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Another prolog system which succumbs to
the bomb.p test case:

$ ulimit -m 2000000
$ ulimit -v 2000000
$ ./tpl -v
Trealla Prolog (c) Infradig 2020-2024, v2.55.18
$ ./tpl
?- ['bomb.p'].
?- foo.
throw(error(resource_error(memory),app/3)).

But on my side not everything is joy
that makes us unique. The matter is
difficult to adjust:

with Machine.GC_MAX_INFERS = 200000 it crashes:

/* Dogelog Player for Java */
?- foo.
Error: Execution aborted because out of memory.

with Machine.GC_MAX_INFERS = 100000 it does not crash:

/* Dogelog Player for Java */
?- foo.
%%% I can go for lunch and come back, it still runs.

How can I find the right value for GC_MAX_INFERS ?
Call a witch doctor and ask his oracle bones?

Mild Shock schrieb:

The test case that crashes all these new
Prolog systems, is for example this one.
It still crashes Scryer Prolog:

$ ulimit -m 2000000
$ ulimit -v 2000000
$ target/release/scryer-prolog -v
v0.9.4-135-g7cfe8ee5

$ target/release/scryer-prolog
?- [user].
app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).
garbage(0, [0]) :- !.
garbage(N, L) :- M is N-1, garbage(M, R), app(R, R, L).
foo :- garbage(12,_), foo.

?- foo.
memory allocation of 2147483648 bytes failed
Aborted

The above preferably runs indefinitely. For
example SWI-Prolog can run it indefinitely.
It also crashes other Prolog systems:

$ ~/go/bin/1pl
Top level for ichiban/prolog v1.2.1
This is for testing purposes only!
See https://github.com/ichiban/prolog for more details.
Type Ctrl-C or 'halt.' to exit.

?- ['bomb.p'].
true.
?- foo.
runtime: out of memory:
cannot allocate 4194304-byte block (802816000 in use)

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

Hi,

What boosted at that time automated
Program verification, and maybe a broader
use of Stärks approach was the Java virtual

machine. A lot of papers poped up at
that time, doing something with JVM
and automated program verification.

Also from that time:

A security logic for abstract state machines https://www.research-collection.ethz.ch/handle/20.500.11850/68777

Axioms for strict and lazy functional programs https://www.research-collection.ethz.ch/handle/20.500.11850/68772

Bye

Mild Shock schrieb:

Hi,

I remember Robert Stärk's disappearing from
academic life at ETH Zurich all of a sudden.
Did Ulrich Neumerkel now also disappeared not

because the Scryer Prolog disaster, but after
he figured out that failure slices are not hip
enought? What could be more hip, are the modalities

of Robert Stärk's logic more hip now and even useful?

Automated Theorem Proving for Prolog Verification
Fred Mesnard etc.. May 2024 https://lim.univ-reunion.fr/staff/fred/Publications/24-MesnardMP-slides.pdf

Disclaimer: I am not deep into this theory,
it has some ingredients that were floating around
the 80's / 80's, not only in the millieau of ETH Zurich,

but also in the vincinity of Gehard Jaeger, Bern.
There are many alternative formalizations that
can express termination etc.. But maybe LPTP is

especially suited for Prolog?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

I can make a case of such a comparison,
DCG pipe dream versus proper look-ahead:

/* Scryer Prolog 0.9.4-135 */
?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)).
% CPU time: 0.283s, 2_506_022 inferences
true.

/* SWI-Prolog 9.3.8 */
?- time((between(1,1000,_), data(X), atom_json_term(X,Y,[]), fail; true)).
% 44,998 inferences, 0.016 CPU in 0.006 seconds (281% CPU, 2879872 Lips)
true.

I think the speed difference of a factor
20x is not because of native float parsing.
The example doesn’t have much float:

data("{ \"a\":123 }").

So whats the bug in the DCG parser by
Scryer Prolog? Why does the parser written by
Jan W. not have the same defect?

Why does the number of inferences differ so much?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.prolog

The time complexity of a look ahead
parser with one word token look ahead and
one character look ahead, and Prolog code

that is optimized towards clauses that
use first argument indexing, you can view
it as a kind of table driven parser with

push down, althought its Prolog, should be only
O(N+M), where N=number of characters and M=number of
words. It has linear complexity and not

something else. In 1965 Donald Knuth proposed
LR(k) parser, which are bottom up, but the idea
here is LL(k) parser, which are top down.

Both parsing algorithms run in linear time.

Mild Shock schrieb:

I can make a case of such a comparison,
DCG pipe dream versus proper look-ahead:

/* Scryer Prolog 0.9.4-135 */
?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)).
   % CPU time: 0.283s, 2_506_022 inferences
   true.

/* SWI-Prolog 9.3.8 */
?- time((between(1,1000,_), data(X), atom_json_term(X,Y,[]), fail; true)).
% 44,998 inferences, 0.016 CPU in 0.006 seconds (281% CPU, 2879872 Lips) true.

I think the speed difference of a factor
20x is not because of native float parsing.
The example doesn’t have much float:

data("{                                   \"a\":123 }").

So whats the bug in the DCG parser by
Scryer Prolog? Why does the parser written by
Jan W. not have the same defect?

Why does the number of inferences differ so much?

--- Synchronet 3.20a-Linux NewsLink 1.114