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 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

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

Results of a fuzzer comparison:

library(nb_rbtrees) from 2014 in SWI-Prolog:

/* SWI-Prolog 9.3.14 */
?- L = [16,10,12,13,15,5,11,8,14,1,7,6,3,2,4,9], rb_new(T),
      (member(X,L), nb_rb_insert(T, X, true),
      fail; true), rb_display(T, 0).
$BLK 12-true
    $RED 5-true
       $BLK 2-true
          $BLK 1-true
             $NIL
             $NIL
          $BLK 3-true
             $NIL
             $RED 4-true
                $NIL
                $NIL
       $BLK 10-true
          $RED 7-true
             $BLK 6-true
                $NIL
                $NIL
             $BLK 8-true
                $NIL
                $RED 9-true
                   $NIL
                   $NIL
          $BLK 11-true
             $NIL
             $NIL
    $BLK 15-true
       $BLK 13-true
          $NIL
          $RED 14-true
             $NIL
             $NIL
       $BLK 16-true
          $NIL
          $NIL

On the other hand the rules by Okasaki give a
different resulting tree, which is better balanced,
has less overall depth and doesn’t have a root 12,

rather the root 8. Implementation based on change_arg/3:

/* Dogelog Player 1.2.5 */
?- L = [16,10,12,13,15,5,11,8,14,1,7,6,3,2,4,9], tree_new(T),
    (member(X,L), tree_set(T, X, true),
    fail; true), tree_display(T, 0).
$BLK 8-true
    $BLK 6-true
       $RED 3-true
          $BLK 1-true
             $NIL
             $RED 2-true
                $NIL
                $NIL
          $BLK 5-true
             $RED 4-true
                $NIL
                $NIL
             $NIL
       $BLK 7-true
          $NIL
          $NIL
    $BLK 12-true
       $BLK 10-true
          $RED 9-true
             $NIL
             $NIL
          $RED 11-true
             $NIL
             $NIL
       $RED 15-true
          $BLK 13-true
             $NIL
             $RED 14-true
                $NIL
                $NIL
          $BLK 16-true
             $NIL
             $NIL

I think Okasaki is the more common red-black
trees implementation, if I am not mistaken Java’s
method fixAfterInsertion() from the class TreeMap,

does also implement the Okasaki rules. Bug or
Feature that SWI-Prolog doesn’t use Okasaki?

Mild Shock schrieb:
> 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]

#14227 — variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules)

The ISO core standard probably set the
stage for a couple of performance sins.
In 7.1.6.1 Variants of a term we find

these test cases:

- f(A, B, A) is a variant of f(X, Y, X).
- g(A, B) is a variant of g(_, _).
- P+Q is a variant of P+Q.

What is doubious here, is the last test
case with P+Q. Do we need to test terms
that have common variables?

Lets assume we have situations where we
don't need variant working with common
variables in the two argument terms, what

about then using this bootstrapping:

variant_term(X, Y) :-
    subsumes_term(X, Y),
    subsumes_term(Y, X).

Here some testing, does it work ok? Take this code:

enum_arg(_, 1).
enum_arg(_, _).
enum_arg(X, X).

enum_list(_, []).
enum_list(X, [H|T]) :- enum_arg(X, H), enum_list(X, T).

boole(G, 1) :- G, !.
boole(_, 0).

nok(L, R) :- length(L, 6), length(R, 6),
      enum_list(_, L), enum_list(_, R),
      boole(variant(L, R), A), boole(variant_term(L, R), B),
      A \== B.

Seems to work fine:

?- nok(L, R).
false.

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

#14228 — Re: variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules)

How much faster is it?

Here some test harness:

test :- length(L, 6), length(R, 6),
    enum_list(_, L), enum_list(_, R),
    variant(L, R), fail; true.

test2 :- length(L, 6), length(R, 6),
    enum_list(_, L), enum_list(_, R),
    variant_term(L, R), fail; true.

Here some results:

- SWI-Prolog 9.3.11:

?- time(test).
% 2,126,498 inferences, 0.734 CPU in 0.752 seconds
(98% CPU, 2895657 Lips)
true.

?- time(test2).
% 2,159,795 inferences, 0.234 CPU in 0.236 seconds
(99% CPU, 9215125 Lips)
true.

- Trealla Prolog 2.57.16:

?- time(test).
% Time elapsed 3.128s, 14827949 Inferences, 4.741 MLips
    true.

?- time(test2).
% Time elapsed 1.079s, 7775516 Inferences, 7.206 MLips
    true.

- Scryer Prolog :

?- time(test3).
    % CPU time: 5.653s, 5_192_831 inferences
    true.

?- time(test2).
    % CPU time: 1.544s, 6_116_163 inferences
    true.

Note: test3 is like test, only it uses builtins:variant/2.

