Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How Logtalk Nonsense missed the Python Bandwagon

88 views
Skip to first unread message

Mostowski Collapse

unread,
Sep 27, 2021, 1:07:12 PM9/27/21
to
Ha Ha, Python is an interesting language. They are like serial
killers, they produce one package after the other like sympy, numpy, etc..
and now they have cpmpy, pysat, etc..

Whereas Logtalk can even not provide a calendar date abstraction.
For example Logtalks Julian date is nothing object oriented, its
just a module, nothing else. Utter nonsense:

https://logtalk.org/docs/iso8601_0.html

So what is the success to Python?

Here is a speculation. It has to do with strict versus non-strict
evaluation strategies. When we look at constraint programming in
both camps we find:

Prolog is Non-Strict by Default:
==========================
Prolog terms by default are not evaluated. So CLP(FD) is for
example defined by introducing new predicates (#=)/2, ...
with the following arguments:

Expr_1 #= Expr_2
Etc...

The predicate (#=)/2 then takes the Prolog terms Expr_1 and
Expr_2 and analysis them. If everything in Expr_1 and Expr_2 is
ground it can divert into (=:=)/2 on the spot.

Otherwise the analysis of Expr_1 and Expr_2 leads to some
internal form that is posted as a constraint.

Python is Strict by Default:
======================
How solve the same problem of a constraint language in Python.
Well if you have that an expression a + b is realized as message
passing like in Smalltalk, i.e. a.__add__(b). You can

defined a datatype for a constraint variable, and then let the strict
evaluation algorithm build constrants for you. Currently I am not 100%
sure whether Python really does it that way, but was watching

Hakan recently and his new productions:
http://hakank.org/cpmpy/

So I find code like for example:

model = Model()
model += [x < 2]

a so called lazy container.

Mostowski Collapse

unread,
Sep 27, 2021, 1:18:51 PM9/27/21
to
I remember probing Logtalk on SWI-Prolog discourse, where
I tried to figure out whether Logtalk will ever provide a Smalltalk
like evaluator. I the got banned by SWI-Prolog asshole moderators.

But it seems the key to success, a 50 years old idea!!!

Its not only that Logtalk Nonsense missed the Python bandwagon.
Its also CLP(Z) from Scryer Prolog which isn't innovative concerning
constraint programming languages.

The disadvantages and advantages of the two approachs are as follows:

Disadvantage Prolog is Non-Strict by Default
=====================================
Very difficult to extend. I am not 100% sure whether this claim
holds, but usually the typical Markus Triska CLP(FD) is not designed
with extensibility in mind. You would need to have intimiate knowledge

of the CLP(FD) to know where to add a new function. The usual
extension points are typically not documented, the CLP(FD) documentation
is not designed towards this goal.

Maybe there are some CLP(X) erround with better extensibility? A
CLP(X), when it sees an unknow evaluable predicate might fall back
to some default strategy? This doesn't work in SWI-Prolog anyway not,

since it is rather enemy of user defined evaluable predicates.

Advantage of Python is Strict by Default
=====================================
Could be much more friendly concerning extensibility of a constraint
programming language. Not 100% sure again. But Python has
classes and abstract classes. Sometimes multi-dispatch can

be annoying, and languages like the Julia programming language
might fare better. In Jekejeke Prolog I have my own take with
datatypes number, vector and matrice in the Gröbner library.

Hopefully I can bring part of it to the Dogelog Runtime. Lets learn
from the missed opportunities of Logtalk and the mistakes of CLP(Z),
and try something new in the future.

Stay Tuned!

Mostowski Collapse

unread,
Sep 27, 2021, 1:34:21 PM9/27/21
to
Hakan refers to this paper:

Increasing modeling language convenience - Tias Guns, 2019
https://github.com/CPMpy/cpmpy/blob/master/docs/modref19_cppy.pdf

Mostowski Collapse

unread,
Sep 28, 2021, 5:27:33 AM9/28/21
to
There is some problem with CLP(FD), that its rather random when it performs
well and when it doesn't perform well. Recently I benchmarked the
SEND+MORE=MONEY problem, and SWI-Prolog exceeds it:

/* SWI-Prolog 8.3.29 */
?- time(puzzle(X)).
% 7,170 inferences, 0.000 CPU in 0.000 seconds (?% CPU, Infinite Lips)
X = [9, 5, 6, 7, 1, 0, 8, 2] ;
% 1,974 inferences, 0.000 CPU in 0.000 seconds (?% CPU, Infinite Lips)
false.

/* Jekejeke Prolog 1.5.1 */
?- time(puzzle(X)).
% Up 136 ms, GC 4 ms, Threads 125 ms (Current 09/28/21 11:23:48)
X = [9, 5, 6, 7, 1, 0, 8, 2] ;
% Up 117 ms, GC 0 ms, Threads 109 ms (Current 09/28/21 11:23:49)
No

Then I benchmarked some Sudoku Problem, and the picture was totally
different. SWI-Prolog had really some problems, but Jekejeke Prolog
did it a little better. I got these results:

example(#(#(_, _, _, _, _, _, _, 1, _),
#(4, _, _, _, _, _, _, _, _),
#(_, 2, _, _, _, _, _, _, _),
#(_, _, _, _, 5, _, 4, _, 7),
#(_, _, 8, _, _, _, 3, _, _),
#(_, _, 1, _, 9, _, _, _, _),
#(3, _, _, 4, _, _, 2, _, _),
#(_, 5, _, 1, _, _, _, _, _),
#(_, _, _, 8, _, 6, _, _, _))).

/* SWI-Prolog, 8.3.29 */
?- time((example(X), sudoku(X))).
91,418,214 inferences, 4.688 CPU in 4.687 seconds (100% CPU, 19502552 Lips)
X = #(#(6, 9, 3, 7, 8, 4, 5, 1, 2),
#(4, 8, 7, 5, 1, 2, 9, 3, 6),
#(1, 2, 5, 9, 6, 3, 8, 7, 4),
#(9, 3, 2, 6, 5, 1, 4, 8, 7),
#(5, 6, 8, 2, 4, 7, 3, 9, 1),
#(7, 4, 1, 3, 9, 8, 6, 2, 5),
#(3, 1, 9, 4, 7, 5, 2, 6, 8),
#(8, 5, 6, 1, 2, 9, 7, 4, 3),
#(2, 7, 4, 8, 3, 6, 1, 5, 9)) ;
231,774,769 inferences, 13.250 CPU in 13.246 seconds (100% CPU, 17492435 Lips)

/* Jekejeke Prolog, 1.5.1 */
?- time((example(X), sudoku(X))).
% Up 2,418 ms, GC 24 ms, Threads 2,406 ms (Current 09/24/21 23:15:48)
X = #(#(6, 9, 3, 7, 8, 4, 5, 1, 2),
#(4, 8, 7, 5, 1, 2, 9, 3, 6),
#(1, 2, 5, 9, 6, 3, 8, 7, 4),
#(9, 3, 2, 6, 5, 1, 4, 8, 7),
#(5, 6, 8, 2, 4, 7, 3, 9, 1),
#(7, 4, 1, 3, 9, 8, 6, 2, 5),
#(3, 1, 9, 4, 7, 5, 2, 6, 8),
#(8, 5, 6, 1, 2, 9, 7, 4, 3),
#(2, 7, 4, 8, 3, 6, 1, 5, 9)) ;
% Up 710 ms, GC 7 ms, Threads 719 ms (Current 09/24/21 23:15:53)

Mostowski Collapse

unread,
Sep 28, 2021, 5:43:04 AM9/28/21
to
I got already results with some early versions of a Pythonesk Constraint
Solver, built inside a Prolog system. The are now prototypes for:

CLP(X), Constraint Programming from Hell

The idea is very easy. The ISO core standard predicate is/2 is
allowed to return a variable. So I have change Jekejeke Prolog 1.5.1
so that is/2 has the following behaviour:

?- X is Y.
X = Y

The rest is a matter of overloading (+)/3, etc.. and (=:=)/2, etc..
Means constraints will be available for (=:=)/2 by some simple
overloading. I got two versions:

Version 1: Only Overloads But Cannot Compute Intervals:
(The overloaded ISO core standard (=:=)/2 defers when it doesn't get numbers)

?- X in 2..5, Y is 2*X.
Y = 2*X,
freeze(X, X in 2..5)
X in 2..5, Y =:= 2*X.
freeze(X, X in 2..5),
freeze(Y, Y =:= 2*X)

Version 2: Overloads And Computes Intervals:
(Intervals get computed by is/2, but then erased in (=:=)/2)

?- X in 2..5, Y is 2*X.
Y = (2*X in 4..10),
freeze(X, X in 2..5)
?- X in 2..5, Y =:= 2*X.
freeze(X, X in 2..5),
freeze(Y, Y =:= 2*X)

Mostowski Collapse

unread,
Sep 28, 2021, 5:56:06 AM9/28/21
to
How do these versions perform? The solver I did doesn't wake up
on bound changes only on value changes. Here are some results.
The version 1 performance is rather depressing, on the other

hand the version 2 performance is encouraging:

/* CLP(X), Version 1 */
?- time(puzzle(X)).
% Up 92,759 ms, GC 868 ms, Threads 91,609 ms (Current 09/28/21 11:48:09)
X = [9, 5, 6, 7, 1, 0, 8, 2] ;
% Up 3,859 ms, GC 36 ms, Threads 3,844 ms (Current 09/28/21 11:48:20)
No

/* CLP(X), Version 2 */
?- time(puzzle(X)).
% Up 1,991 ms, GC 20 ms, Threads 1,906 ms (Current 09/28/21 11:49:17)
X = [9, 5, 6, 7, 1, 0, 8, 2] ;
% Up 130 ms, GC 2 ms, Threads 140 ms (Current 09/28/21 11:49:18)
No

One motivational aspect of CLP(X) is some ideas to bring
it to the Prolog system natively! There are the following ideas,
which could be implemented by Smalltalkish dispatch:

1) Return Variable, i.e. X is Y ~~> X = Y
We did already this modification for Jekejeke Prolog. The
modification should be also available for Dogelog Runtime.
Its just a matter of doing a different type switch.

2) Overloaded Arithmetic:
I am also expecting to do is more natively. Currently the arithmetic
does anyway check the type of its arguments. So instead of
throwing an error when the arguments are not numbers, the
Prolog system would natively divert into some other behaviour.

3) Overloaded Comparison:
I am also expecting to do is more natively. Currently the comparison
does anyway check the type of its arguments. So instead of
throwing an error when the arguments are not numbers, the
Prolog system would natively divert into some other behaviour.

Will massage the CLP(X) prototype a little bit and then upload it to gist.

Stay Tuned!

Mostowski Collapse

unread,
Sep 28, 2021, 8:07:25 AM9/28/21
to
By allowing operators such as (+)/3, etc.. and (<)/2, etc.. having
an extended meaning Python is probably in the same camp like C++.
So the convenience of Python is similar to the convenience of

C++, except in Python we don't need to mention some types
all the time. In as far a Pythonesk constraint programming
language embedding is more convenient than a C++ constraint

programming language embedding. The advantage over Java
is even greater, because one disadvantage of Java is that it
doesn't alllow overloading operators (+)/3, etc.. and (<)/2, etc..

Picat might show the same dark side like Java. Picat has
even abandoned the custom operators as found in Prolog,
but mostlikely it doesn't allow overloading the default operators

it does have? Right?

Mostowski Collapse

unread,
Sep 28, 2021, 8:13:31 AM9/28/21
to
The Pythonesk approach is also the death kiss to Picat on
another side. Picat invested into extending Prolog by things
such as the following:

assignment
if-then-else
while

It does so via a transformation which they call the canonical
form. But the above constructs are often used in a deterministic
fashion in a the model set up phase of a constraint programming

problem. It wouldn't make much sense to introduce non-determinism
in the model set up phase. Python can do the same easily since
it has all these constructs as an imperative language. And

the additional model += , populating the lazy container, only
increases clarity of the code. Through lexical scoping or the
context mechanism of Python, this can be possibly even more

short cuted. So what remains for Picat, the tabling? Well it possibly
will not take much for Python to learn the same as well. Possibly
there is memoization already around. Would need to check what

their proposal for non-determinisic rules is then?

Mostowski Collapse

unread,
Sep 28, 2021, 9:03:44 AM9/28/21
to
Ok, CLP(X), Constraint Programming from Hell is now on
the weebs. The SEND+MORE=MONEY example doesn't use any
(#=)/2 or (#\=)/2 anymore, just use the ordinary

(=:=)/2 and (=\=)/2 from ISO core standard:

puzzle(X) :-
X = [S,E,N,D,M,O,R,Y],
X ins 0..9,
all_different(X),
M =\= 0,
S =\= 0,
1000*S + 100*E + 10*N + D +
1000*M + 100*O + 10*R + E =:=
10000*M + 1000*O + 100*N + 10*E + Y,
label(X).

See also:

Preview: Pythonesk Finite Domain Solver in a Prolog System. (Jekejeke)
https://twitter.com/dogelogch/status/1442835365333716993

Preview: Pythonesk Finite Domain Solver in a Prolog System. (Jekejeke)
https://www.facebook.com/groups/dogelog

Mostowski Collapse

unread,
Sep 28, 2021, 12:42:16 PM9/28/21
to
My 2022 New Years Goals: Understand this tweet:

"goose typing" is a new term coined by Alex Martelli of
"duck typing" fame to describe virtual subclassing of
Python ABCs. See @fluentpython
https://twitter.com/ramalhoorg/status/560496888290754560

Or maybe buy the damned book...

Mostowski Collapse

unread,
Oct 28, 2021, 2:59:38 PM10/28/21
to
There are way too few Logtalk jokes! Any ideas?

QA engineer walks into a bar. Orders a beer. Orders 0 beers.
Orders 999999999 beers. Orders a lizard. Orders -1 beers.
Orders a sfdeljknesv.

Mostowski Collapse

unread,
Oct 28, 2021, 3:02:29 PM10/28/21
to
Ok, I got one, its even a new one:

Q: How many programmers does it take to kill a cockroach?
A: Two: one holds, the other installs a Logtalk pack on it.

Credits:

python pyjoke automatically write random programming jokes
https://www.youtube.com/watch?v=i4dufpV_YaM
0 new messages