This addresses #2713. Many thanks to @notoria for reporting this
excellent case!
Example:
?- portray_clause(A = @).
A= @ .
true.
At other positions the now inserted space is unnecessary, as in:
?- portray_clause((head:- @,b)).
head :-
@ ,
b.
true.
The toplevel has a similar issue:
?- C = # ; false.
C = # |<-- cursor is here; redundant space after #
There may be a way to solve this issue for all cases like this.
Many thanks to @hurufu for the very nice definition!
This is until library(random) provides this functionality,
and a good name is found for it. See #2670.
This usage is now considered deprecated. Use strings instead for
greater efficiency and type consistency in your applications.
This functionality is a candidate for removal in a future commit.
In particular, octet does *not* mean that the input is a list of
Prolog bytes in the sense of "integers between 0..255", but that the
character codes are used directly as byte values.
These non-terminals take a grammar rule body and additional arguments
as arguments. These arguments are appended to the first argument.
A key motivation for the introduction of these non-terminals is found
in the discussion and sample code provided by @bakaq in:
https://github.com/mthom/scryer-prolog/discussions/2260
In this way, portable higher-order DCG programming is possible while
keeping the logical grammar rule expansion implementation dependent.
Example:
?- phrase(phrase('.', a, []), Cs).
Cs = "a".
This allows subsequently invoked constraints to take the entire
filtering results into account, instead of being invoked when the
obtained information is not yet entirely used.
The SICStus-style attributed variables mechanism of Scryer Prolog
automatically prevents very subtle interaction problems that can arise
in systems that do not give all variables that are involved in a
unification an opportunity to schedule their propagators.
An example of such a subtle interaction is:
?- tuples_in([[A,C,B]], [[3,1,3],[4,2,4]]),
global_cardinality([A,B,D], [3-1,4-2]),
A = 4.
A = 4 causes pgcc_check/1 and pgcc/2 to be queued in the fast and slow
queue, respectively. In the fast queue, there is also rel_tuple/2,
which is worked off after gcc_check/1 and simultaneously instantiates
both C and B (to 2 and 4, respectively). Instantiation of C schedules
do_queue//0 from verify_attributes/3. Note that C does not participate
in the global_cardinality/2 constraint.
Critically, B also gets an opportunity to schedule its propagators in
this case, so another gcc_check/1 is run before gcc_global/2!
This allows subsequently invoked constraints to take the entire
filtering results into account, instead of being invoked when the
obtained information is not yet entirely used.
It speeds up programs such as the one in:
https://github.com/triska/clpz/issues/26
The main motivation for this change is the introduction of the newly
available predicate ed25519_seed_keypair/2, allowing to generate a key
pair from a given seed. In this way, a key pair can be dynamically
generated from (for example) a password, using crypto_password_hash/3
in combination with crypto_data_hkdf/4 to generate the seed. The
advantage of this method is that the private key need not be stored at
all anywhere.
It is not possible to add a corresponding feature to ring, since it is
closed as "not planned": https://github.com/briansmith/ring/issues/1003
I also used this opportunity to move more of the logic to Prolog. We
now have total control of the key pair representation, and I also
changed the representation to conform to the PKCS#8 v2 standard,
something that only later ring versions do, while still being
backwards compatible with tools that produce a wrong representation
including earlier ring versions.
Another great advantage we get from this change is that the Ed25519
predicates now also run on the 32-bit and WASM versions of Scryer.
One use case is to ensure that once/1 is safe to use:
term_si(Goal),
once(Goal)
In such cases, Goal is ground and can yield at most one solution,
therefore once/1 does not remove any solutions.
Example:
?- time(member(X, "abc")).
% CPU time: 0.000s, 1 inference
X = a
; % CPU time: 0.000s, 3 inferences
X = b
; % CPU time: 0.000s, 3 inferences
X = c.
This is an initial step towards addressing #1039.
If reification constraints (such as reified equality) are triggered
here, then they may wish to disable this propagator and remove
attributes from auxiliary variables. If the pexp/3 propagation is
interrupted for that purpose, then the attributes will be
unintentionally reattached by the following fd_put/3 calls in this
propagator. We must ensure that this propagator completely finishes,
so we queue the triggered propagators for later processing.
geq/2 implements propagator activation outside the queue, and thus
should not be used in propagators in the way it was used here.
pexp/3 by itself may not seem particularly important. However, it can
arise by metamorphosis from Var*Var. Example:
?- A#<==> -1#=C*C, C in 0..1.
A = 0, clpz:(C in 0..1).
This addresses #2089.
This addresses all remaining cases from #2083, excepting (//)/2:
?- #\ 1#=(X*X)/0.
clpz:(X in inf..sup).
?- #\ 1#=(X+X)/0.
clpz:(X in inf..sup).
Still remaining:
?- #\ 0#=(Y// -1)/0.
clpz:(-1*Y#=_A).
Quoting from 7.11 Flags:
NOTE - A built-in predicate current_prolog_flag(Flag, Value)
(8.17.2) enables a program to discover all the flags supported
by a processor and their current values.
The (+)/1 prefix in get_atts/2 at line 4219 by itself already causes a
greater than 15% slowdown for the benchmark shown in #1730:
?- N #= 2^14,
time(((between(1, N, _),
X #\= Y,
false)
; true)).
The performance impact is not a good reason to remove the optional
(+)/1 prefix! Performance issues should be addressed at the root, in
this case get_atts/2 (#1962). We should never manually work around
performance issues in built-in predicates.
In contrast, readability is a good argument, and I find the calls
slightly easier to read without the optional (+)/1 prefix.
The prefix is now consistently omitted when possible.
This is to facilitate WASM compilation as currently worked on
by @rujialiu in #615. Many thanks, and many thanks to @pornin
for crrl which makes this possible!
Markus Triska