Mild Shock schrieb:
> The ISO core standard probably set the
> stage for a couple of performance sins.
> In 7.1.6.1 Variants of a term we find
> 
> these test cases:
> 
> - f(A, B, A) is a variant of f(X, Y, X).
> - g(A, B) is a variant of g(_, _).
> - P+Q is a variant of P+Q.
> 
> What is doubious here, is the last test
> case with P+Q. Do we need to test terms
> that have common variables?
> 
> Lets assume we have situations where we
> don't need variant working with common
> variables in the two argument terms, what
> 
> about then using this bootstrapping:
> 
> variant_term(X, Y) :-
>     subsumes_term(X, Y),
>     subsumes_term(Y, X).
> 
> Here some testing, does it work ok? Take this code:
> 
> enum_arg(_, 1).
> enum_arg(_, _).
> enum_arg(X, X).
> 
> enum_list(_, []).
> enum_list(X, [H|T]) :- enum_arg(X, H), enum_list(X, T).
> 
> boole(G, 1) :- G, !.
> boole(_, 0).
> 
> nok(L, R) :- length(L, 6), length(R, 6),
>       enum_list(_, L), enum_list(_, R),
>       boole(variant(L, R), A), boole(variant_term(L, R), B),
>       A \== B.
> 
> Seems to work fine:
> 
> ?- nok(L, R).
> false.
> 
> 

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

#14229 — Re: variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules)

So what can we do with this insight. Here is
a little performance of a new distinct/1,
that is eager und non-variant enumerating:

/* eagerness */
?- distinct(repeat), !.
true.

d(f(A,A)).
d(f(a,a)).
d(f(B,B)).

/* non-variant enumerating */
?- distinct(d(X)).
X = f(_70321, _70321);
X = f(a, a);
fail.

It is implemented with variant_term/2, since the
remembered list of archived witnesses so far,
is anyway copies of terms. So variant_term/2

is appropriate, we never have to check
two terms that have variables in common.

Cool!

Mild Shock schrieb:
> How much faster is it?
> 
> Here some test harness:
> 
> test :- length(L, 6), length(R, 6),
>     enum_list(_, L), enum_list(_, R),
>     variant(L, R), fail; true.
> 
> test2 :- length(L, 6), length(R, 6),
>     enum_list(_, L), enum_list(_, R),
>     variant_term(L, R), fail; true.
> 
> Here some results:
> 
> - SWI-Prolog 9.3.11:
> 
> ?- time(test).
> % 2,126,498 inferences, 0.734 CPU in 0.752 seconds
> (98% CPU, 2895657 Lips)
> true.
> 
> ?- time(test2).
> % 2,159,795 inferences, 0.234 CPU in 0.236 seconds
> (99% CPU, 9215125 Lips)
> true.
> 
> - Trealla Prolog 2.57.16:
> 
> ?- time(test).
> % Time elapsed 3.128s, 14827949 Inferences, 4.741 MLips
>     true.
> 
> ?- time(test2).
> % Time elapsed 1.079s, 7775516 Inferences, 7.206 MLips
>     true.
> 
> - Scryer Prolog :
> 
> ?- time(test3).
>     % CPU time: 5.653s, 5_192_831 inferences
>     true.
> 
> ?- time(test2).
>     % CPU time: 1.544s, 6_116_163 inferences
>     true.
> 
> Note: test3 is like test, only it uses builtins:variant/2.
> 
> Mild Shock schrieb:
>> The ISO core standard probably set the
>> stage for a couple of performance sins.
>> In 7.1.6.1 Variants of a term we find
>>
>> these test cases:
>>
>> - f(A, B, A) is a variant of f(X, Y, X).
>> - g(A, B) is a variant of g(_, _).
>> - P+Q is a variant of P+Q.
>>
>> What is doubious here, is the last test
>> case with P+Q. Do we need to test terms
>> that have common variables?
>>
>> Lets assume we have situations where we
>> don't need variant working with common
>> variables in the two argument terms, what
>>
>> about then using this bootstrapping:
>>
>> variant_term(X, Y) :-
>>     subsumes_term(X, Y),
>>     subsumes_term(Y, X).
>>
>> Here some testing, does it work ok? Take this code:
>>
>> enum_arg(_, 1).
>> enum_arg(_, _).
>> enum_arg(X, X).
>>
>> enum_list(_, []).
>> enum_list(X, [H|T]) :- enum_arg(X, H), enum_list(X, T).
>>
>> boole(G, 1) :- G, !.
>> boole(_, 0).
>>
>> nok(L, R) :- length(L, 6), length(R, 6),
>>       enum_list(_, L), enum_list(_, R),
>>       boole(variant(L, R), A), boole(variant_term(L, R), B),
>>       A \== B.
>>
>> Seems to work fine:
>>
>> ?- nok(L, R).
>> false.
>>
>>
> 

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

