I am still fiddling around with (is)/2 implementation.
Formerly Jekejeke Prolog had traditionally automatic
bridging and tunneling. This is all going down the drain,

we want to become more GNU Prolog compatible. Novacore
should be as puritanical as possible, namely a Prolog core that
has an upbringing that disapproves the suggar laced world of

formerly Jekejeke Prolog! Funny discovery, not all Prolog
systems throw the same evaluable errors. Here a little
discrepancy between GNU Prolog and SWI-Prolog:

/* GNU Prolog */
?- X is append(1,2).
uncaught exception: error(type_error(evaluable,append/2),(is)/2)
?- X is append([1,2],[3]).
uncaught exception: error(type_error(evaluable,append/2),(is)/2)

/* SWI-Prolog */
?- X is append(1,2).
ERROR: Arithmetic: `append/2' is not a function
?- X is append([1,2],[3]).
ERROR: Type error: `[]' expected, found `[1,2]' (a list)
("x" must hold one character)

My newest take in formerly Jekejeke Prolog and Dogelog
Player, now behaving the same for this test case. This
is a preview, these versions have not yet been officially released:

/* Jekejeke Prolog, 1.6.3 */
?- X is append(1,2).
Error: Argument should have evaluable functor, found append/2.
?- X is append([1,2],[3]).
Error: Argument should have evaluable functor, found append/2.

/* Dogelog Player, 1.1.1, nodeJS */
?- X is append(1,2).
Error: Argument should have evaluable functor, found append/2.
?- X is append([1,2],[3]).
Error: Argument should have evaluable functor, found append/2.

/* Dogelog Player, 1.1.1, PyPy */
?- X is append(1,2).
Error: Argument should have evaluable functor, found append/2.
?- X is append([1,2],[3]).
Error: Argument should have evaluable functor, found append/2.

Mild Shock schrieb am Samstag, 9. September 2023 um 20:09:47 UTC+2:
> I am still fiddling around with (is)/2 implementation.
> Formerly Jekejeke Prolog had traditionally automatic
> bridging and tunneling. This is all going down the drain,
>
> we want to become more GNU Prolog compatible. Novacore
> should be as puritanical as possible, namely a Prolog core that
> has an upbringing that disapproves the suggar laced world of
>
> formerly Jekejeke Prolog! Funny discovery, not all Prolog
> systems throw the same evaluable errors. Here a little
> discrepancy between GNU Prolog and SWI-Prolog:
>
> /* GNU Prolog */
> ?- X is append(1,2).
> uncaught exception: error(type_error(evaluable,append/2),(is)/2)
> ?- X is append([1,2],[3]).
> uncaught exception: error(type_error(evaluable,append/2),(is)/2)
>
> /* SWI-Prolog */
> ?- X is append(1,2).
> ERROR: Arithmetic: `append/2' is not a function
> ?- X is append([1,2],[3]).
> ERROR: Type error: `[]' expected, found `[1,2]' (a list)
> ("x" must hold one character)

I started using this test case:

test :-
between(0,1000000,N),
_ is exp(1+N/1000000),
fail.
test.

To test a new Java foreign function interface. I then
observed that SWI-Prolog stack engine causes
a little overhead:

/* SWI-Prolog, 9.1.14, optimise=false */
?- time(test).
% 2,000,001 inferences, 0.313 CPU in 0.315 seconds
(99% CPU, 6400003 Lips)
true.

/* SWI-Prolog, 9.1.14, optimise=true */
?- time(test).
% 1,000,002 inferences, 0.172 CPU in 0.176 seconds
(98% CPU, 5818193 Lips)
true.

Intrestingly GNU Prolog doesn’t use a stack engine,
just relies on the native stack. Its quite speedy without
any optimisation:

/* GNU Prolog 1.5.0 (64 bits) */
?- test.
(125 ms) yes

The internal call is tail recursive I guess, since the functor is
already checked, and a looked up handle, a function pointer,
causes the evaluation. Recently GNU Prolog has moved to GitHub,

so I can find the source code of GNU Prolog stuff more easily, things
like Load_Math_Expression. But I think the GNU Prolog approach is
only feasible, if you dare to rely on the native stack.

Concerning the new Java foreign function interface. I switched
from handles obtained by method reflection to handles that were
populated via functional interfaces. Its an itch faster, and close

