Re: Is Scryer Prologs failure measurable? (Was: Holy Grail makes People Disappear)

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?

>

>