#14230 — Re: variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules)

Ok, I have to redo my nok/2 test for Scryer Prolog,
since Scryer Prolog doesn't work as per ISO spec:

/* Scryer Prolog Playground */
?- builtins:variant(f(A,B), f(C,D)).
    A = A, B = A, C = A, D = A.

It should not leave some bindings. At least this is
what other Prolog systems do:

/* Trealla Prolog */
?- variant(f(A,B), f(C,D)).
    true.

/* SWI-Prolog */
?- variant(f(A,B), f(C,D)).
true.

The performance tests are not affected, but I guess
it is better to test nok/2 like this:

nok2(L, R) :- length(L, 6), length(R, 6),
      enum_list(_, L), enum_list(_, R),
      boole(variant_term(L, R), A), boole(builtins:variant(L, R), B),
      A \== B.

Besides the binding glitch, it seems to be ok:

?- nok2(L, R).
    false.

Mild Shock schrieb:
> So what can we do with this insight. Here is
> a little performance of a new distinct/1,
> that is eager und non-variant enumerating:
> 
> /* eagerness */
> ?- distinct(repeat), !.
> true.
> 
> d(f(A,A)).
> d(f(a,a)).
> d(f(B,B)).
> 
> /* non-variant enumerating */
> ?- distinct(d(X)).
> X = f(_70321, _70321);
> X = f(a, a);
> fail.
> 
> It is implemented with variant_term/2, since the
> remembered list of archived witnesses so far,
> is anyway copies of terms. So variant_term/2
> 
> is appropriate, we never have to check
> two terms that have variables in common.
> 
> Cool!
> 
> Mild Shock schrieb:
>> How much faster is it?
>>
>> Here some test harness:
>>
>> test :- length(L, 6), length(R, 6),
>>     enum_list(_, L), enum_list(_, R),
>>     variant(L, R), fail; true.
>>
>> test2 :- length(L, 6), length(R, 6),
>>     enum_list(_, L), enum_list(_, R),
>>     variant_term(L, R), fail; true.
>>
>> Here some results:
>>
>> - SWI-Prolog 9.3.11:
>>
>> ?- time(test).
>> % 2,126,498 inferences, 0.734 CPU in 0.752 seconds
>> (98% CPU, 2895657 Lips)
>> true.
>>
>> ?- time(test2).
>> % 2,159,795 inferences, 0.234 CPU in 0.236 seconds
>> (99% CPU, 9215125 Lips)
>> true.
>>
>> - Trealla Prolog 2.57.16:
>>
>> ?- time(test).
>> % Time elapsed 3.128s, 14827949 Inferences, 4.741 MLips
>>     true.
>>
>> ?- time(test2).
>> % Time elapsed 1.079s, 7775516 Inferences, 7.206 MLips
>>     true.
>>
>> - Scryer Prolog :
>>
>> ?- time(test3).
>>     % CPU time: 5.653s, 5_192_831 inferences
>>     true.
>>
>> ?- time(test2).
>>     % CPU time: 1.544s, 6_116_163 inferences
>>     true.
>>
>> Note: test3 is like test, only it uses builtins:variant/2.
>>
>> Mild Shock schrieb:
>>> The ISO core standard probably set the
>>> stage for a couple of performance sins.
>>> In 7.1.6.1 Variants of a term we find
>>>
>>> these test cases:
>>>
>>> - f(A, B, A) is a variant of f(X, Y, X).
>>> - g(A, B) is a variant of g(_, _).
>>> - P+Q is a variant of P+Q.
>>>
>>> What is doubious here, is the last test
>>> case with P+Q. Do we need to test terms
>>> that have common variables?
>>>
>>> Lets assume we have situations where we
>>> don't need variant working with common
>>> variables in the two argument terms, what
>>>
>>> about then using this bootstrapping:
>>>
>>> variant_term(X, Y) :-
>>>     subsumes_term(X, Y),
>>>     subsumes_term(Y, X).
>>>
>>> Here some testing, does it work ok? Take this code:
>>>
>>> enum_arg(_, 1).
>>> enum_arg(_, _).
>>> enum_arg(X, X).
>>>
>>> enum_list(_, []).
>>> enum_list(X, [H|T]) :- enum_arg(X, H), enum_list(X, T).
>>>
>>> boole(G, 1) :- G, !.
>>> boole(_, 0).
>>>
>>> nok(L, R) :- length(L, 6), length(R, 6),
>>>       enum_list(_, L), enum_list(_, R),
>>>       boole(variant(L, R), A), boole(variant_term(L, R), B),
>>>       A \== B.
>>>
>>> Seems to work fine:
>>>
>>> ?- nok(L, R).
>>> false.
>>>
>>>
>>
> 

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

#13684

The new multilingual strings are also an exercise in
Novacore. There were a few issues that needed novel
Prolog solutions, to make a Novacore solution.

