I had a discussion with Sloof Lirpa on Discord. He agrees
with Markus Triskas analysis of aggregate_all/3, an
analysis which can be transmutate to setof/3 from the
ISO core standard: So we would for example:
?- setof(X, member(X, [b,a,c]), [a]).
false.
But adding a constraint (X = a) would make the query succeed:
?- X=a, setof(X, member(X, [b,a,c]), [a]).
X = a.
This non-monotonic behaviour complicates reasoning
about programs considerably, and also makes declarative
debugging (library(debug)) inapplicable. Are there
monotonic alternatives that would be useful in at least
some of the cases in which this non-monotonic construct is
commonly used? It would be great to establish a more
declarative alternative.
Same problem with negation as failure, credits go
to Elias Whitlow. So we would for example have:
?- \+ X = b.
false.
But adding a constraint (X = a) would make the query succeed:
?- X=a, \+ X = b.
X = a.
This non-monotonic behaviour complicates reasoning
about programs considerably, and also makes declarative
debugging (library(debug)) inapplicable. Are there
monotonic alternatives that would be useful in at least
some of the cases in which this non-monotonic construct is
commonly used? It would be great to establish a more
declarative alternative.
Mostowski Collapse schrieb am Freitag, 12. August 2022 um 01:00:22 UTC+2:
I had a discussion with Sloof Lirpa on Discord. He agrees
with Markus Triskas analysis of aggregate_all/3, an
analysis which can be transmutate to setof/3 from the
ISO core standard: So we would for example:
?- setof(X, member(X, [b,a,c]), [a]).
false.
But adding a constraint (X = a) would make the query succeed:
?- X=a, setof(X, member(X, [b,a,c]), [a]).
X = a.
This non-monotonic behaviour complicates reasoning
about programs considerably, and also makes declarative
debugging (library(debug)) inapplicable. Are there
monotonic alternatives that would be useful in at least
some of the cases in which this non-monotonic construct is
commonly used? It would be great to establish a more
declarative alternative.
Looks like its dooms day for most of ISO core standard and that the
language is completely wrecked. That (==)/2, ground/1 and nonvar/1
are also suspicious is seen here:
(==)/2 is non-monotonoic:
```
?- X == a.
false.
?- X = a, X == a.
X = a.
```
Further ground/1 is non-monotonoic:
```
?- ground(f(X)).
false.
?- X = a, ground(f(X)).
X = a.
```
Finally nonvar/1 is non-monotonic:
```
?- nonvar(X).
false.
?- X = a, nonvar(X).
X = a.
```
Possibly sort/2 is also non-monotonic. Although the situation is
slightly different. In Scryer Prolog the predicate, when used in
a conjunction, can switch from false to error:
?- sort([1,2,3], X), X = [].
false.
?- X = a, sort([1,2,3], X), X = [].
error(type_error(list,a),sort/2).
So I guess Markus Triskas observation also applies to sort/2?
And possibly also to keysort/2?
Mostowski Collapse schrieb am Freitag, 12. August 2022 um 08:24:39 UTC+2:
Looks like its dooms day for most of ISO core standard and that the language is completely wrecked. That (==)/2, ground/1 and nonvar/1
are also suspicious is seen here:
(==)/2 is non-monotonoic:
```
?- X == a.
false.
?- X = a, X == a.
X = a.
```
Further ground/1 is non-monotonoic:
```
?- ground(f(X)).
false.
?- X = a, ground(f(X)).
X = a.
```
Finally nonvar/1 is non-monotonic:
```
?- nonvar(X).
false.
?- X = a, nonvar(X).
X = a.
```
I had a discussion with Sloof Lirpa on Discord.
For better declarativity, possibly some predicates need to be
made to fail, instead of throw an error, if they receive an
argument of the wrong type, like here:
?- length([1,2,3], a).
error(type_error(integer,a),length/2).
More declarative behaviour, based on Markus Triskas
observation, would be:
?- length([1,2,3], a).
false
Does Scryer Prolog already have a switch to switch off exceptions?
SWI-Prolog discourse had a long discussion errors considered
harmful dealing with this issue.
https://swi-prolog.discourse.group/t/errors-considered-harmful/3574/88
The struggle is real, possibly a result of Fastfood McDonald
approach to Prolog? Dunno. Call the language BigMacLog then?
https://github.com/mthom/scryer-prolog/issues/1564
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:03:08 UTC+2:
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
For example subtract/3 has complexity
O(n*m)
And ord_subtract/3, if you do it wrong, and
insert sort/2 everywhere, has complexity:
O(n*log n + m*log m)
subtract/3 is better than ord_subtract/3 for m<<n.
But if you manage to elminate the sort/2,
then ord_subtract/2 is only O(n+m) and better again.
So there is a lot to deliberate.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:16:11 UTC+2:
The struggle is real, possibly a result of Fastfood McDonald
approach to Prolog? Dunno. Call the language BigMacLog then?
https://github.com/mthom/scryer-prolog/issues/1564
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:03:08 UTC+2:
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
Here some penny of thought. If Scryer Prolog would:
1. Rethink the notion of pure, and incorporate some
results of logic programming concerning SLDNF
2. Allow (+)//1 in DCG, which was refused here
on dubious grounds:
https://github.com/mthom/scryer-prolog/issues/1479
Then it could abandon the old fashioned DCG, were D is taken
literally as definite, i.e. without negation and pure. And it could
move towards the more modern grammar formalism:
parsing expression grammar (PEG) https://en.wikipedia.org/wiki/Parsing_expression_grammar
Its quite easy to map PEG to DCG, where D is not interpreted
that strict. And this can give much more efficient parsers, that
are at the same time concise and declarative.
Edit 14.08.2022
Even the Ruby ISO standard uses some PEG inspired formalism
for their grammar. Check it out.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 01:18:08 UTC+2:
New JSON parser is extremly slow https://github.com/mthom/scryer-prolog/issues/1566
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 01:09:34 UTC+2:
Why Aprils Fool? Well this here was 10 Apr 2021, almost Aprils Fool day:
How it started:
Scryer Prolog sets a new standard for efficient encoding of lists of characters, which we mean when we say "strings" in the context of
Scryer Prolog. A key advantage of the efficient encoding is that
DCGs can be used for describing the string, since it is simply a list.
A good infrastructure for processing JSON with Scryer Prolog uses
this representation, and describes JSON format with a DCG. https://github.com/mthom/scryer-prolog/discussions/892
How its going:
$ target/release/scryer-prolog -v
"v0.9.0-181-g8e9302ea"
$ target/release/scryer-prolog
?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)).
% CPU time: 1.953s
true.
/* SWI-Prolog (threaded, 64 bits, version 8.5.14) */
?- time((between(1,1000,_), data(X), atom_json_term(X,Y,[]), fail; true)).
% 48,000 inferences, 0.000 CPU in 0.007 seconds (0% CPU, Infinite Lips) true.
The test data was simply:
data("{ \"a\":123 }").
I got the idea for this nasty test data, after inspecting the source code
Why Aprils Fool? Well this here was 10 Apr 2021, almost Aprils Fool day:
How it started:
Scryer Prolog sets a new standard for efficient encoding of lists of characters, which we mean when we say "strings" in the context of
Scryer Prolog. A key advantage of the efficient encoding is that
DCGs can be used for describing the string, since it is simply a list.
A good infrastructure for processing JSON with Scryer Prolog uses
this representation, and describes JSON format with a DCG. https://github.com/mthom/scryer-prolog/discussions/892
How its going:
$ target/release/scryer-prolog -v
"v0.9.0-181-g8e9302ea"
$ target/release/scryer-prolog
?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)).
% CPU time: 1.953s
true.
/* SWI-Prolog (threaded, 64 bits, version 8.5.14) */
?- time((between(1,1000,_), data(X), atom_json_term(X,Y,[]), fail; true)).
% 48,000 inferences, 0.000 CPU in 0.007 seconds (0% CPU, Infinite Lips)
true.
The test data was simply:
data("{ \"a\":123 }").
I got the idea for this nasty test data, after inspecting the source code
of the new library(serialization/json). Just compare to what Jan W. is doing. Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:23:30 UTC+2:
For example subtract/3 has complexity
O(n*m)
And ord_subtract/3, if you do it wrong, and
insert sort/2 everywhere, has complexity:
O(n*log n + m*log m)
subtract/3 is better than ord_subtract/3 for m<<n.
But if you manage to elminate the sort/2,
then ord_subtract/2 is only O(n+m) and better again.
So there is a lot to deliberate.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:16:11 UTC+2:
The struggle is real, possibly a result of Fastfood McDonald
approach to Prolog? Dunno. Call the language BigMacLog then?
https://github.com/mthom/scryer-prolog/issues/1564
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:03:08 UTC+2:
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
New JSON parser is extremly slow https://github.com/mthom/scryer-prolog/issues/1566
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 01:09:34 UTC+2:
Why Aprils Fool? Well this here was 10 Apr 2021, almost Aprils Fool day:
How it started:
Scryer Prolog sets a new standard for efficient encoding of lists of characters, which we mean when we say "strings" in the context of
Scryer Prolog. A key advantage of the efficient encoding is that
DCGs can be used for describing the string, since it is simply a list.
A good infrastructure for processing JSON with Scryer Prolog uses
this representation, and describes JSON format with a DCG. https://github.com/mthom/scryer-prolog/discussions/892
How its going:
$ target/release/scryer-prolog -v
"v0.9.0-181-g8e9302ea"
$ target/release/scryer-prolog
?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)).
% CPU time: 1.953s
true.
/* SWI-Prolog (threaded, 64 bits, version 8.5.14) */
?- time((between(1,1000,_), data(X), atom_json_term(X,Y,[]), fail; true)). % 48,000 inferences, 0.000 CPU in 0.007 seconds (0% CPU, Infinite Lips) true.
The test data was simply:
data("{ \"a\":123 }").
I got the idea for this nasty test data, after inspecting the source code of the new library(serialization/json). Just compare to what Jan W. is doing.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:23:30 UTC+2:
For example subtract/3 has complexity
O(n*m)
And ord_subtract/3, if you do it wrong, and
insert sort/2 everywhere, has complexity:
O(n*log n + m*log m)
subtract/3 is better than ord_subtract/3 for m<<n.
But if you manage to elminate the sort/2,
then ord_subtract/2 is only O(n+m) and better again.
So there is a lot to deliberate.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:16:11 UTC+2:
The struggle is real, possibly a result of Fastfood McDonald
approach to Prolog? Dunno. Call the language BigMacLog then?
https://github.com/mthom/scryer-prolog/issues/1564
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:03:08 UTC+2:
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
And the winner is:
In the category "muito loco":
- Ciao Prolog: A lot of new tickets and a lot of bla bla
In the category "gets work done":
- SWI-Prolog: Just copy paste the rextester Prolog text to here, it wurks! https://dev.swi-prolog.org/wasm/shell
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:03:08 UTC+2:
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
Pay attention! So Logtalk and Scryer struggles with ‘|’? https://github.com/mthom/scryer-prolog/issues/1571
Its not an issue for the fCube version I posted here. Since it has:
:- op(700, xfy, <=>).
:- op(600, xfy, =>).
:- op(500, xfy, v).
:- op(400, xfy, &).
:- op(300, fy, ~).
fCube: an efficient prover for Intuitionistic propositional Logic
in Rextester - Joseph Vidal-Rosset, 2022
https://rextester.com/SEOO25214
Rextester is funny, it has an integrated version management system,
maybe a wikipedia variant? Will Ciao or SWIPL WASM have the same?
Mostowski Collapse schrieb am Montag, 15. August 2022 um 11:44:26 UTC+2:
And the winner is:
In the category "muito loco":
- Ciao Prolog: A lot of new tickets and a lot of bla bla
In the category "gets work done":
- SWI-Prolog: Just copy paste the rextester Prolog text to here, it wurks! https://dev.swi-prolog.org/wasm/shell
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:03:08 UTC+2:
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
Oops its the other way around, the Joseph Vidal-Rosset
version is the dangerous version it has:
% operator definitions (TPTP syntax)
:- op( 500, fy, ~). % negation
:- op(1000, xfy, &). % conjunction
:- op(1100, xfy, '|'). % disjunction
:- op(1110, xfy, =>). % conditional
:- op(1120, xfy, <=>). % biconditional
Well I started allowing '|' redefinition in Jekejeke Prolog and
Dogelog Player, SWI-Prolog allows the same, no error here:
/* SWI-Prolog (threaded, 64 bits, version 8.5.14) */
?- op(1100, xfy, '|').
true.
This was done in favor of all the legacy TPTP syntax stuff.
Mostowski Collapse schrieb am Dienstag, 16. August 2022 um 01:17:39 UTC+2:
Pay attention! So Logtalk and Scryer struggles with ‘|’? https://github.com/mthom/scryer-prolog/issues/1571
Its not an issue for the fCube version I posted here. Since it has:
:- op(700, xfy, <=>).
:- op(600, xfy, =>).
:- op(500, xfy, v).
:- op(400, xfy, &).
:- op(300, fy, ~).
fCube: an efficient prover for Intuitionistic propositional Logic
in Rextester - Joseph Vidal-Rosset, 2022
https://rextester.com/SEOO25214
Rextester is funny, it has an integrated version management system,
maybe a wikipedia variant? Will Ciao or SWIPL WASM have the same? Mostowski Collapse schrieb am Montag, 15. August 2022 um 11:44:26 UTC+2:
And the winner is:
In the category "muito loco":
- Ciao Prolog: A lot of new tickets and a lot of bla bla
In the category "gets work done":
- SWI-Prolog: Just copy paste the rextester Prolog text to here, it wurks!
https://dev.swi-prolog.org/wasm/shell
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:03:08 UTC+2:
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
I like the quality of the new JSON parser for Scryer Prolog.
Did anybody review the code?
I get for example:
?- number_chars(X, "7.075657757024522e-7").
X = 7.075657757024522e-7.
?- json_chars(X, "7.075657757024522e-7", "").
X = number(7.075657757024521e-7)
The two results are different:
?- C = "7.075657757024522e-7",
number_chars(X, C),
json_chars(number(Y), C, ""),
X == Y.
false.
LoL
SWI-Prolog doesn't have this error:
?- use_module(library(http/json)).
true.
?- number_chars(X, "7.075657757024522e-7").
X = 7.075657757024522e-7.
?- atom_json_term('7.075657757024522e-7', X, []).
X = 7.075657757024522e-7.
Mostowski Collapse schrieb am Dienstag, 16. August 2022 um 02:40:57 UTC+2:
I like the quality of the new JSON parser for Scryer Prolog.
Did anybody review the code?
I get for example:
?- number_chars(X, "7.075657757024522e-7").
X = 7.075657757024522e-7.
?- json_chars(X, "7.075657757024522e-7", "").
X = number(7.075657757024521e-7)
The two results are different:
?- C = "7.075657757024522e-7",
number_chars(X, C),
json_chars(number(Y), C, ""),
X == Y.
false.
LoL
I still don't understand why '|' even landed in DCG,
it only causes problems. Back in the 1980's nobody
used DCG like that:
The first clause on the right-hand side:
verb (change) — >
[c] ; [ch] ; [change] ; [set] .
is satisfied if the token is any one of the four listed
(the ";" is Prolog's way of ex- pressing the OR relation among clauses). https://archive.org/details/byte-magazine-1987-08/page/n181/mode/2up
And still your own folks nowadays dont use '|':
```
json_ws -->
( parsing ->
json_ws_greedy
; json_ws_lazy
).
``` https://github.com/mthom/scryer-prolog/blob/master/src/lib/serialization/json.pl
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 01:45:08 UTC+2:
Here some penny of thought. If Scryer Prolog would:
1. Rethink the notion of pure, and incorporate some
results of logic programming concerning SLDNF
2. Allow (+)//1 in DCG, which was refused here
on dubious grounds:
https://github.com/mthom/scryer-prolog/issues/1479
Then it could abandon the old fashioned DCG, were D is taken
literally as definite, i.e. without negation and pure. And it could
move towards the more modern grammar formalism:
parsing expression grammar (PEG) https://en.wikipedia.org/wiki/Parsing_expression_grammar
Its quite easy to map PEG to DCG, where D is not interpreted
that strict. And this can give much more efficient parsers, that
are at the same time concise and declarative.
Edit 14.08.2022
Even the Ruby ISO standard uses some PEG inspired formalism
for their grammar. Check it out.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 01:18:08 UTC+2:
New JSON parser is extremly slow https://github.com/mthom/scryer-prolog/issues/1566
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 01:09:34 UTC+2:
Why Aprils Fool? Well this here was 10 Apr 2021, almost Aprils Fool day:
How it started:
Scryer Prolog sets a new standard for efficient encoding of lists of characters, which we mean when we say "strings" in the context of Scryer Prolog. A key advantage of the efficient encoding is that
DCGs can be used for describing the string, since it is simply a list. A good infrastructure for processing JSON with Scryer Prolog uses
this representation, and describes JSON format with a DCG. https://github.com/mthom/scryer-prolog/discussions/892
How its going:
$ target/release/scryer-prolog -v
"v0.9.0-181-g8e9302ea"
$ target/release/scryer-prolog
?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)). % CPU time: 1.953s
true.
/* SWI-Prolog (threaded, 64 bits, version 8.5.14) */
?- time((between(1,1000,_), data(X), atom_json_term(X,Y,[]), fail; true)).
% 48,000 inferences, 0.000 CPU in 0.007 seconds (0% CPU, Infinite Lips)
true.
The test data was simply:
data("{ \"a\":123 }").
I got the idea for this nasty test data, after inspecting the source code
of the new library(serialization/json). Just compare to what Jan W. is doing.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:23:30 UTC+2:
For example subtract/3 has complexity
O(n*m)
And ord_subtract/3, if you do it wrong, and
insert sort/2 everywhere, has complexity:
O(n*log n + m*log m)
subtract/3 is better than ord_subtract/3 for m<<n.
But if you manage to elminate the sort/2,
then ord_subtract/2 is only O(n+m) and better again.
So there is a lot to deliberate.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:16:11 UTC+2:
The struggle is real, possibly a result of Fastfood McDonald approach to Prolog? Dunno. Call the language BigMacLog then?
https://github.com/mthom/scryer-prolog/issues/1564
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:03:08 UTC+2:
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic
https://rextester.com/SEOO25214
Can you make it run?
Here some penny of thought. If Scryer Prolog would:
1. Rethink the notion of pure, and incorporate some
results of logic programming concerning SLDNF
2. Allow (+)//1 in DCG, which was refused here
on dubious grounds:
https://github.com/mthom/scryer-prolog/issues/1479
Then it could abandon the old fashioned DCG, were D is taken
literally as definite, i.e. without negation and pure. And it could
move towards the more modern grammar formalism:
parsing expression grammar (PEG) https://en.wikipedia.org/wiki/Parsing_expression_grammar
Its quite easy to map PEG to DCG, where D is not interpreted
that strict. And this can give much more efficient parsers, that
are at the same time concise and declarative.
Edit 14.08.2022
Even the Ruby ISO standard uses some PEG inspired formalism
for their grammar. Check it out.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 01:18:08 UTC+2:
New JSON parser is extremly slow https://github.com/mthom/scryer-prolog/issues/1566
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 01:09:34 UTC+2:
Why Aprils Fool? Well this here was 10 Apr 2021, almost Aprils Fool day:
How it started:
Scryer Prolog sets a new standard for efficient encoding of lists of characters, which we mean when we say "strings" in the context of
Scryer Prolog. A key advantage of the efficient encoding is that
DCGs can be used for describing the string, since it is simply a list.
A good infrastructure for processing JSON with Scryer Prolog uses
this representation, and describes JSON format with a DCG. https://github.com/mthom/scryer-prolog/discussions/892
How its going:
$ target/release/scryer-prolog -v
"v0.9.0-181-g8e9302ea"
$ target/release/scryer-prolog
?- time((between(1,1000,_), data(X), json_chars(Y,X,[]), fail; true)).
% CPU time: 1.953s
true.
/* SWI-Prolog (threaded, 64 bits, version 8.5.14) */
?- time((between(1,1000,_), data(X), atom_json_term(X,Y,[]), fail; true)).
% 48,000 inferences, 0.000 CPU in 0.007 seconds (0% CPU, Infinite Lips) true.
The test data was simply:
data("{ \"a\":123 }").
I got the idea for this nasty test data, after inspecting the source code
of the new library(serialization/json). Just compare to what Jan W. is doing.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:23:30 UTC+2:
For example subtract/3 has complexity
O(n*m)
And ord_subtract/3, if you do it wrong, and
insert sort/2 everywhere, has complexity:
O(n*log n + m*log m)
subtract/3 is better than ord_subtract/3 for m<<n.
But if you manage to elminate the sort/2,
then ord_subtract/2 is only O(n+m) and better again.
So there is a lot to deliberate.
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:16:11 UTC+2:
The struggle is real, possibly a result of Fastfood McDonald approach to Prolog? Dunno. Call the language BigMacLog then?
https://github.com/mthom/scryer-prolog/issues/1564
Mostowski Collapse schrieb am Sonntag, 14. August 2022 um 00:03:08 UTC+2:
Here is the Scryer Prolog challenge:
fCube: an efficient prover for Intuitionistic propositional Logic https://rextester.com/SEOO25214
Can you make it run?
BTW: I used this fuzzer to find the number:
?- repeat, random(X), Y is X/1000000,
number_chars(Y,C),
json_chars(number(Z),C,""), Z \== Y.
See also:
https://en.wikipedia.org/wiki/Fuzzing
Mostowski Collapse schrieb am Dienstag, 16. August 2022 um 02:47:12 UTC+2:
SWI-Prolog doesn't have this error:
?- use_module(library(http/json)).
true.
?- number_chars(X, "7.075657757024522e-7").
X = 7.075657757024522e-7.
?- atom_json_term('7.075657757024522e-7', X, []).
X = 7.075657757024522e-7.
Mostowski Collapse schrieb am Dienstag, 16. August 2022 um 02:40:57 UTC+2:
I like the quality of the new JSON parser for Scryer Prolog.
Did anybody review the code?
I get for example:
?- number_chars(X, "7.075657757024522e-7").
X = 7.075657757024522e-7.
?- json_chars(X, "7.075657757024522e-7", "").
X = number(7.075657757024521e-7)
The two results are different:
?- C = "7.075657757024522e-7",
number_chars(X, C),
json_chars(number(Y), C, ""),
X == Y.
false.
LoL
I still don't understand why '|' even landed in DCG,
it only causes problems. Back in the 1980's nobody
used DCG like that:
The first clause on the right-hand side:
verb (change) — >
[c] ; [ch] ; [change] ; [set] .
is satisfied if the token is any one of the four listed
(the ";" is Prolog's way of ex- pressing the OR relation among clauses). https://archive.org/details/byte-magazine-1987-08/page/n181/mode/2up
And still your own folks nowadays dont use '|':
```
json_ws -->
( parsing ->
json_ws_greedy
; json_ws_lazy
).
``` https://github.com/mthom/scryer-prolog/blob/master/src/lib/serialization/json.pl
Intersting bug in Scryer Prolog, only one solution:
$ ../target/release/scryer-prolog -v
"v0.9.0-175-g6b8e6204"
$ ../target/release/scryer-prolog
?- [tictac].
true.
?- best(["x-o", "o-x", "-x-"],x,Y).
Y = ["x-o","o-x","-xx"].
But then SWI-Prolog gives me 4 solutions:
/* SWI-Prolog (threaded, 64 bits, version 8.5.14) */
?- set_prolog_flag(double_quotes, chars).
true.
?- best(["x-o", "o-x", "-x-"],x,Y).
Y = [[x, x, o], [o, -, x], [-, x, -]] ;
Y = [[x, -, o], [o, x, x], [-, x, -]] ;
Y = [[x, -, o], [o, -, x], [x, x, -]] ;
Y = [[x, -, o], [o, -, x], [-, x, x]].
Test case is here in this tar ball:
http://www.rubycap.ch/gist/bench.tar.gz
And Trealla has also no problem:
$ ../tpl -v
Trealla Prolog (c) Infradig 2020-2022, v2.1.11
$ ../tpl
?- ['tictac.p'].
true.
?- best(["x-o", "o-x", "-x-"],x,Y).
Y = ["xxo","o-x","-x-"]
; Y = ["x-o","oxx","-x-"]
; Y = ["x-o","o-x","xx-"]
; Y = ["x-o","o-x","-xx"].
Mostowski Collapse schrieb am Mittwoch, 31. August 2022 um 03:02:43 UTC+2:
Intersting bug in Scryer Prolog, only one solution:
$ ../target/release/scryer-prolog -v
"v0.9.0-175-g6b8e6204"
$ ../target/release/scryer-prolog
?- [tictac].
true.
?- best(["x-o", "o-x", "-x-"],x,Y).
Y = ["x-o","o-x","-xx"].
But then SWI-Prolog gives me 4 solutions:
/* SWI-Prolog (threaded, 64 bits, version 8.5.14) */
?- set_prolog_flag(double_quotes, chars).
true.
?- best(["x-o", "o-x", "-x-"],x,Y).
Y = [[x, x, o], [o, -, x], [-, x, -]] ;
Y = [[x, -, o], [o, x, x], [-, x, -]] ;
Y = [[x, -, o], [o, -, x], [x, x, -]] ;
Y = [[x, -, o], [o, -, x], [-, x, x]].
Test case is here in this tar ball:
http://www.rubycap.ch/gist/bench.tar.gz
Saw the bug first in an extremly fast tictac runtime,
and then used this fuzzer to find such a test case:
random_board([[A,B,C],[D,E,F],[H,I,J]]) :-
random_member(A, [o,-,x]),
random_member(B, [o,-,x]),
random_member(C, [o,-,x]),
random_member(D, [o,-,x]),
random_member(E, [o,-,x]),
random_member(F, [o,-,x]),
random_member(H, [o,-,x]),
random_member(I, [o,-,x]),
random_member(J, [o,-,x]).
Fuzzers are lit!
Mostowski Collapse schrieb am Mittwoch, 31. August 2022 um 03:09:56 UTC+2:
And Trealla has also no problem:
$ ../tpl -v
Trealla Prolog (c) Infradig 2020-2022, v2.1.11
$ ../tpl
?- ['tictac.p'].
true.
?- best(["x-o", "o-x", "-x-"],x,Y).
Y = ["xxo","o-x","-x-"]
; Y = ["x-o","oxx","-x-"]
; Y = ["x-o","o-x","xx-"]
; Y = ["x-o","o-x","-xx"].
Mostowski Collapse schrieb am Mittwoch, 31. August 2022 um 03:02:43 UTC+2:
Intersting bug in Scryer Prolog, only one solution:
$ ../target/release/scryer-prolog -v
"v0.9.0-175-g6b8e6204"
$ ../target/release/scryer-prolog
?- [tictac].
true.
?- best(["x-o", "o-x", "-x-"],x,Y).
Y = ["x-o","o-x","-xx"].
But then SWI-Prolog gives me 4 solutions:
/* SWI-Prolog (threaded, 64 bits, version 8.5.14) */
?- set_prolog_flag(double_quotes, chars).
true.
?- best(["x-o", "o-x", "-x-"],x,Y).
Y = [[x, x, o], [o, -, x], [-, x, -]] ;
Y = [[x, -, o], [o, x, x], [-, x, -]] ;
Y = [[x, -, o], [o, -, x], [x, x, -]] ;
Y = [[x, -, o], [o, -, x], [-, x, x]].
Test case is here in this tar ball:
http://www.rubycap.ch/gist/bench.tar.gz
Sloof Lirpa has changed his mind. He now says we don't
need library(sets) or library(ordsets), we can for example
do set union where naturally with:
?- A = [1,2,3], B=[2,3,4], setof(X, (member(X,A); member(X,B)), L).
A = [1, 2, 3],
B = [2, 3, 4],
L = [1, 2, 3, 4].
Sloof Lirpa now even makes the claim that setof/3 is
quite declarative. He gives this example, students that
have some courses:
course(berta, english).
course(berta, math).
course(berta, french).
course(carlo, math).
course(carlo, french).
course(carlo, biology).
He gives now this example of monotonicity:
?- setof(X, (course(berta, X), course(carlo, X)), L).
L = [french, math].
?- setof(X, (course(A, X), course(B, X)), L), A=berta, B=carlo.
A = berta,
B = carlo,
L = [french, math] ;
false.
Mostowski Collapse schrieb am Freitag, 12. August 2022 um 01:00:22 UTC+2:
I had a discussion with Sloof Lirpa on Discord. He agrees
with Markus Triskas analysis of aggregate_all/3, an
analysis which can be transmutate to setof/3 from the
ISO core standard: So we would for example:
?- setof(X, member(X, [b,a,c]), [a]).
false.
But adding a constraint (X = a) would make the query succeed:
?- X=a, setof(X, member(X, [b,a,c]), [a]).
X = a.
This non-monotonic behaviour complicates reasoning
about programs considerably, and also makes declarative
debugging (library(debug)) inapplicable. Are there
monotonic alternatives that would be useful in at least
some of the cases in which this non-monotonic construct is
commonly used? It would be great to establish a more
declarative alternative.
I had a discussion with Sloof Lirpa on Discord. He agrees
with Markus Triskas analysis of aggregate_all/3, an
analysis which can be transmutate to setof/3 from the
ISO core standard: So we would for example:
?- setof(X, member(X, [b,a,c]), [a]).
false.
But adding a constraint (X = a) would make the query succeed:
?- X=a, setof(X, member(X, [b,a,c]), [a]).
X = a.
This non-monotonic behaviour complicates reasoning
about programs considerably, and also makes declarative
debugging (library(debug)) inapplicable. Are there
monotonic alternatives that would be useful in at least
some of the cases in which this non-monotonic construct is
commonly used? It would be great to establish a more
declarative alternative.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 493 |
Nodes: | 16 (2 / 14) |
Uptime: | 159:05:00 |
Calls: | 9,700 |
Files: | 13,732 |
Messages: | 6,179,717 |