to SWI-Prolog optimised, but only for JDK 8:

/* Jekejeke Prolog, 1.6.3, JDK 8, Functional Interface */
?- time(test).
% Time 171 ms, GC 2 ms, Wall 09/09/2023 22:04
true.

The above uses the native stack like GNU Prolog and no
cycle testing nothing. But I guess it burns CPU since it uses
two pointers to represent a term. I hope I can soon get rid of that.

Another brake could be the varargs array allocation.

Mild Shock schrieb am Samstag, 9. September 2023 um 22:17:13 UTC+2:
> I started using this test case:
>
> test :-
> between(0,1000000,N),
> _ is exp(1+N/1000000),
> fail.
> test.
>
> To test a new Java foreign function interface. I then
> observed that SWI-Prolog stack engine causes
> a little overhead:
>
> /* SWI-Prolog, 9.1.14, optimise=false */
> ?- time(test).
> % 2,000,001 inferences, 0.313 CPU in 0.315 seconds
> (99% CPU, 6400003 Lips)
> true.
>
> /* SWI-Prolog, 9.1.14, optimise=true */
> ?- time(test).
> % 1,000,002 inferences, 0.172 CPU in 0.176 seconds
> (98% CPU, 5818193 Lips)
> true.
>
> Intrestingly GNU Prolog doesn’t use a stack engine,
> just relies on the native stack. Its quite speedy without
> any optimisation:
>
> /* GNU Prolog 1.5.0 (64 bits) */
> ?- test.
> (125 ms) yes

Ok there is a big confusion in SWI-Prolog discourse, I was
mentioning native stack, and people think I was talking
about native code. Holy cow! Do I speak chinese, or what?

Just look for yourself. Step 1: Go to GNU Prolog GitHub,
Step 2: Lookup the C function Load_Math_Expression
Interesting find, for Dogelog Player on CPython so far:

/* Dogelog Player 1.1.1, CPython */
?- X=1+X, Y is X.
Unknown exception: 'maximum recursion depth exceeded'

What does PyPy do? What does JavaScript do? How do we
handle this exception. Are there more candidates than only (is)/2,
like for example copy_term/2, etc.. This would cover Dogelog

Player. What about formerly Jekejeke Prolog, respectively Java?

Mild Shock schrieb am Samstag, 9. September 2023 um 22:18:21 UTC+2:
> The internal call is tail recursive I guess, since the functor is
> already checked, and a looked up handle, a function pointer,
> causes the evaluation. Recently GNU Prolog has moved to GitHub,
>
> so I can find the source code of GNU Prolog stuff more easily, things
> like Load_Math_Expression. But I think the GNU Prolog approach is
> only feasible, if you dare to rely on the native stack.
>
> Concerning the new Java foreign function interface. I switched
> from handles obtained by method reflection to handles that were
> populated via functional interfaces. Its an itch faster, and close
>
> to SWI-Prolog optimised, but only for JDK 8:
>
> /* Jekejeke Prolog, 1.6.3, JDK 8, Functional Interface */
> ?- time(test).
> % Time 171 ms, GC 2 ms, Wall 09/09/2023 22:04
> true.
>
> The above uses the native stack like GNU Prolog and no
> cycle testing nothing. But I guess it burns CPU since it uses
> two pointers to represent a term. I hope I can soon get rid of that.
>
> Another brake could be the varargs array allocation.
> Mild Shock schrieb am Samstag, 9. September 2023 um 22:17:13 UTC+2:
> > I started using this test case:
> >
> > test :-
> > between(0,1000000,N),
> > _ is exp(1+N/1000000),
> > fail.
> > test.
> >
> > To test a new Java foreign function interface. I then
> > observed that SWI-Prolog stack engine causes
> > a little overhead:
> >
> > /* SWI-Prolog, 9.1.14, optimise=false */
> > ?- time(test).
> > % 2,000,001 inferences, 0.313 CPU in 0.315 seconds
> > (99% CPU, 6400003 Lips)
> > true.
> >
> > /* SWI-Prolog, 9.1.14, optimise=true */
> > ?- time(test).
> > % 1,000,002 inferences, 0.172 CPU in 0.176 seconds
> > (98% CPU, 5818193 Lips)
> > true.
> >
> > Intrestingly GNU Prolog doesn’t use a stack engine,
> > just relies on the native stack. Its quite speedy without
> > any optimisation:
> >
> > /* GNU Prolog 1.5.0 (64 bits) */
> > ?- test.
> > (125 ms) yes

