@MSGID:
<9adc813b-8b5b-4e4e-a823-f7d6af5c6e57n@googlegroups.com> 7b1c9a48
@REPLY:
<02c12d31-31dd-436d-b3ac-26379ccc6522n@googlegroups.com> 65e35562
@REPLYADDR Mild Shock <bursejan@gmail.com>
@REPLYTO 2:5075/128 Mild Shock
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<616590d2-4927-4f60-ba91-acef849695a3n@googlegroups.com> <b4fe1397-91ae-472c-9365-dbd8e0937f27n@googlegroups.com>
<a6ed877b-5d7d-4404-b41c-ee58c12ba6a0n@googlegroups.com> <5848823c-8c71-4d67-8dc0-42a72aaa95acn@googlegroups.com>
<f3083699-800d-45c6-b622-cea67bac91fbn@googlegroups.com> <02c12d31-31dd-436d-b3ac-26379ccc6522n@googlegroups.com>
@RFC-Message-ID:
<9adc813b-8b5b-4e4e-a823-f7d6af5c6e57n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441