One problem was I didn't want to use library(format)
and format/3 to format multilingual strings when 
generating error messages. This addresses more

the later multilingual strings processing than the 
multilingual strings store itself. So how resolve this 
paradox? Here is my take, a mini format/3 boostraped 

from the Dogelog Player specific atom_split/3:

% sys_inter_polate(+Stream, +Atom, +List)
sys_inter_polate(Stream, Template, Args) :-
   atom_split(Template, '~', [Head|Tail]),
   put_atom(Stream, Head),
   sys_zipper_output(Args, Tail, Stream).

% sys_zipper_output(+List, +List, +Stream)
sys_zipper_output([Arg|Args], [Head|Tail], Stream) :-
   writeq(Stream, Arg),
   put_atom(Stream, Head),
   sys_zipper_output(Args, Tail, Stream).
sys_zipper_output([], [], _).

It only understands format specifier '~', but is sufficient:

/* German Text */
strings('syntax_error.singleton_var', de, 'Alleinstehende Variable(n) ~, anonyme Variable(n) (_) benutzen.').

/* English and Fallback Text */
strings('syntax_error.singleton_var', '', 'Singleton variable(s) ~, use anonymous variable(s) (_).').

LoL

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

#13724

Did you know that Novacore has change_arg/3?
Works for Dogelog Player and formerly Jekejeke Prolog.
It is similar like nb_linkarg/3 in SWI-Prolog.

So we can implement countall/3 in a blink:

countall(G, N) :-
   functor(Holder, v, 1),
   change_arg(1, Holder, 0),
   (G,
       arg(1, Holder, H),
       J is H+1,
       change_arg(1, Holder, J),
       fail; true),
   arg(1, Holder, N).

Works find:

?- countall(between(10,20,_), N).
N = 11.

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

#13854

We are now exploring file systems with novacore.
And here and then we have a couple of primitives
and then do some bootstrapping. It currently lands

in library(random) until we find a better place:

% directory_member(+Atom, -Atom)
directory_member(F, N) :-
    directory_files(F, L),
    member(N, L).

% ensure_directory(+Atom)
ensure_directory(F) :-
    file_exists(F),
    file_property(F, type(directory)),
    !.
ensure_directory(F) :-
    make_directory(F).

Guess what, finding semantic and support of
directory_files/2, file_exists/1 and file_property/2
is already non trivial.

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

#13855

LogNonsenseTalk with its brainwash is totally
useless. This here is already wrong:

file_exists(File) :-
     absolute_file_name(File, ExpandedPath),
     {exists_file(ExpandedPath)}.

https://github.com/LogtalkDotOrg/logtalk3/blob/master/library/os/os.lgt

Becaue for example exists_file/1 in SWI-Prolog
means exists regular file. But file_exists/1

should mean exists file of any type. Just
lookup what GNU Prolog provides. In OS lingua

file means often regular, directory, etc..

Mild Shock schrieb:
> We are now exploring file systems with novacore.
> And here and then we have a couple of primitives
> and then do some bootstrapping. It currently lands
> 
> in library(random) until we find a better place:
> 
> % directory_member(+Atom, -Atom)
> directory_member(F, N) :-
>     directory_files(F, L),
>     member(N, L).
> 
> % ensure_directory(+Atom)
> ensure_directory(F) :-
>     file_exists(F),
>     file_property(F, type(directory)),
>     !.
> ensure_directory(F) :-
>     make_directory(F).
> 
> Guess what, finding semantic and support of
> directory_files/2, file_exists/1 and file_property/2
> is already non trivial.
> 

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

#13856

You see the OS jargon meaning in directory_member/2
which is bootstrapped from directory_files/2.

directory_files/2 should of course list any files
inside the directory, regular, directory, etc..

not only regular files. So "files" means any
file of type regular, directory, etc..

Mild Shock schrieb:
> 
> LogNonsenseTalk with its brainwash is totally
> useless. This here is already wrong:
> 
> file_exists(File) :-
>      absolute_file_name(File, ExpandedPath),
>      {exists_file(ExpandedPath)}.
> 
> https://github.com/LogtalkDotOrg/logtalk3/blob/master/library/os/os.lgt
> 
> Becaue for example exists_file/1 in SWI-Prolog
> means exists regular file. But file_exists/1
> 
> should mean exists file of any type. Just
> lookup what GNU Prolog provides. In OS lingua
> 
> file means often regular, directory, etc..
> 
> Mild Shock schrieb:
>> We are now exploring file systems with novacore.
>> And here and then we have a couple of primitives
>> and then do some bootstrapping. It currently lands
>>
>> in library(random) until we find a better place:
>>
>> % directory_member(+Atom, -Atom)
>> directory_member(F, N) :-
>>     directory_files(F, L),
>>     member(N, L).
>>
>> % ensure_directory(+Atom)
>> ensure_directory(F) :-
>>     file_exists(F),
>>     file_property(F, type(directory)),
>>     !.
>> ensure_directory(F) :-
>>     make_directory(F).
>>
>> Guess what, finding semantic and support of
>> directory_files/2, file_exists/1 and file_property/2
>> is already non trivial.
>>
> 

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

