From Newsgroup: comp.lang.prolog

Hi,

I don't know, but 100x times slower than
SWI-Prolog doesn't sound good for Scryer Prolog.
And the 10x times slower than SWI-Prolog

are also not nice for Trealla Prolog. But I
guess Trealla uses C code programming that
has passed the time of test. What is Scryer

using? Well they do not use something that
is far away from the Strudel Coding Style for
Music, namely I find things like:

let arity = self.code[current_pred_start..current_pred_end]
.iter()
.flat_map(Instruction::registers)
.flat_map(|r| match r {
RegType::Temp(t) => Some(t),
_ => None,
})
.max()
.unwrap_or(0);
https://github.com/mthom/scryer-prolog/issues/3175

These things usually don't perform well. Even
if they process tuple oriented and not
set oriented, still the programming style

induces a lot of overhead, unless the compiler
does agressively massage the code. Possibly
only Haskell can do, since its longer in the

bussiness. Not sure about Rust. Basically an iter()
is a constructor and an arrow function is a constructor,
and they create objects! Also the argument threading

can be less efficient than a code block with
registers and a traditional loop. A flat
map is even a special kind of a horror among

pipeline elements, since it usually needs a
little state. Maybe using the novel C+20 Pipes
would help. They are quite charming, even passing

sentinells around. LoL

Bye

Mild Shock schrieb:

Hi,

The same example values also create fishy 🐟
sorting using native sorting in Scryer Prolog:

/* Scryer Prolog 0.9.4-417 */
?- values([z,x,y], A), sort(A, B),
   values([x,y,z], C), sort(C, D), B == D.
   false. /* fishy 🐟 */

Or using native sorting in SWI-Prolog:

/* SWI-Prolog 9.3.25 */
?- values([z,x,y], A), sort(A, B),
   values([x,y,z], C), sort(C, D), B == D.
false. /* fishy 🐟 */

Bye

Mild Shock schrieb:

I checked that your examples are not counter
examples for my compare_with_stack/3.

What makes you think the values I show, X, Y
and Z, are possible in a total linear ordering?
The values also break predsort/3, you can easily
verify that sort([x,y,z]) =\= sort([y,x,z]):

value(x, X) :- X = X-0-9-7-6-5-4-3-2-1.
value(y, Y) :- Y = Y-7-5-8-2-4-1.
value(z, Z) :- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1.

values(L, R) :- maplist(value, L, R).

?- values([x,y,z], A), predsort(compare_with_stack, A, B),
    values([y,x,z], C), predsort(compare_with_stack, C, D),
    B == D.
false.

But expectation would be sort([x,y,z]) ==
sort([y,x,z]) since sort/2 should be immune
to permutation. If this isn’t enough proof that
there is something fishy in compare_with_stack/3 ,

well then I don’t know, maybe the earth is indeed flat?

--- Synchronet 3.21a-Linux NewsLink 1.2