Is there any use case for the cycle check? It gives an error more earlier.
If one has a resource quota, one would also get an error only a little bit
later, when the stack is to large and some memory is exhausted.

Here is a sketch of a post mortem analysis, even written in 100%
pure Prolog, which gives an error analysis service:

X is Y :-
catch(eval(Y,X), error(foo,_),
(acyclic_term(Y) -> throw(error(bar,_)); throw(error(baz,_)))).

The single error “foo” produced by the internal eval/2 predicate
is changed into either an error “bar” or an error “baz”, to provide the
end-user some more information. Can be also implemented

natively by the builtin is/2, making a cycle test during eval/2
unnecessary, since acyclic_term/1 exists. Or is there a danger
that acyclic_term/1 crashes? It probably uses less stack than eval/2.

Mild Shock schrieb am Sonntag, 10. September 2023 um 23:45:55 UTC+2:
> Ok there is a big confusion in SWI-Prolog discourse, I was
> mentioning native stack, and people think I was talking
> about native code. Holy cow! Do I speak chinese, or what?
>
> Just look for yourself. Step 1: Go to GNU Prolog GitHub,
> Step 2: Lookup the C function Load_Math_Expression
> Interesting find, for Dogelog Player on CPython so far:
>
> /* Dogelog Player 1.1.1, CPython */
> ?- X=1+X, Y is X.
> Unknown exception: 'maximum recursion depth exceeded'
>
> What does PyPy do? What does JavaScript do? How do we
> handle this exception. Are there more candidates than only (is)/2,
> like for example copy_term/2, etc.. This would cover Dogelog
>
> Player. What about formerly Jekejeke Prolog, respectively Java?
> Mild Shock schrieb am Samstag, 9. September 2023 um 22:18:21 UTC+2:
> > The internal call is tail recursive I guess, since the functor is
> > already checked, and a looked up handle, a function pointer,
> > causes the evaluation. Recently GNU Prolog has moved to GitHub,
> >
> > so I can find the source code of GNU Prolog stuff more easily, things
> > like Load_Math_Expression. But I think the GNU Prolog approach is
> > only feasible, if you dare to rely on the native stack.
> >
> > Concerning the new Java foreign function interface. I switched
> > from handles obtained by method reflection to handles that were
> > populated via functional interfaces. Its an itch faster, and close
> >
> > to SWI-Prolog optimised, but only for JDK 8:
> >
> > /* Jekejeke Prolog, 1.6.3, JDK 8, Functional Interface */
> > ?- time(test).
> > % Time 171 ms, GC 2 ms, Wall 09/09/2023 22:04
> > true.
> >
> > The above uses the native stack like GNU Prolog and no
> > cycle testing nothing. But I guess it burns CPU since it uses
> > two pointers to represent a term. I hope I can soon get rid of that.
> >
> > Another brake could be the varargs array allocation.
> > Mild Shock schrieb am Samstag, 9. September 2023 um 22:17:13 UTC+2:
> > > I started using this test case:
> > >
> > > test :-
> > > between(0,1000000,N),
> > > _ is exp(1+N/1000000),
> > > fail.
> > > test.
> > >
> > > To test a new Java foreign function interface. I then
> > > observed that SWI-Prolog stack engine causes
> > > a little overhead:
> > >
> > > /* SWI-Prolog, 9.1.14, optimise=false */
> > > ?- time(test).
> > > % 2,000,001 inferences, 0.313 CPU in 0.315 seconds
> > > (99% CPU, 6400003 Lips)
> > > true.
> > >
> > > /* SWI-Prolog, 9.1.14, optimise=true */
> > > ?- time(test).
> > > % 1,000,002 inferences, 0.172 CPU in 0.176 seconds
> > > (98% CPU, 5818193 Lips)
> > > true.
> > >
> > > Intrestingly GNU Prolog doesn’t use a stack engine,
> > > just relies on the native stack. Its quite speedy without
> > > any optimisation:
> > >
> > > /* GNU Prolog 1.5.0 (64 bits) */
> > > ?- test.
> > > (125 ms) yes