#14103 — New milestone float formatting [LoL] (Was: Request for comments, Novacore the sequel to ISO modules)

Hi,

To capture some critical examples of float to string
conversion I went with this kind of little excess
precision and had this float to string conversion:

          return shape_number(num.toPrecision(17));

Which gives this unfortunate result, still in release
1.2.1 of Dogelog Player for JavaScript seen:

?- between(1,10,N), X is (20+N)/10, write(X), nl, fail; true.
2.1000000000000001
2.2000000000000002
2.2999999999999998
2.3999999999999999
2.5
2.6000000000000001
2.7000000000000002
2.7999999999999998
2.8999999999999999
3.0

One work around is to check whether precision 16 would
also work. Like this code here:

         let res = num.toPrecision(16);
         if (Number(res) === num) {
             return shape_number(res);
         } else {
             return shape_number(num.toPrecision(17));
         }

The results are much more eye friendly:

?- between(1,10,N), X is (20+N)/10, write(X), nl, fail; true.
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
3.0
true.

Can we accept this solution? Will it slow down printing?

Mild Shock schrieb:
> The new multilingual strings are also an exercise in
> Novacore. There were a few issues that needed novel
> Prolog solutions, to make a Novacore solution.
> 
> One problem was I didn't want to use library(format)
> and format/3 to format multilingual strings when
> generating error messages. This addresses more
> 
> the later multilingual strings processing than the
> multilingual strings store itself. So how resolve this
> paradox? Here is my take, a mini format/3 boostraped
> 
> from the Dogelog Player specific atom_split/3:
> 
> % sys_inter_polate(+Stream, +Atom, +List)
> sys_inter_polate(Stream, Template, Args) :-
>     atom_split(Template, '~', [Head|Tail]),
>     put_atom(Stream, Head),
>     sys_zipper_output(Args, Tail, Stream).
> 
> % sys_zipper_output(+List, +List, +Stream)
> sys_zipper_output([Arg|Args], [Head|Tail], Stream) :-
>     writeq(Stream, Arg),
>     put_atom(Stream, Head),
>     sys_zipper_output(Args, Tail, Stream).
> sys_zipper_output([], [], _).
> 
> It only understands format specifier '~', but is sufficient:
> 
> /* German Text */
> strings('syntax_error.singleton_var', de, 'Alleinstehende Variable(n) ~, anonyme Variable(n) (_) benutzen.').
> 
> /* English and Fallback Text */
> strings('syntax_error.singleton_var', '', 'Singleton variable(s) ~, use anonymous variable(s) (_).').
> 
> LoL
> 

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

#14104 — Re: New milestone float formatting [LoL] (Was: Request for comments, Novacore the sequel to ISO modules)

Further test cases are:

?- X is 370370367037037036703703703670 / 123456789012345678901234567890.
X = 3.0000000000000004.

?- X is 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1.
X = 0.7999999999999999.

The first test case doesn't work in SWI-Prolog
since recently it has improve its realization of
(/)/2 arithemetic function. While in most Prolog

systems we should have the above result, since
neither the division equals 3.0 nor the sum equals
0.8 when we use floating point numbers, and

when we convert first to floating point number
before doing the division. The adaptive algorithm
is more expensive than just calling num.toPrecision(17).

It will in mimimum call num.toPrecision(16) and do
the back conversion, i.e. Number(res). So unparsing
has a parsing cost. And for critical numbers, it

has a second unparsing via num.toPrecision(17) cost.
But I guess we can accept this little slow down.

Mild Shock schrieb:
> Hi,
> 
> To capture some critical examples of float to string
> conversion I went with this kind of little excess
> precision and had this float to string conversion:
> 
>           return shape_number(num.toPrecision(17));
> 
> Which gives this unfortunate result, still in release
> 1.2.1 of Dogelog Player for JavaScript seen:
> 
> ?- between(1,10,N), X is (20+N)/10, write(X), nl, fail; true.
> 2.1000000000000001
> 2.2000000000000002
> 2.2999999999999998
> 2.3999999999999999
> 2.5
> 2.6000000000000001
> 2.7000000000000002
> 2.7999999999999998
> 2.8999999999999999
> 3.0
> 
> One work around is to check whether precision 16 would
> also work. Like this code here:
> 
>          let res = num.toPrecision(16);
>          if (Number(res) === num) {
>              return shape_number(res);
>          } else {
>              return shape_number(num.toPrecision(17));
>          }
> 
> The results are much more eye friendly:
> 
> ?- between(1,10,N), X is (20+N)/10, write(X), nl, fail; true.
> 2.1
> 2.2
> 2.3
> 2.4
> 2.5
> 2.6
> 2.7
> 2.8
> 2.9
> 3.0
> true.
> 
> Can we accept this solution? Will it slow down printing?

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

