Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.prolog > #13157 > unrolled thread

Request for comments, Novacore the sequel to ISO modules

Back to article view | Back to comp.lang.prolog

Contents

  Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-17 05:18 -0700
    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-17 06:37 -0700
      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-17 07:00 -0700
        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-17 13:28 -0700
          Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-31 02:59 -0700
            Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-31 03:04 -0700
              Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-31 03:10 -0700
                Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-31 10:18 -0700
                  Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-31 10:22 -0700
                    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 16:06 -0700
                      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 16:12 -0700
                        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 16:13 -0700
                          Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 16:14 -0700
                            Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 23:57 -0700
                              Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 23:59 -0700
                                Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-12 05:11 -0700
                                  Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-12 10:46 -0700
                                    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-12 10:48 -0700
                                      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-12 13:22 -0700
                                        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 05:53 -0700
                                          Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 07:32 -0700
                                            Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 11:16 -0700
                                              Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 11:18 -0700
                                                Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 11:36 -0700
                                                  Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 13:28 -0700
                                                    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-14 01:41 -0700
                                                      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-14 01:43 -0700
                                                        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-14 07:41 -0700
    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <janburse@fastmail.fm> - 2022-10-15 14:30 +0200
      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 07:42 -0700
        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 07:50 -0700
        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 07:51 -0700
          Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 07:52 -0700
            Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 18:55 -0700
              Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 18:58 -0700
                Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 19:46 -0700
                  Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-25 05:55 -0700
                    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-25 05:59 -0700
                      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-25 08:36 -0700
                        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-25 10:53 -0700
                          Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-26 07:01 -0700
                            Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-26 07:02 -0700
                              Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-11-14 14:21 -0800
                                Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-11-14 14:31 -0800
                                  Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-11-17 06:08 -0800
                                    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-11-17 06:21 -0800
    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-11 12:45 -0800
      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-11 12:52 -0800
        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-11 14:24 -0800
          Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-13 01:56 -0800
            Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-13 01:58 -0800
              Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-13 01:59 -0800
              Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-13 02:01 -0800
                Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-13 04:49 -0800
                  Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-16 15:03 -0800
                    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-16 15:07 -0800
                      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-17 00:49 -0800
                        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-17 03:22 -0800
                          Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-02-27 03:08 -0800
                            Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-02-27 03:08 -0800
                              Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-02-27 10:31 -0800
                                Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-02-27 10:33 -0800
                                  Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-02-27 16:05 -0800
                                    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-01 09:01 -0800
                                      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-01 09:02 -0800
                                    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-02 04:06 -0800
                                      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-02 04:08 -0800
                                        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-08 01:45 -0800
                                          Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-08 01:47 -0800
    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-18 05:55 -0700
      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-18 05:56 -0700
        Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-18 06:01 -0700
          Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-18 06:06 -0700
    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-05-13 06:36 -0700
      Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-05-13 06:41 -0700
    Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-05-21 03:54 -0700
      Differences among the "bomb" and "xbetween" (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-09-24 17:10 +0200
        The issue with free speech Mild Shock <janburse@fastmail.fm> - 2024-10-09 15:29 +0200
          failure of formal verification [software.imdea.org] (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-11-06 09:33 +0100
            Re: failure of formal verification [software.imdea.org] (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-11-06 09:35 +0100
              Re: failure of formal verification [software.imdea.org] (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-11-06 09:37 +0100
        variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-10-12 22:02 +0200
          Re: variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-10-12 23:16 +0200
          Re: variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-10-12 23:34 +0200
            Re: variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-10-13 00:54 +0200
    Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <bursejan@gmail.com> - 2023-07-29 04:51 -0700
      Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <bursejan@gmail.com> - 2023-09-07 17:15 -0700
        Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <janburse@fastmail.fm> - 2023-11-19 19:56 +0100
          Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <janburse@fastmail.fm> - 2023-11-19 19:59 +0100
            Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <janburse@fastmail.fm> - 2023-11-19 20:01 +0100
      New milestone float formatting [LoL] (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-07-28 14:32 +0200
        Re: New milestone float formatting [LoL] (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-07-28 14:38 +0200
          Re: New milestone float formatting [LoL] (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-07-28 16:42 +0200
            Re: Differences among the "bomb" and "xbetween" (Was: New milestone float formatting [LoL]) Mild Shock <janburse@fastmail.fm> - 2024-09-24 17:20 +0200
              New milestone time formatting (Was: Differences among the "bomb" and "xbetween") Mild Shock <janburse@fastmail.fm> - 2024-09-26 13:22 +0200
        More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404] Mild Shock <janburse@fastmail.fm> - 2024-10-09 09:43 +0200
          Even More Prolog Improvement Proposals (PIPs) [PIP301 - PIP303] (Was: More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404]) Mild Shock <janburse@fastmail.fm> - 2024-10-09 09:45 +0200
            Re: Even More Prolog Improvement Proposals (PIPs) [PIP301 - PIP303] (Was: More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404]) Mild Shock <janburse@fastmail.fm> - 2024-10-09 10:00 +0200
              Re: Even More Prolog Improvement Proposals (PIPs) [PIP301 - PIP303] (Was: More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404]) Mild Shock <janburse@fastmail.fm> - 2024-10-09 11:22 +0200
      A FFI for evaluable functions Mild Shock <janburse@fastmail.fm> - 2024-10-10 00:14 +0200
        Name resolution is a blackbox (Re: A FFI for evaluable functions) Mild Shock <janburse@fastmail.fm> - 2024-10-10 00:16 +0200
          plonk in discourse (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-10-10 00:48 +0200
            When do two Prolog terms marry? (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-10-14 19:15 +0200
              Re: When do two Prolog terms marry? (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-10-14 19:22 +0200
              native implementation of variant/2 can be fast (Was: When do two Prolog terms marry?) Mild Shock <janburse@fastmail.fm> - 2024-10-15 01:35 +0200
        KISS principle pays off (Was: A FFI for evaluable functions) Mild Shock <janburse@fastmail.fm> - 2024-11-03 00:52 +0100
      Waste of EU money / bread and butter of statistics (Was: failure of formal verification [software.imdea.org]) Mild Shock <janburse@fastmail.fm> - 2024-11-06 09:51 +0100
        Re: Waste of EU money / bread and butter of statistics (Was: failure of formal verification [software.imdea.org]) Mild Shock <janburse@fastmail.fm> - 2024-11-06 10:09 +0100
        Re: Waste of EU money / bread and butter of statistics (Was: failure of formal verification [software.imdea.org]) Julio Di Egidio <julio@diegidio.name> - 2024-11-06 10:43 +0100
          SICStus Prolog is overrated (Was: Waste of EU money / bread and butter of statistics) Mild Shock <janburse@fastmail.fm> - 2024-11-06 12:57 +0100
            Crashing under its own bloath, Scryer Prolog (Was: SICStus Prolog is overrated) Mild Shock <janburse@fastmail.fm> - 2024-11-06 13:03 +0100
              “Luce,” which is Italian for “light.” (Was: Crashing under its own bloath, Scryer Prolog) Mild Shock <janburse@fastmail.fm> - 2024-11-06 13:12 +0100
                More Poisened Meat balls? [NIVIDIA & OpenAI] (Way: “Luce,” which is Italian for “light.”) Mild Shock <janburse@fastmail.fm> - 2024-11-06 13:33 +0100
                  Re: More Poisened Meat balls? [NIVIDIA & OpenAI] (Way: “Luce,” which is Italian for “light.”) Julio Di Egidio <julio@diegidio.name> - 2024-11-06 14:17 +0100
      Not all Red-Black Trees are Okasaki (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-11-07 00:59 +0100
    Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <bursejan@gmail.com> - 2023-11-19 10:54 -0800

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#13479

If you have fibers, you also don’t need any locking. At least not for
basic operations like assert/1, retract/1, etc… since they still run single
threaded if you don’t yield during these operations. But on

the other hand try this in the current SWI-Prolog WASM shell:

?- call_with_time_limit(0.5, (repeat, fail)).
ERROR: Unhandled exception: toplevel: Unknown procedure:
call_with_time_limit/2 (DWIM could not correct goal)
https://dev.swi-prolog.org/wasm/shell

Surprisingly, since this weekend, I can do the following
in Dogelog Player for Python, the predicate time_out/2 accepts
milliseconds and has the arguments in different order:

?- time_out((repeat, fail), 500).
Error: system_error(timelimit_exceeded)
        user:1
And I didn’t use threads, so how did I do it? BTW: I don’t know
whether Tau Prolog can demonstrate it. They have demonstrated
something else, multiple Prolog threads trying to reach a finish line.

I am not yet there at the Tau Prolog calibre of fibers, step by step
wondering currently how signal handling can be done.

Mostowski Collapse schrieb am Montag, 27. Februar 2023 um 12:09:01 UTC+1:
> A bonus would be if the Prolog system had event 
> loops in its Workers by default, so that kind of fibers 
> would be available, and one would still have some benefits 
> 
> of a multi-threaded Prolog system, just do it async 
> in the same thread. Maybe a couple service threads besides 
> the workers threads nevertheless, so that for example 
> 
> things like call_with_time_limit/2 still work. Maybe such a 
> Worker Prolog could be bootstrapped from a multi-threaded 
> Prolog system by changing some defaults, for example 
> 
> that predicates are by default this new form of thread local.
> Mostowski Collapse schrieb am Montag, 27. Februar 2023 um 12:08:12 UTC+1: 
> > Could a Novacore also be a Worker Prolog? One coul 
> > imagine a Prolog system where all predicates are by 
> > default thread local, and where threads can only 
> > 
> > share information through message passing. You would 
> > more or less get JavaScript Workers. Such a Prolog system 
> > would not anymore need synchronization of predicates, 
> > 
> > neither needed for static nor dynamic predicates. I am 
> > currently wondering whether I can build such a Prolog variant 
> > and what the performance would be? But a special form of 
> > 
> > thread local would be needed, since the predicate needs not be 
> > visible among multiple workers.

[toc] | [prev] | [next] | [standalone]

#13480

Relatively straight forward using Python fibers. Only they are not
called fibers, the are call coroutines. For example the new
built-in to schedule an alarm is implemented as follows in Python:

    loop = asyncio.get_running_loop()
    res = loop.call_later(delay/1000.0, alarm_abort)

The same works also for JavaScript now, using an API with some
different names, but also based on an event loop I guess. Thats
the magic of fibers, they are inbetween single threaded and

multi-threaded. The alarm_abort callback in the above posts a
signal, which gets taken note by the auto-yielding interpreter. The
behaviour is very similar to a multi-threaded Prolog alarm,

or a single-threaded Prolog alarm that uses some operating
system service for the signalling.

Mostowski Collapse schrieb am Montag, 27. Februar 2023 um 19:31:36 UTC+1:
> If you have fibers, you also don’t need any locking. At least not for 
> basic operations like assert/1, retract/1, etc… since they still run single 
> threaded if you don’t yield during these operations. But on 
> 
> the other hand try this in the current SWI-Prolog WASM shell: 
> 
> ?- call_with_time_limit(0.5, (repeat, fail)). 
> ERROR: Unhandled exception: toplevel: Unknown procedure: 
> call_with_time_limit/2 (DWIM could not correct goal) 
> https://dev.swi-prolog.org/wasm/shell 
> 
> Surprisingly, since this weekend, I can do the following 
> in Dogelog Player for Python, the predicate time_out/2 accepts 
> milliseconds and has the arguments in different order: 
> 
> ?- time_out((repeat, fail), 500). 
> Error: system_error(timelimit_exceeded) 
> user:1 
> And I didn’t use threads, so how did I do it? BTW: I don’t know 
> whether Tau Prolog can demonstrate it. They have demonstrated 
> something else, multiple Prolog threads trying to reach a finish line. 
> 
> I am not yet there at the Tau Prolog calibre of fibers, step by step 
> wondering currently how signal handling can be done.
> Mostowski Collapse schrieb am Montag, 27. Februar 2023 um 12:09:01 UTC+1: 
> > A bonus would be if the Prolog system had event 
> > loops in its Workers by default, so that kind of fibers 
> > would be available, and one would still have some benefits 
> > 
> > of a multi-threaded Prolog system, just do it async 
> > in the same thread. Maybe a couple service threads besides 
> > the workers threads nevertheless, so that for example 
> > 
> > things like call_with_time_limit/2 still work. Maybe such a 
> > Worker Prolog could be bootstrapped from a multi-threaded 
> > Prolog system by changing some defaults, for example 
> > 
> > that predicates are by default this new form of thread local. 
> > Mostowski Collapse schrieb am Montag, 27. Februar 2023 um 12:08:12 UTC+1: 
> > > Could a Novacore also be a Worker Prolog? One coul 
> > > imagine a Prolog system where all predicates are by 
> > > default thread local, and where threads can only 
> > > 
> > > share information through message passing. You would 
> > > more or less get JavaScript Workers. Such a Prolog system 
> > > would not anymore need synchronization of predicates, 
> > > 
> > > neither needed for static nor dynamic predicates. I am 
> > > currently wondering whether I can build such a Prolog variant 
> > > and what the performance would be? But a special form of 
> > > 
> > > thread local would be needed, since the predicate needs not be 
> > > visible among multiple workers.

[toc] | [prev] | [next] | [standalone]

#13483

Is this Worker Prolog part of Novacore. Well Yes and
No. Novacore is supposed to be a core without any libraries,
reduced to the minimum. So it can be the basis for 

a multitude of things, like:

Multi-Threaded Prolog    ----\
Single-Threaded Prolog   ---+-----> Novacore
Worker Fiber Prolog      ------/

Thats why I am currently moving all kind of
libraries out of formerly Jekejeke Prolog Runtime,
to a different place, threads are gone, locks are

gone, pipes are gone, directories are gone, everything
is gone. Maybe Workers will come? Who knows.
Maybe Worker Fibers will come?

I am not 100% sure whether Workers always need
Fibers? Well there is one use case. If a Worker
needs to be abortable, this could be done

by a auto-yielding Prolog system running inside
the Worker. See Prolog of Ciao Playground. So
I guess one has to think as a Worker Prolog not

as a Multi-Threaded Prolog rather as a Multi-Single-
Threaded Prolog, where each Thread is Single in
that it is isolated from the other Threads, doesn't

see their predicates, and the fiber makes an easy
solution to abort such a Thread. In Java its done
differently. There most all Multi-Threaded APIs are

abortable from the outside, but to abort a Prolog
interpreter you still need something else, since
you don't necessarily call Multi-Threaded APIs

all the time. So polling some signal or auto-yielding
is essentially the same. 

Mostowski Collapse schrieb am Montag, 27. Februar 2023 um 19:33:05 UTC+1:
> Relatively straight forward using Python fibers. Only they are not 
> called fibers, the are call coroutines. For example the new 
> built-in to schedule an alarm is implemented as follows in Python: 
> 
> loop = asyncio.get_running_loop() 
> res = loop.call_later(delay/1000.0, alarm_abort) 
> 
> The same works also for JavaScript now, using an API with some 
> different names, but also based on an event loop I guess. Thats 
> the magic of fibers, they are inbetween single threaded and 
> 
> multi-threaded. The alarm_abort callback in the above posts a 
> signal, which gets taken note by the auto-yielding interpreter. The 
> behaviour is very similar to a multi-threaded Prolog alarm, 
> 
> or a single-threaded Prolog alarm that uses some operating 
> system service for the signalling.
> Mostowski Collapse schrieb am Montag, 27. Februar 2023 um 19:31:36 UTC+1: 
> > If you have fibers, you also don’t need any locking. At least not for 
> > basic operations like assert/1, retract/1, etc… since they still run single 
> > threaded if you don’t yield during these operations. But on 
> > 
> > the other hand try this in the current SWI-Prolog WASM shell: 
> > 
> > ?- call_with_time_limit(0.5, (repeat, fail)). 
> > ERROR: Unhandled exception: toplevel: Unknown procedure: 
> > call_with_time_limit/2 (DWIM could not correct goal) 
> > https://dev.swi-prolog.org/wasm/shell 
> > 
> > Surprisingly, since this weekend, I can do the following 
> > in Dogelog Player for Python, the predicate time_out/2 accepts 
> > milliseconds and has the arguments in different order: 
> > 
> > ?- time_out((repeat, fail), 500). 
> > Error: system_error(timelimit_exceeded) 
> > user:1 
> > And I didn’t use threads, so how did I do it? BTW: I don’t know 
> > whether Tau Prolog can demonstrate it. They have demonstrated 
> > something else, multiple Prolog threads trying to reach a finish line. 
> > 
> > I am not yet there at the Tau Prolog calibre of fibers, step by step 
> > wondering currently how signal handling can be done. 
> > Mostowski Collapse schrieb am Montag, 27. Februar 2023 um 12:09:01 UTC+1: 
> > > A bonus would be if the Prolog system had event 
> > > loops in its Workers by default, so that kind of fibers 
> > > would be available, and one would still have some benefits 
> > > 
> > > of a multi-threaded Prolog system, just do it async 
> > > in the same thread. Maybe a couple service threads besides 
> > > the workers threads nevertheless, so that for example 
> > > 
> > > things like call_with_time_limit/2 still work. Maybe such a 
> > > Worker Prolog could be bootstrapped from a multi-threaded 
> > > Prolog system by changing some defaults, for example 
> > > 
> > > that predicates are by default this new form of thread local. 
> > > Mostowski Collapse schrieb am Montag, 27. Februar 2023 um 12:08:12 UTC+1: 
> > > > Could a Novacore also be a Worker Prolog? One coul 
> > > > imagine a Prolog system where all predicates are by 
> > > > default thread local, and where threads can only 
> > > > 
> > > > share information through message passing. You would 
> > > > more or less get JavaScript Workers. Such a Prolog system 
> > > > would not anymore need synchronization of predicates, 
> > > > 
> > > > neither needed for static nor dynamic predicates. I am 
> > > > currently wondering whether I can build such a Prolog variant 
> > > > and what the performance would be? But a special form of 
> > > > 
> > > > thread local would be needed, since the predicate needs not be 
> > > > visible among multiple workers.

[toc] | [prev] | [next] | [standalone]

#13486

Are lazy streams fibers? Not really.

If you preform engine yield, you just land in the parent
context of the current execution. You don’t temporarily
suspend the current execution. You need an event loop

for that. But all the papers by Tarau, Wielemaker and
Schrijvers never discuss that. You could also imagine a
new Prolog language, with two new operators async/1

and await/1. For example one could write a bankteller
web worker only with fibers, and one could
produce code as follows:

:- async withdraw/2.
withdraw(Amount) :-
      await do_something,
      retact(account(Current)),
      Current2 is Curent-Amount,
      assertz(account(Current2)),
      await do_something2.

Since the retract/assertz combo is not interleaved with an
await statement, we know that noting will yield while executing
the combo, and the effect is as if it were a critical region. But

locks or atomics are not needed. You have to switch off auto-
yielding for such a code as above, no auto-yielding is also the
default execution mode of JavaScript, and you could apply

the same reasoning to JavaScript.

[toc] | [prev] | [next] | [standalone]

#13487

Maybe good name for such a language would be
Fibertalk. It would have a linter with some style checks.
Like if a body goal has an await/1, but the head predicate

doesn’t have async/1, there would be a warning or error.
But you can implement async/1 and await/1 extremly simple.
They are only declarations as a kind of program documentation

and are also useful for the linter, but for execution they do nothing:

async(_).
await(G) :- G.

To implement them as above is possible for a Prolog
system with fibers that can yield anywhere. It might be
as well the case, that for JavaScript the keywords are

also only decoration? Not sure. The decoration goes also
into attributes of objects such as “Function” in JavaScript.

Mostowski Collapse schrieb am Mittwoch, 1. März 2023 um 18:01:19 UTC+1:
> Are lazy streams fibers? Not really. 
> 
> If you preform engine yield, you just land in the parent 
> context of the current execution. You don’t temporarily 
> suspend the current execution. You need an event loop 
> 
> for that. But all the papers by Tarau, Wielemaker and 
> Schrijvers never discuss that. You could also imagine a 
> new Prolog language, with two new operators async/1 
> 
> and await/1. For example one could write a bankteller 
> web worker only with fibers, and one could 
> produce code as follows: 
> 
> :- async withdraw/2. 
> withdraw(Amount) :- 
> await do_something, 
> retact(account(Current)), 
> Current2 is Curent-Amount, 
> assertz(account(Current2)), 
> await do_something2. 
> 
> Since the retract/assertz combo is not interleaved with an 
> await statement, we know that noting will yield while executing 
> the combo, and the effect is as if it were a critical region. But 
> 
> locks or atomics are not needed. You have to switch off auto- 
> yielding for such a code as above, no auto-yielding is also the 
> default execution mode of JavaScript, and you could apply 
> 
> the same reasoning to JavaScript.

[toc] | [prev] | [next] | [standalone]

#13489

So is there really a 3rd category Worker Fiber? Thanks for 
challenging me explaning a concept over and over again.

Q: You shouldn’t, but you need between fibers on the same worker?

A: Do you mean shared atom and clause garbage collection is needed?
Yes. But only a single threaded version of it. Its not doing anything
between fibers inside the same worker. You don’t need locking or

atomics for fibers as I see it. With the JavaScript Worker model, 
you land in single threaded Prolog system, although you are 
multi-threaded. I don’t know how difficult it would be to build a 

SWI-Prolog system that has Workers running single-threaded,
but nevertheless supports many of them over threads? You possibly
have to separate the Workers from a Workers monitor. Make the

Workers monitor a separately compiled component, where multi-threading
is enable. And compile the SWI-Prolog Workers Prolog runtime system
single-threaded, i.e. with multi-threading disabled.

Mostowski Collapse schrieb am Dienstag, 28. Februar 2023 um 01:05:12 UTC+1:
> Multi-Threaded Prolog ----\ 
> Single-Threaded Prolog ---+-----> Novacore 
> Worker Fiber Prolog ------/ 

[toc] | [prev] | [next] | [standalone]

#13490

I don’t know yet how to bake it. In formerly Jekejeke
Prolog I have ultra static but no yield or auto-yield yet,
despite that it has engines!

In Dogelog Player I have yield or auto-yield, but no
cooperative task spawning yet. One Prolog system that
has already fibers is Tau Prolog, but their system

doesn’t perform very well otherwise. SWI-Prolog is
in a good position in that it has already engines with
yield and recently auto-yield!

Mostowski Collapse schrieb am Donnerstag, 2. März 2023 um 13:06:55 UTC+1:
> So is there really a 3rd category Worker Fiber? Thanks for 
> challenging me explaning a concept over and over again. 
> 
> Q: You shouldn’t, but you need between fibers on the same worker? 
> 
> A: Do you mean shared atom and clause garbage collection is needed? 
> Yes. But only a single threaded version of it. Its not doing anything 
> between fibers inside the same worker. You don’t need locking or 
> 
> atomics for fibers as I see it. With the JavaScript Worker model, 
> you land in single threaded Prolog system, although you are 
> multi-threaded. I don’t know how difficult it would be to build a 
> 
> SWI-Prolog system that has Workers running single-threaded, 
> but nevertheless supports many of them over threads? You possibly 
> have to separate the Workers from a Workers monitor. Make the 
> 
> Workers monitor a separately compiled component, where multi-threading 
> is enable. And compile the SWI-Prolog Workers Prolog runtime system 
> single-threaded, i.e. with multi-threading disabled.
> Mostowski Collapse schrieb am Dienstag, 28. Februar 2023 um 01:05:12 UTC+1: 
> > Multi-Threaded Prolog ----\ 
> > Single-Threaded Prolog ---+-----> Novacore 
> > Worker Fiber Prolog ------/

[toc] | [prev] | [next] | [standalone]

#13506

Now I made a new version of my non-fibers and fibers API.
I removed the name “engine” from the API, so as to avoid
confusion. Engines are more lower level than the Python

idea of callbacks and tasks. The API now reads:

Part 1: Callbacks (non-fibers) (Changed)
They are Stackless and run in the <strike>main Engine</strike> 
current Task of the Current Thread. In my current take, they run 
without Auto-Yield and without Yield-Allowed.

os_call_later(G, D, T):
The predicate succeeds in T with a new timer. As a side effect
it schedules the goal G to be executed after D milliseconds.

os_call_cancel(T):
The predicate succeeds. As a side effect it cancels the timer T.

Part 2: Tasks (1:N fibers) (Changed)
They are Stackful and create their own <strike>Engine</strike> Task 
in the Current Thread. In my current take, they run with 
Auto-Yield and with Yield-Allowed.

os_task_current(E):
The predicate succeeds in E with the current <strike>engine</strike> task.

os_task_abort(E, M):
The predicate succeeds. As a side effect the <strike>engine</strike>
task E gets the message M signalled.

os_task_create(G, E):
The predicate succeeds in E with a new <strike>engine</strike> task
for the goal G. The task gets immediately scheduled to be executed.

Mostowski Collapse schrieb am Donnerstag, 2. März 2023 um 13:08:48 UTC+1:
> I don’t know yet how to bake it. In formerly Jekejeke 
> Prolog I have ultra static but no yield or auto-yield yet, 
> despite that it has engines! 
> 
> In Dogelog Player I have yield or auto-yield, but no 
> cooperative task spawning yet. One Prolog system that 
> has already fibers is Tau Prolog, but their system 
> 
> doesn’t perform very well otherwise. SWI-Prolog is 
> in a good position in that it has already engines with 
> yield and recently auto-yield!
> Mostowski Collapse schrieb am Donnerstag, 2. März 2023 um 13:06:55 UTC+1: 
> > So is there really a 3rd category Worker Fiber? Thanks for 
> > challenging me explaning a concept over and over again. 
> > 
> > Q: You shouldn’t, but you need between fibers on the same worker? 
> > 
> > A: Do you mean shared atom and clause garbage collection is needed? 
> > Yes. But only a single threaded version of it. Its not doing anything 
> > between fibers inside the same worker. You don’t need locking or 
> > 
> > atomics for fibers as I see it. With the JavaScript Worker model, 
> > you land in single threaded Prolog system, although you are 
> > multi-threaded. I don’t know how difficult it would be to build a 
> > 
> > SWI-Prolog system that has Workers running single-threaded, 
> > but nevertheless supports many of them over threads? You possibly 
> > have to separate the Workers from a Workers monitor. Make the 
> > 
> > Workers monitor a separately compiled component, where multi-threading 
> > is enable. And compile the SWI-Prolog Workers Prolog runtime system 
> > single-threaded, i.e. with multi-threading disabled. 
> > Mostowski Collapse schrieb am Dienstag, 28. Februar 2023 um 01:05:12 UTC+1: 
> > > Multi-Threaded Prolog ----\ 
> > > Single-Threaded Prolog ---+-----> Novacore 
> > > Worker Fiber Prolog ------/

[toc] | [prev] | [next] | [standalone]

#13507

Nice addition to the current API spec and already
implemented for JavaScript and Python. A callback
has now the context available of the task that scheduled it.

?- os_task_current(T), write('task='), write(T), nl.
task=main

?- call_later((os_task_current(T), write('task='),
write(T), nl), 100), sleep(500).
task=main

?- create_task((os_task_current(T), write('task='), write(T), nl)), sleep(500).
task=[object Object]

?- create_task(call_later((os_task_current(T), write('task='),
write(T), nl), 100)), sleep(500).
task=[object Object]

And there is a new Prolog flag allow_yield, which can 
be illustrated, you can query what the current API says:

?- current_prolog_flag(allow_yield, A), write('allow_yield='), write(A), nl.
allow_yield=on

?- call_later((current_prolog_flag(allow_yield, A), write('allow_yield='),
write(A), nl), 100), sleep(500).
allow_yield=off

Mostowski Collapse schrieb am Mittwoch, 8. März 2023 um 10:45:15 UTC+1:
> Now I made a new version of my non-fibers and fibers API. 
> I removed the name “engine” from the API, so as to avoid 
> confusion. Engines are more lower level than the Python 
> 
> idea of callbacks and tasks. The API now reads: 
> 
> Part 1: Callbacks (non-fibers) (Changed) 
> They are Stackless and run in the <strike>main Engine</strike> 
> current Task of the Current Thread. In my current take, they run 
> without Auto-Yield and without Yield-Allowed. 
> 
> os_call_later(G, D, T): 
> The predicate succeeds in T with a new timer. As a side effect 
> it schedules the goal G to be executed after D milliseconds. 
> 
> os_call_cancel(T): 
> The predicate succeeds. As a side effect it cancels the timer T. 
> 
> Part 2: Tasks (1:N fibers) (Changed) 
> They are Stackful and create their own <strike>Engine</strike> Task 
> in the Current Thread. In my current take, they run with 
> Auto-Yield and with Yield-Allowed. 
> 
> os_task_current(E): 
> The predicate succeeds in E with the current <strike>engine</strike> task. 
> 
> os_task_abort(E, M): 
> The predicate succeeds. As a side effect the <strike>engine</strike> 
> task E gets the message M signalled. 
> 
> os_task_create(G, E): 
> The predicate succeeds in E with a new <strike>engine</strike> task 
> for the goal G. The task gets immediately scheduled to be executed.
> Mostowski Collapse schrieb am Donnerstag, 2. März 2023 um 13:08:48 UTC+1: 
> > I don’t know yet how to bake it. In formerly Jekejeke 
> > Prolog I have ultra static but no yield or auto-yield yet, 
> > despite that it has engines! 
> > 
> > In Dogelog Player I have yield or auto-yield, but no 
> > cooperative task spawning yet. One Prolog system that 
> > has already fibers is Tau Prolog, but their system 
> > 
> > doesn’t perform very well otherwise. SWI-Prolog is 
> > in a good position in that it has already engines with 
> > yield and recently auto-yield! 
> > Mostowski Collapse schrieb am Donnerstag, 2. März 2023 um 13:06:55 UTC+1: 
> > > So is there really a 3rd category Worker Fiber? Thanks for 
> > > challenging me explaning a concept over and over again. 
> > > 
> > > Q: You shouldn’t, but you need between fibers on the same worker? 
> > > 
> > > A: Do you mean shared atom and clause garbage collection is needed? 
> > > Yes. But only a single threaded version of it. Its not doing anything 
> > > between fibers inside the same worker. You don’t need locking or 
> > > 
> > > atomics for fibers as I see it. With the JavaScript Worker model, 
> > > you land in single threaded Prolog system, although you are 
> > > multi-threaded. I don’t know how difficult it would be to build a 
> > > 
> > > SWI-Prolog system that has Workers running single-threaded, 
> > > but nevertheless supports many of them over threads? You possibly 
> > > have to separate the Workers from a Workers monitor. Make the 
> > > 
> > > Workers monitor a separately compiled component, where multi-threading 
> > > is enable. And compile the SWI-Prolog Workers Prolog runtime system 
> > > single-threaded, i.e. with multi-threading disabled. 
> > > Mostowski Collapse schrieb am Dienstag, 28. Februar 2023 um 01:05:12 UTC+1: 
> > > > Multi-Threaded Prolog ----\ 
> > > > Single-Threaded Prolog ---+-----> Novacore 
> > > > Worker Fiber Prolog ------/

[toc] | [prev] | [next] | [standalone]

#13525

Inside Novacore we could reinvent Prolog Dicts. JavaScript 
has a primitive data type for Symbols, so you can call 
Symbol.for(“key”), which will internalize the string, so that 

you can use pointer equality on the result:

> Symbol is a built-in object whose constructor returns a symbol primitive
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol

It wouldn’t match JSON usage, since the keys are not supposed
to be Symbols, only Strings. But maybe this is only superficially, 
and internally they are Symbols. One could do the same for 

Novacore Prolog Dicts. On the surface Novacore Prolog
Dicts would use Strings:

?- X = {"abc" : 123.45, "def": 67}.
But under the hood there would be a transition from String to Atom:

?- X = {"abc" : 123.45, "def": 67}, X =.. L.
L = [C'novacore_dict, abc, 123.45, def, 67]

The rational would be: The keys usually form a limited vocabulary.

[toc] | [prev] | [next] | [standalone]

#13526

Interestingly with the above trick, a Prolog parser can
recognize Novacore Prolog Dicts. Since it would see this
production at the head of a Novacore Prolog Dict:

novacore_dict :== "{" string ":" term ... "}"

Which is unlike the ISO core definition of “{}”, since in
ISO core there are no strings, and even a qualified call in
ISO module assumes that we have atom “:” term. So

there would be no collision with this production:

set :== "{" term "}"

Mostowski Collapse schrieb am Samstag, 18. März 2023 um 13:55:21 UTC+1:
> Inside Novacore we could reinvent Prolog Dicts. JavaScript 
> has a primitive data type for Symbols, so you can call 
> Symbol.for(“key”), which will internalize the string, so that 
> 
> you can use pointer equality on the result: 
> 
> > Symbol is a built-in object whose constructor returns a symbol primitive 
> > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol 
> 
> It wouldn’t match JSON usage, since the keys are not supposed 
> to be Symbols, only Strings. But maybe this is only superficially, 
> and internally they are Symbols. One could do the same for 
> 
> Novacore Prolog Dicts. On the surface Novacore Prolog 
> Dicts would use Strings: 
> 
> ?- X = {"abc" : 123.45, "def": 67}. 
> But under the hood there would be a transition from String to Atom: 
> 
> ?- X = {"abc" : 123.45, "def": 67}, X =.. L. 
> L = [C'novacore_dict, abc, 123.45, def, 67] 
> 
> The rational would be: The keys usually form a limited vocabulary.

[toc] | [prev] | [next] | [standalone]

#13527

Currently I get an error when I use string keys:

/* SWI-Prolog 9.1.4 */
?- current_prolog_flag(double_quotes, X).
X = string.

?- X = _{"abc": 123.46, "def": 67}.
ERROR: Syntax error: key_expected
Also there is the annoying need for an underscore functor.

With string keys I could directly embed JSON?
In this case null, false and true could be easily an atom.
Thats kind of solving the constant problem from another angle.

Mostowski Collapse schrieb am Samstag, 18. März 2023 um 13:56:23 UTC+1:
> Interestingly with the above trick, a Prolog parser can 
> recognize Novacore Prolog Dicts. Since it would see this 
> production at the head of a Novacore Prolog Dict: 
> 
> novacore_dict :== "{" string ":" term ... "}" 
> 
> Which is unlike the ISO core definition of “{}”, since in 
> ISO core there are no strings, and even a qualified call in 
> ISO module assumes that we have atom “:” term. So 
> 
> there would be no collision with this production: 
> 
> set :== "{" term "}"
> Mostowski Collapse schrieb am Samstag, 18. März 2023 um 13:55:21 UTC+1: 
> > Inside Novacore we could reinvent Prolog Dicts. JavaScript 
> > has a primitive data type for Symbols, so you can call 
> > Symbol.for(“key”), which will internalize the string, so that 
> > 
> > you can use pointer equality on the result: 
> > 
> > > Symbol is a built-in object whose constructor returns a symbol primitive 
> > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol 
> > 
> > It wouldn’t match JSON usage, since the keys are not supposed 
> > to be Symbols, only Strings. But maybe this is only superficially, 
> > and internally they are Symbols. One could do the same for 
> > 
> > Novacore Prolog Dicts. On the surface Novacore Prolog 
> > Dicts would use Strings: 
> > 
> > ?- X = {"abc" : 123.45, "def": 67}. 
> > But under the hood there would be a transition from String to Atom: 
> > 
> > ?- X = {"abc" : 123.45, "def": 67}, X =.. L. 
> > L = [C'novacore_dict, abc, 123.45, def, 67] 
> > 
> > The rational would be: The keys usually form a limited vocabulary.

[toc] | [prev] | [next] | [standalone]

#13528

But this other angle would only work inside JSON.
There is still a problem with ordinary Prolog code, and
for example the disabled setter. If we want to avoid some

bottle neck of translating structures back and forth.

Mostowski Collapse schrieb am Samstag, 18. März 2023 um 14:01:35 UTC+1:
> Currently I get an error when I use string keys: 
> 
> /* SWI-Prolog 9.1.4 */ 
> ?- current_prolog_flag(double_quotes, X). 
> X = string. 
> 
> ?- X = _{"abc": 123.46, "def": 67}. 
> ERROR: Syntax error: key_expected 
> Also there is the annoying need for an underscore functor. 
> 
> With string keys I could directly embed JSON? 
> In this case null, false and true could be easily an atom. 
> Thats kind of solving the constant problem from another angle.
> Mostowski Collapse schrieb am Samstag, 18. März 2023 um 13:56:23 UTC+1: 
> > Interestingly with the above trick, a Prolog parser can 
> > recognize Novacore Prolog Dicts. Since it would see this 
> > production at the head of a Novacore Prolog Dict: 
> > 
> > novacore_dict :== "{" string ":" term ... "}" 
> > 
> > Which is unlike the ISO core definition of “{}”, since in 
> > ISO core there are no strings, and even a qualified call in 
> > ISO module assumes that we have atom “:” term. So 
> > 
> > there would be no collision with this production: 
> > 
> > set :== "{" term "}" 
> > Mostowski Collapse schrieb am Samstag, 18. März 2023 um 13:55:21 UTC+1: 
> > > Inside Novacore we could reinvent Prolog Dicts. JavaScript 
> > > has a primitive data type for Symbols, so you can call 
> > > Symbol.for(“key”), which will internalize the string, so that 
> > > 
> > > you can use pointer equality on the result: 
> > > 
> > > > Symbol is a built-in object whose constructor returns a symbol primitive 
> > > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol 
> > > 
> > > It wouldn’t match JSON usage, since the keys are not supposed 
> > > to be Symbols, only Strings. But maybe this is only superficially, 
> > > and internally they are Symbols. One could do the same for 
> > > 
> > > Novacore Prolog Dicts. On the surface Novacore Prolog 
> > > Dicts would use Strings: 
> > > 
> > > ?- X = {"abc" : 123.45, "def": 67}. 
> > > But under the hood there would be a transition from String to Atom: 
> > > 
> > > ?- X = {"abc" : 123.45, "def": 67}, X =.. L. 
> > > L = [C'novacore_dict, abc, 123.45, def, 67] 
> > > 
> > > The rational would be: The keys usually form a limited vocabulary.

[toc] | [prev] | [next] | [standalone]

#13622

Now I have already removed the following predicates from
Novacore, they landed in library(compat):

- numbervars/2
- subsumes/2
- subsumes_term/2

Now wonder where variant/2 would land? SWI-Prolog wants to tell me 
that variant/2 might need library(compat), because of numbervars/2. 
Assuming A and B have already distinct variables I get the following solution:

A =@= B :-
        \+ \+ (numbervars(Ac, 0, N), 
                   numbervars(Bc, 0, N),
                   Ac == Bc).
https://www.swi-prolog.org/pldoc/doc_for?object=%28%3D@%3D%29/2

On the other hand this solution gives me also a library(compat)
dependency, since its based on subsumes_term/2. Again assuming A and 
B have already distinct variables I get the following solution:

A =@= B :-
        subsumes_term(A, B),
        subsumes_term(B, A).
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/built-in_predicates

Isn't there something simpler?

[toc] | [prev] | [next] | [standalone]

#13623

This is cute, has quite some different dependencies,
inspired by the use of term_variables/3 in bagof/3,
again assuming that A and B have already disjoint variables:

A =@= B :- 
    term_variables(A, L),
    term_variables(B, R),
    \+ \+ (L=R, A==B).

Can be bootstrapped from a much smaler Novacore.

Mostowski Collapse schrieb am Samstag, 13. Mai 2023 um 15:36:04 UTC+2:
> Now I have already removed the following predicates from 
> Novacore, they landed in library(compat): 
> 
> - numbervars/2 
> - subsumes/2 
> - subsumes_term/2 
> 
> Now wonder where variant/2 would land? SWI-Prolog wants to tell me 
> that variant/2 might need library(compat), because of numbervars/2. 
> Assuming A and B have already distinct variables I get the following solution: 
> 
> A =@= B :- 
> \+ \+ (numbervars(A, 0, N), 
> numbervars(B, 0, N), 
> A == B). 
> https://www.swi-prolog.org/pldoc/doc_for?object=%28%3D@%3D%29/2 
> 
> On the other hand this solution gives me also a library(compat) 
> dependency, since its based on subsumes_term/2. Again assuming A and 
> B have already distinct variables I get the following solution: 
> 
> A =@= B :- 
> subsumes_term(A, B), 
> subsumes_term(B, A). 
> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/built-in_predicates 
> 
> Isn't there something simpler?

[toc] | [prev] | [next] | [standalone]

#13637

Now I have implemented the new open/4 options method/1,
headers/1 and body/1 also for Dogelog Player. There is a first
take that works in the browser. More platforms to follow.

Its such a thin extension, API wise, want to have it as part of 
Novacore. What do other Prolog systems do? Here is what 
SWI-Prolog in their offering. 

- method/1: Accepts the method name in lower case,
  so far I use the option with an upper case value.
- headers/1: Doesn't use our Key-Value pair format, 
  instead the format is Key(Value). Has separate option
  for auth/1 and inside auth/1 for bearer/1.
- body/1: Not available in SWI-Prolog, must use post/1,
  and post/1 accepts quite a bulk of formats.

and then I find that Trealla Prolog does something else
Signature wise:

- offers some convenience like http_post/4, http_delete/3, 
  bootstrapped from http_get/3.
- http_get/3 has options method/1, post/1 and header/2,
  quite amazing, mostly written in 100% Prolog!
- might also support HTTPS, depends on client/5.
- this was checked into GitHub 9 months ago

and Scryer Prolog does again something else
Signature wise:

- http_open/3 had a 100% Prolog solution in 2020,
  but became something else 12 months ago.
- http_open/3 has options method/1, data/1 and
  request_headers/1, goes into CallHttpOpen instruction,
  which then uses hyper_tls.

[toc] | [prev] | [next] | [standalone]

#14202 — Differences among the "bomb" and "xbetween" (Was: Request for comments, Novacore the sequel to ISO modules)

Here are two test cases for memory
management of a Prolog system:

/* bomb */

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.

/* xbetween */
xbetween1(L, _, L).
xbetween1(L, U, N) :- L < U, M is L+1, xbetween1(M, U, N).

They test possibly something different. xbetween does
not produce a lot of objects during tail recursion,
it only decrements one integer. The xbetween example

might be ok, wherea the bomb example might be neverthelesss
not ok, especially since unlike in the xbetween example,
the bomb example has also an "intermediate" variables.

The "intermediate" variable is "_":

foo :- garbage(12,_), foo.

The xbetween example has no such variable. All
variables in the xbetween example are either in
the head or in the tail recursive call, making

it a more trivial example than the bomb example.

[toc] | [prev] | [next] | [standalone]

#14221 — The issue with free speech

@herme wrote:

Just a quick comment: note that you can make
and discuss the PIP proposals directly on
the PIPs discourse.

Here my response:

I will probably never go there since somebody
tried censoring my comments and said I don’t
work towards the Prolog cause. The good thing
about SWI-Prolog discourse, it has become

quite calm cocerning attempts to censor people,
possibly because some particular people left.
Which is in my opinion the best thing that
could happen to this forum. There is no

guarantee in other forums to really have free speech.

[toc] | [prev] | [next] | [standalone]

#14253 — failure of formal verification [software.imdea.org] (Was: The issue with free speech)

Hi,

Not only are the fucking PIPs behind a
login wall that doesn't work:

Dictionaries in Prolog
https://gitlab.software.imdea.org/prolog-lang/pip-0102

I cannot read gitlab.software.imdea.org,
since it redirects to some internal server
during login.

Also formal verification doesn't have the
same track record as fuzzying. Take the SWI-Prolog
red-black trees. Are they really red-black trees?

I used fuzzy testing to find the test case.
Exhaustive enumeration of permutation seemed to
be out of reach computationally.

So I used these random permutations to find a
discrepancy in resulting tree depth:

fuzzer(R) :-
    numlist(1, 16, L),
    between(1, 1000, _),
    random_permutation(L, R).

Maybe the same technique can use to find smaller
discrepancies, and then use the smaller examples to
pin down difference in implemented balance

rules or implement rebalancing strategy.

Bye

Mild Shock schrieb:
> @herme wrote:
> 
> Just a quick comment: note that you can make
> and discuss the PIP proposals directly on
> the PIPs discourse.
> 
> Here my response:
> 
> I will probably never go there since somebody
> tried censoring my comments and said I don’t
> work towards the Prolog cause. The good thing
> about SWI-Prolog discourse, it has become
> 
> quite calm cocerning attempts to censor people,
> possibly because some particular people left.
> Which is in my opinion the best thing that
> could happen to this forum. There is no
> 
> guarantee in other forums to really have free speech.
> 

[toc] | [prev] | [next] | [standalone]

#14254 — Re: failure of formal verification [software.imdea.org] (Was: The issue with free speech)

So what is the spec. Well one can use:

Red-Black Trees in a Functional Setting
https://www.cs.tufts.edu/~nr/cs257/archive/chris-okasaki/redblack99.pdf

insert :: (Ord a) => a -> Tree a -> Tree a
insert x s = makeBlack $ ins s
   where ins E  = T R E x E
         ins (T color a y b)
           | x < y  = balance color (ins a) y b
           | x == y = T color a y b
           | x > y  = balance color a y (ins b)
         makeBlack (T _ a y b) = T B a y b

The balancing would be as follows, again Haskell code:

balance :: Color -> Tree a -> a -> Tree a -> Tree a
balance B (T R (T R a x b) y c) z d = T R (T B a x b) y (T B c z d)
balance B (T R a x (T R b y c)) z d = T R (T B a x b) y (T B c z d)
balance B a x (T R (T R b y c) z d) = T R (T B a x b) y (T B c z d)
balance B a x (T R b y (T R c z d)) = T R (T B a x b) y (T B c z d)
balance color a x b = T color a x b

Does SWI-Prolog implement somewhere Okasaki red-black trees.

Mild Shock schrieb:
> Hi,
> 
> Not only are the fucking PIPs behind a
> login wall that doesn't work:
> 
> Dictionaries in Prolog
> https://gitlab.software.imdea.org/prolog-lang/pip-0102
> 
> I cannot read gitlab.software.imdea.org,
> since it redirects to some internal server
> during login.
> 
> Also formal verification doesn't have the
> same track record as fuzzying. Take the SWI-Prolog
> red-black trees. Are they really red-black trees?
> 
> I used fuzzy testing to find the test case.
> Exhaustive enumeration of permutation seemed to
> be out of reach computationally.
> 
> So I used these random permutations to find a
> discrepancy in resulting tree depth:
> 
> fuzzer(R) :-
>     numlist(1, 16, L),
>     between(1, 1000, _),
>     random_permutation(L, R).
> 
> Maybe the same technique can use to find smaller
> discrepancies, and then use the smaller examples to
> pin down difference in implemented balance
> 
> rules or implement rebalancing strategy.
> 
> Bye
> 
> Mild Shock schrieb:
>> @herme wrote:
>>
>> Just a quick comment: note that you can make
>> and discuss the PIP proposals directly on
>> the PIPs discourse.
>>
>> Here my response:
>>
>> I will probably never go there since somebody
>> tried censoring my comments and said I don’t
>> work towards the Prolog cause. The good thing
>> about SWI-Prolog discourse, it has become
>>
>> quite calm cocerning attempts to censor people,
>> possibly because some particular people left.
>> Which is in my opinion the best thing that
>> could happen to this forum. There is no
>>
>> guarantee in other forums to really have free speech.
>>
> 

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.prolog

csiph-web