#14105 — Re: New milestone float formatting [LoL] (Was: Request for comments, Novacore the sequel to ISO modules)

GNU Prolog seems to still use the non-adaptive
algorithm with 17 decimal precision. It could
profit from the adaptive algorithm that arbitrates

between 16 and 17 decimal precision:

/* GNU Prolog 1.5.0 */

?- X is 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1.
X = 0.79999999999999993

?- 0.79999999999999993 == 0.7999999999999999.
Yes

?- X is 23/10.
X = 2.2999999999999998

?- 2.2999999999999998 == 2.3.
Yes

All discrepancies are not incorrect displays,
since reparsing decimal numbers shows that they
hit the same floating point values.

But 2.3 would be cuter!

Mild Shock schrieb:
> 
> Further test cases are:
> 
> ?- X is 370370367037037036703703703670 / 123456789012345678901234567890.
> X = 3.0000000000000004.
> 
> ?- X is 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1.
> X = 0.7999999999999999.
> 
> The first test case doesn't work in SWI-Prolog
> since recently it has improve its realization of
> (/)/2 arithemetic function. While in most Prolog
> 
> systems we should have the above result, since
> neither the division equals 3.0 nor the sum equals
> 0.8 when we use floating point numbers, and
> 
> when we convert first to floating point number
> before doing the division. The adaptive algorithm
> is more expensive than just calling num.toPrecision(17).
> 
> It will in mimimum call num.toPrecision(16) and do
> the back conversion, i.e. Number(res). So unparsing
> has a parsing cost. And for critical numbers, it
> 
> has a second unparsing via num.toPrecision(17) cost.
> But I guess we can accept this little slow down.

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

#14203 — Re: Differences among the "bomb" and "xbetween" (Was: New milestone float formatting [LoL])

Here some results on a Lenovo Yoga with
Windows 11 for xbetween:

/* SWI-Prolog 9.3.11 */
?- time((xbetween1(1,1000000000,_),fail)).
% 2,000,000,002 inferences, 72.688 CPU in 72.790 seconds (100% CPU, 
27515047 Lips)
false.

/* Dogelog Player 1.2.3, WSL2, JDK 21 */
?- time((xbetween1(1,1000000000,_),fail)).
% Time 160451 ms, GC 4 ms, Lips 24929729, Wall 24/09/2024 17:01
fail.

Dang, still ca. 2x times slower. But no
memory problem at all. Prolog specific GC is
very low, only 4 ms, because the Prolog system
doesn't allocate some logical variables for

this example. The extended neck here is semi-det
builtins, that are already evaluated only using
native stack and no Prolog stack, when the

clause is instantiated:

xbetween1(L, U, N) :- L < U, M is L+1, xbetween1(M, U, N).
                       \---- neck ----/

So overhead in Dogelog compared to SWI-Prolog
is among the fact that it abandons and creates a choice
point in every backtracking. Haven't found a way

yet to elegantly avoid this unecessary effort.

Mild Shock schrieb:
 > 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]

#14205 — New milestone time formatting (Was: Differences among the "bomb" and "xbetween")

This became a rather lengthy subproject,
but still a rewarding one. Here are the
changes:

- atom_time/3: Renamed sys_time_atom/3 to
   atom_time/3. Changed signature a little bit,
   this is to format and scan local times.

- atom_utctime/3: Landed in library(util/spin).
   This is to format and scan local times.

Can other Prolog systems implement atom_utctime/3
correctly. SWI-Prolog lacks the mode scan mode,
and formatting goes wrong:

/* SWI-Prolog 9.3.11 */
?- format_time(atom(X), '%a, %d %b %Y %H:%M:%S', 1725635101.000, posix).
X = 'Fri, 06 Sep 2024 17:05:01'.

/* Dogelog Player 1.2.3 */
?- atom_utctime(X, '%a, %d %b %Y %H:%M:%S', 1725635101000).
X = 'Fri, 06 Sep 2024 15:05:01'.

The above is from a machine without locale 'C'.
Its not suitable for rfc1123. What does SWI-Prolog
do, it uses weekday and month names from GMT,

but otherwise it uses local hours:

1725635101 Timestamp to Human date  [batch convert]
Supports Unix timestamps in seconds,
milliseconds, microseconds and nanoseconds.
Assuming that this timestamp is in seconds:
GMT: Friday, 6. September 2024 15:05:01
Your time zone: Freitag, 6. September 2024 17:05:01 GMT+02:00 DST
Relative: 20 days ago
https://www.epochconverter.com/

See also:

All HTTP date/time stamps MUST be represented in
Greenwich Mean Time (GMT), without exception.
https://datatracker.ietf.org/doc/html/rfc2616#section-3.3.1

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

#14215 — More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404]

How about some of these PIPs:

PIP401: library(lists)
Provide predicates such as nth1/3, last/2, etc…

PIP402: library(sets)
Provide predicates such as union/3, subset/2, etc…

PIP403: library(sequence)
Provide predicates such as call_nth/2, limit/2, etc…

PIP404: library(aggregate)
Provide predicates such as aggregate_all/3, aggregate/3, etc…

There was once an effort Prolog Commons, which has
some overlap with the above PIPs:

The Prolog Commons Group - PART I - Library
https://prolog-commons.org/PrologCommons.html/part_library.html

But its more modularized than just a Prologue to Prolog,
which has a few list predicates and miscellaneous.

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

#14216 — Even More Prolog Improvement Proposals (PIPs) [PIP301 - PIP303] (Was: More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404])

Also interesting development, there is something
like “Prologue to Prolog C”, where C possibly
stands for cryptography. So maybe a further PIP:

PIP301: library(crypto)
Predicates such as crypto_data_hash/3, etc…

PIP302: library(charsio)
Predicates such as open_memory_file/2, etc…

PIP303: library(format)
Predicates such as format/3, etc…

In the above I have also added charsio and format,
which is useful in many contexts. Some remark about
the 30x modules, they usually a more based on

additional native routines. This is unlike the 40x
modules, which can have a pure Prolog reference
implementation.

Mild Shock schrieb:
> How about some of these PIPs:
> 
> PIP401: library(lists)
> Provide predicates such as nth1/3, last/2, etc…
> 
> PIP402: library(sets)
> Provide predicates such as union/3, subset/2, etc…
> 
> PIP403: library(sequence)
> Provide predicates such as call_nth/2, limit/2, etc…
> 
> PIP404: library(aggregate)
> Provide predicates such as aggregate_all/3, aggregate/3, etc…
> 
> There was once an effort Prolog Commons, which has
> some overlap with the above PIPs:
> 
> The Prolog Commons Group - PART I - Library
> https://prolog-commons.org/PrologCommons.html/part_library.html
> 
> But its more modularized than just a Prologue to Prolog,
> which has a few list predicates and miscellaneous.
> 
> 

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

#14217 — Re: Even More Prolog Improvement Proposals (PIPs) [PIP301 - PIP303] (Was: More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404])

And this one:

PIP304: library(math)
Evaluable functions such as popcount/1, etc…

The idea of a library(math) is brand new,
I first had it named library(random) and
then it got out of hands, exploded and

had many bitwise operations.

Mild Shock schrieb:
> Also interesting development, there is something
> like “Prologue to Prolog C”, where C possibly
> stands for cryptography. So maybe a further PIP:
> 
> PIP301: library(crypto)
> Predicates such as crypto_data_hash/3, etc…
> 
> PIP302: library(charsio)
> Predicates such as open_memory_file/2, etc…
> 
> PIP303: library(format)
> Predicates such as format/3, etc…
> 
> In the above I have also added charsio and format,
> which is useful in many contexts. Some remark about
> the 30x modules, they usually a more based on
> 
> additional native routines. This is unlike the 40x
> modules, which can have a pure Prolog reference
> implementation.
> 
> Mild Shock schrieb:
>> How about some of these PIPs:
>>
>> PIP401: library(lists)
>> Provide predicates such as nth1/3, last/2, etc…
>>
>> PIP402: library(sets)
>> Provide predicates such as union/3, subset/2, etc…
>>
>> PIP403: library(sequence)
>> Provide predicates such as call_nth/2, limit/2, etc…
>>
>> PIP404: library(aggregate)
>> Provide predicates such as aggregate_all/3, aggregate/3, etc…
>>
>> There was once an effort Prolog Commons, which has
>> some overlap with the above PIPs:
>>
>> The Prolog Commons Group - PART I - Library
>> https://prolog-commons.org/PrologCommons.html/part_library.html
>>
>> But its more modularized than just a Prologue to Prolog,
>> which has a few list predicates and miscellaneous.
>>
>>
> 

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

#14218 — Re: Even More Prolog Improvement Proposals (PIPs) [PIP301 - PIP303] (Was: More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404])

Ok, Scryer Prolog calls it library(arithmetic).
I prefer library(math), since many other programming
languages have Math.random(). But if I remember

well Scryer Prolog has a separate library for
random numbers. The library(arithemtic) might
provide a popcount/2 predicate, but it doesn't

provide a popcount/2 evaluable function. I get this error:

?- ['gridn.p'].
    error(type_error(evaluable,popcount/1),load/1).

Thats a pitty, one more obstacle in portable Prolog code.

P.S.: I know it is hard to make evaluable functions
definable in modules or Prolog text more general.
Especially since executing a Prolog defined evaluable

functions can be non-trivial in terms of stack etc..,
since evaluable functions just like unification etc..
might use other stacks, and therefore mixing with

the Prolog stack can lead to bad performance, because
of some impedence mismatch. But there is a nice compromise,
for native libraries it might be easier to register

a new evaluable function.

Mild Shock schrieb:
> And this one:
> 
> PIP304: library(math)
> Evaluable functions such as popcount/1, etc…
> 
> The idea of a library(math) is brand new,
> I first had it named library(random) and
> then it got out of hands, exploded and
> 
> had many bitwise operations.
> 
> Mild Shock schrieb:
>> Also interesting development, there is something
>> like “Prologue to Prolog C”, where C possibly
>> stands for cryptography. So maybe a further PIP:
>>
>> PIP301: library(crypto)
>> Predicates such as crypto_data_hash/3, etc…
>>
>> PIP302: library(charsio)
>> Predicates such as open_memory_file/2, etc…
>>
>> PIP303: library(format)
>> Predicates such as format/3, etc…
>>
>> In the above I have also added charsio and format,
>> which is useful in many contexts. Some remark about
>> the 30x modules, they usually a more based on
>>
>> additional native routines. This is unlike the 40x
>> modules, which can have a pure Prolog reference
>> implementation.
>>
>> Mild Shock schrieb:
>>> How about some of these PIPs:
>>>
>>> PIP401: library(lists)
>>> Provide predicates such as nth1/3, last/2, etc…
>>>
>>> PIP402: library(sets)
>>> Provide predicates such as union/3, subset/2, etc…
>>>
>>> PIP403: library(sequence)
>>> Provide predicates such as call_nth/2, limit/2, etc…
>>>
>>> PIP404: library(aggregate)
>>> Provide predicates such as aggregate_all/3, aggregate/3, etc…
>>>
>>> There was once an effort Prolog Commons, which has
>>> some overlap with the above PIPs:
>>>
>>> The Prolog Commons Group - PART I - Library
>>> https://prolog-commons.org/PrologCommons.html/part_library.html
>>>
>>> But its more modularized than just a Prologue to Prolog,
>>> which has a few list predicates and miscellaneous.
>>>
>>>
>>
> 

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

#14223 — A FFI for evaluable functions

The implementation to allow native libraries to register
new evaluable functions is the same as how predicates
are consulted. Take these two files:

$ cat > foo.p

test :- hello.

$ cat > bar.p

hello :- write('hello'), nl.

If I consult foo.p before bar.p there is a forward reference.
But if I ultimately consult bar.p the forward reference is
resolved. How does a Prolog system do that?

$ target/release/scryer-prolog
?- ['foo.p'].
    true.

?- test.
    error(existence_error(procedure,hello/0),hello/0).

?- ['bar.p'].
    true.

?- test.
hello
    true.

Now enhance is/2, etc... so that it uses the same resultion
meachanism, but only for the evaluable function namespace,
and provide a FFI where one can register evaluable functions,

in the evaluable function namespace, eh voila you are done,
makeing your Prolog extensible. Allowing to register evaluable
functions like gdc/2, popcount/1, etc.. outside of the core.

Mild Shock schrieb:
> The new multilingual strings are also an exercise in
> Novacore. There were a few issues that needed novel
> Prolog solutions, to make a Novacore solution.
> 
> One problem was I didn't want to use library(format)
> and format/3 to format multilingual strings when
> generating error messages. This addresses more
> 
> the later multilingual strings processing than the
> multilingual strings store itself. So how resolve this
> paradox? Here is my take, a mini format/3 boostraped
> 
> from the Dogelog Player specific atom_split/3:
> 
> % sys_inter_polate(+Stream, +Atom, +List)
> sys_inter_polate(Stream, Template, Args) :-
>     atom_split(Template, '~', [Head|Tail]),
>     put_atom(Stream, Head),
>     sys_zipper_output(Args, Tail, Stream).
> 
> % sys_zipper_output(+List, +List, +Stream)
> sys_zipper_output([Arg|Args], [Head|Tail], Stream) :-
>     writeq(Stream, Arg),
>     put_atom(Stream, Head),
>     sys_zipper_output(Args, Tail, Stream).
> sys_zipper_output([], [], _).
> 
> It only understands format specifier '~', but is sufficient:
> 
> /* German Text */
> strings('syntax_error.singleton_var', de, 'Alleinstehende Variable(n) ~, anonyme Variable(n) (_) benutzen.').
> 
> /* English and Fallback Text */
> strings('syntax_error.singleton_var', '', 'Singleton variable(s) ~, use anonymous variable(s) (_).').
> 
> LoL
> 

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

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

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

csiph-web