variable_names/1 and ordering

[burs...@gmail.com]

I don't think. The ordering is implememtation dependent.
If the variable has not two names, nothing changes. The
age doesn't determine some name, like for example _<age>.

The age only determines the ordering inside the given
names. There exists no such once/1 example. You hare
halucinating and confused about two different topics.

Ulrich Neumerl wrote:

burs...@gmail.com writes:
> A minor discrepancy between the two versions is:
>
> Jekejeke Prolog 1 (latest Version 1.0.9b, from then on discontinued):
> ?- A = Roger, write_term(foo(A+Roger,A+H),
> [variable_names(['A'=A,'Roger'=Roger,'_'=H])]), nl.
> foo(A+A,A+_)
>
> Jekejeke Prolog 2 (currently Version 1.2.6):
> ?- A = Roger, write_term(foo(A+Roger,A+H),
> [variable_names(['A'=A,'Roger'=Roger,'_'=H])]), nl.
> foo(Roger+Roger,Roger+_)
>
> Because of the new variable ordering.

Thanks. I should have run through all tests. Namely:

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/variable_names#21
http://www.complang.tuwien.ac.at/ulrich/iso-prolog/variable_names#22

So write_term/2 depends on the "age" of variables which is an unreliable,
implemenation dependent notion. Therefore, otherwise permitted
optimizations, like inlining of once/1 would change the
result of write_term/2 for *named* variables.

(It is conforming that unnamed variables will show some implementation
depended variable name. But this here is about named variables.)

Will update soon.

[burs...@gmail.com]

If the ordering is implementation dependent,
as your test case says here:

19 _Impdep

And if different compilation of once/1 changes
some features that go into this implementation
dependent ordering, well then this dependention

dependent ordering changes. If you do not want
this to happen, you need to define some ordering
and not make it implementation dependent.

But this is impossible. If the pre-history of
the call write_term/1 has a single unification
Z = X. And the implementation dependent ordering

is "intelligent", depending how this unficiation
is realized. Then this "intelligence" will change
the display if the unification changes. Thats what
we want by this "intelligent" ordering.

Here is a simple example:

Didn't Work with Jekejeke Prolog 1.0.9a, was less "intelligent",
the criteria was basically only input order of
the variable_names/1 list:

?- T=foo(X,Y,Z), X = Z, write_term(T,[quoted(true),
variable_names([
'Z'=Z,'Y'=Y,'X'=X])]), nl.
foo(Z,Y,Z)

?- T=foo(X,Y,Z), Z = X, write_term(T,[quoted(true),
variable_names([
'Z'=Z,'Y'=Y,'X'=X])]), nl.
foo(Z,Y,Z)

Works with Jekejeke Prolog 1.2.6, is more "intelligent",
classhes in the variable_names list are now resolved
by the deref count of each variable:

?- T=foo(X,Y,Z), X = Z, write_term(T,[quoted(true),
variable_names([
'Z'=Z,'Y'=Y,'X'=X])]), nl.
foo(Z,Y,Z)

?- T=foo(X,Y,Z), Z = X, write_term(T,[quoted(true),
variable_names([
'Z'=Z,'Y'=Y,'X'=X])]), nl.
foo(X,Y,X)

Thats a neat little heuristic, that makes very
nice display of Prolog terms. I needed to see
whats going on with attribute variables.

Enjoy!

[burs...@gmail.com]

The ordering is not yet perfect, maybe adoping
a display of attribute variables, like in ECLiPSe
Prolog, i.e. X{}, would be a better solution,

for the case I had where I delveloped the heurisitics.
So this is only one first heuristic, I had developed
once. The problem is that a unification which

is essentially only:

X = Y = Z

Can go many different ways:

X -> Y -> Z

X -> Y
^
|
Z

Etc..

Probably I will do an update of the heuristic
in the next days. I should decrement the count by
one, when the last deref was to an

attributed variable... could give even better results.

[burs...@gmail.com]

Concerning your _<age> confusion, you can test
both versions 1.0.9a and 1.2.6 side by side.

[burs...@gmail.com]

Concerning your _<age> confusion, you can test
both versions 1.0.9a and 1.2.6 side by side.

The 1.0.9b version uses this settings location:

C:\Users\Foo Bar\Jekejeke Prolog

And the 1.2.6 version uses this settings location:

C:\Users\Foo Bar\AppData\Roaming\Jekejeke Prolog

[burs...@gmail.com]

Here is a test case, where I would need a better ordering.
The ordering works fine, if all involved variables are
attributed variables.

So lets first load an attributed variable library:

Jekejeke Prolog 2, Runtime Library 1.2.6
(c) 1985-2018, XLOG Technologies GmbH, Switzerland

?- apropos(put_attr).
Indicator Module
put_attr/3 term/unify
Yes

?- use_module(library(term/unify)).
% 5 consults and 0 unloads in 42 ms.
Yes

?- [user].
foo:attr_unify_hook(_,_).

Yes

Now lets do the exactly same test case again, but
X and Z are now given attributed variables.

/* only attributed variables works also fine */

? - T=foo(X,Y,Z), put_attr(X,foo,bar), put_attr(Z,foo,bar),

X = Z, write_term(T,[quoted(true), variable_names([
'Z'=Z,'Y'=Y,'X'=X])]), nl.
foo(Z,Y,Z)

?- T=foo(X,Y,Z), put_attr(X,foo,bar), put_attr(Z,foo,bar),

Z = X, write_term(T,[quoted(true), variable_names([
'Z'=Z,'Y'=Y,'X'=X])]), nl.
foo(X,Y,X)

But here is a case where the result is not anymore
that smooth. The complicated situation is when attributed
variables and normal variables are mixed:

/* mixing attributed variables and
ordinary variables doesn't do the job anymore */

?- T=foo(X,Y,Z), put_attr(X,foo,bar), X = Z,

write_term(T,[quoted(true), variable_names([
'Z'=Z,'Y'=Y,'X'=X])]), nl.
foo(Z,Y,Z)

?- T=foo(X,Y,Z), put_attr(X,foo,bar), Z = X,

write_term(T,[quoted(true), variable_names([
'Z'=Z,'Y'=Y,'X'=X])]), nl.
foo(Z,Y,Z)

Am Samstag, 2. Juni 2018 15:40:07 UTC+2 schrieb burs...@gmail.com:

[burs...@gmail.com]

Intuitively in the mixed case, I would expect as
a result even foo(X,Y,X) and foo(X,Y,X) given the
way attributed variables work. But the distance
metric is off by one. Will try a fix.

[Ulrich Neumerkel]

burs...@gmail.com writes:
>I don't think. The ordering is implememtation dependent.
>If the variable has not two names, nothing changes.

Agreed!

> The age doesn't determine some name, like for example _<age>.

Indeed, but in this example, there are no _-variables anyway.

>The age only determines the ordering inside the given
>names. There exists no such once/1 example. You hare
>halucinating and confused about two different topics.

So, lets consider:

r :-
p1, p2.

p1 :-
X = Y,
write_term(X+Y,[variable_names(['X'=X,'Y'=Y])]), nl.

p2 :-
Y = X,
X = Y,
write_term(X+Y,[variable_names(['X'=X,'Y'=Y])]), nl.

Running r I get
Y+Y
X+X

why the diff'rence?

[Ulrich Neumerkel]

burs...@gmail.com writes:
>If the ordering is implementation dependent,
>as your test case says here:
>
>19 _Impdep

It seems you are referring to:

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/variable_names#19

In this case, the precise variable name has to start with _, but
thereafter, the precise name is implementation dependent.

This has absolutely nothing to do with the ordering as it is
used when there are two entries for the "same" variable.

For all implementations except Jekejeke, the situation is clear:
The leftmost entry in the list is used. And thus, the age of
variables and such can have no influence whatsoever.

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/WDCor3#variable_names

In this respect, Jekejeke 0.9.9 was perfectly conforming while
1.2.6 produces implementation dependent results.

[burs...@gmail.com]

You don't need the second X=Y in p2, it wont
do anything. Ever read a paper about Unification?

===============================================
And you are confused, variables from different
clauses don't communicate.
===============================================

But read here, Jan Burse wrote:
> And the implementation dependent ordering
> is "intelligent", depending how this unficiation
> is realized.

And yes the result is, which is logically 100% correct:

?- [user].

r :-
p1, p2.
p1 :-
X = Y,
write_term(X+Y,[variable_names(['X'=X,'Y'=Y])]), nl.
p2 :-
Y = X,
write_term(X+Y,[variable_names(['X'=X,'Y'=Y])]), nl.

?- r.
Y+Y
X+X

[burs...@gmail.com]

Ulrich Neumerkel:

> In this respect, Jekejeke 0.9.9 was perfectly
> conforming while 1.2.6 produces implementation
> dependent results.

Yes, thats what I am telling already for days. I also
wrote, when I gave you the test cases, the
following:

> The expectations in the test cases, expected outcomes,
> are not the same as in your list. So a reference ISO 65,
> only means that I borrowed the test case, but not the
>
> https://github.com/jburse/jekejeke-samples/blob/master/jekdev/compfreq/system/connect.p#L38
>
> expected outcome. Where your outcome and my outcome
> differ, you can view it as **disagreement**, or
> **implementation defined** or **implememtation specific**
> or **whatever**.

https://groups.google.com/d/msg/comp.lang.prolog/U0Qcxi5LUmA/CS3ICjmnAAAJ

Since you have specified "If more than one element applies,
the leftmost is used.", one could emulate my behaviour
in applying a sorting routine.

Or I could remove my sorting, and provide it as an extra
routine, outside of the write_term/1. But doing the sorting
and detecting the duplicate variables is much

easier to do in one pass, than in two passes. What doesn't
make any sense in my opinion is this note:

NOTE 2 — Many Prolog processors modified write option numbervars/1 to print arbitrary variable names. The write option variable_names/1 serves this purpose and avoids vulnerabilities.

How do you avoid vulnerabitie, when for example A = 'x+y'
is allowed? Doesn't make any sense.

[burs...@gmail.com]

The problem is that if you provide an outside sorting,
you could from the beginning provide a mapping that
hasn't the following features:

- Without A1 = V and A2 = V for a variable V,
so the outside sorting could already
make it unique

- Without A = T where T is not a variable,
so the outside sorting could already
remove non variable entries.

The ISO core standard variable_names/1 is a little schizophrenic,
why allow a large variable names list, if you do not
want to allow some intelligence by the Prolog interpreter?

Doesn't make any sense at all...

[burs...@gmail.com]

A further problem is, that outside sorting.
How will you do it? Ever tried to do deref
counting in pure Prolog? Good luck,
this is impossible.

So you must have a write_term/1 option that
can implement this sorting lower level, because
you cannot implement it in Prolog itself.
Only a lower level routine can do it.

The write_term/1 option is a small elegant
route to allow this little piece of "intelligence"
that you cannot implement by a outside sorting,
which would be implement in pure Prolog,

or in Prolog using meta predicates like var/1
etc.. Its simply impossible in Prolog to
provide a variable age or a variable deref
count? Ever thought about that?

So far you didn't give an argument why
variable_names/1 should be intelligent, and
I also don't see any means to implement it in
the ISO core standard with how you define

variable_names/1. Which makes your variable_names/1
useless. Of what use is it, if you cannot make a

strict-mode pure Prolog code that would do this sorting?

but you have in strict-mode a stupide variable_names/1?
So you cannot make it any intelligent?

[burs...@gmail.com]

Your X+X example can be fixed, you can implement
a left most sorting routine in pure Prolog this
is possible, since it doesn't need a deref count.

Its very easy in fact, so you can also use
Jekejeke 1.2.6 for that. I will probably
remove Jekejeke 1.0.9a from my website.

?- [user].
r :-
p1, p2.
p1 :-
X = Y,

remove_dups(['X'=X,'Y'=Y], L),
write_term(X+Y,L), nl.

p2 :-
Y = X,

remove_dups(['X'=X,'Y'=Y], L),
write_term(X+Y,L), nl.

remove_dups(_,_) :- ... you can do it ...

[burs...@gmail.com]

Here is one way to define remove_dups/2:

:- use_module(library(experiment/maps)).

build_unique_map([], M, M).
build_unique_map([_=V|L], M, N) :-
get(M, V, _), !,
build_unique_map(L, M, N).
build_unique_map([A=V|L], M, N) :-
put(M, V, A, H),
build_unique_map(L, H, N).

map_to_assoc([], []).
map_to_assoc([V-A|L], [A=V|R]) :-
map_to_assoc(L, R).

remove_dups(L, R) :-
build_unique_map(L, [], H),
map_to_assoc(H, R).

It uses this library:
https://github.com/jburse/jekejeke-devel/blob/master/jekrun/headless/jekpro/frequent/experiment/maps.p

When you use this code:

r :-
p1, p2.
p1 :-
X = Y,
remove_dups(['X'=X,'Y'=Y], L),

write_term(X+Y,[variable_names(L)]), nl.

p2 :-
Y = X,
remove_dups(['X'=X,'Y'=Y], L),

write_term(X+Y,[variable_names(L)]), nl.

You get this result:

?- r.
X+X
X+X
Yes

But I don't see that an intelligent

priorize_dups(_,_) :- ... not possible to implement in pure
Prolog or Prolog with the usual metas
like var/1, ==/2, ...

How would you do a priorize_dups/2? You can do this
only natively meanigfully. I have tried to provide
something in Prolog, a datatype for that. You could
pass around the compound A=V.

The "intelligent" sorting is based on the trick,
that it looks at the compounds A=V, and can from there
do a deref. It doesn't work if you make the compounds
later somewhere. So it relies on the compounds it

gets from the read_term/1, or in your example at
compile time from the clause. And can thus do a
deref count. Its not really an "age" of a variable.
Its solely based on deref counting inside the

compounds A=V, when you go from _=V to V. When
you inpack V from the paring constructor (=)/2.
So its very simple to implement, but also non-logical,
even non-meta-logical. You can practically not

implement it meanigfull with logic or meta-logic.
Its just a quick hack, which I needed, because once
I wanted a more inelligent variable display. Since
I am planning a new call_reside_vars/2 for

Jekejeke Prolog 3, it will anyway all change again...

[burs...@gmail.com]

Hi Ulrich,

Rest assured, there is no problem with allowing
the Prolog processor to make a variable name choice.
This is anyway an option that is mostly needed

in the top-level. You can of course also use it
to list clauses in listing/[0,1] and friends. But
so far I havent seen a problem over the last years.

If you see a problem, please document it.

I also did some checks today about term expansion.
Term expansion hardly does A=B, and if it does, it
doesn't impact the result in any significant way.

If you see a problem, please document it.

I made this test just right now. I don't see any
problems whatever. Works on my side, I am using
variable_names/1 in my listing/[0,1]:

Jekejeke Prolog 2, Runtime Library 1.2.6
(c) 1985-2018, XLOG Technologies GmbH, Switzerland

?- [user].
q --> [X,X].

Yes
?- listing.
% user

q([X,X|A], A).
Yes

Unfortunately variable name listing/[0,1] works not
yet completely for SWI-Prolog. They announced something,
but it does not yet work in their top-level.

Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.15)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.

?- [user].
|: q --> [X,X].
|:
% user://1 compiled 0.00 sec, 1 clauses
true.

?- listing(q/2).
q([A, A|B], B).

true.

The reason is SWI-Prolog has variable_names/1, but
they do not yet use it anywhere. You can check their
code. I checked it last year, it wasnt used anywhere.

But you can test SWI-Prolog, a Prolog system which so
far has ignored all your variable_names/1 efforts in
listing/[0,1] itself, this way:

 Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.15)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.

?- T=(q-->[X,X]), write_term(T,[variable_names(['X'=X])]), nl.
q-->[X,X]

?- T1=(q-->[X,X]), expand_term(T1,T),
write_term(T, [variable_names(['X'=X])]), nl.
q([X,X|_1166],_1166):-true

And again works also on my side. I demonstrated already
through listing/[0,1], but just in case you don't believe me:

Jekejeke Prolog 2, Runtime Library 1.2.6
(c) 1985-2018, XLOG Technologies GmbH, Switzerland

?- T=(q-->[X,X]),
write_term(T,[variable_names(['X'=X])]), nl.
q-->[X,X]

?- T1=(q-->[X,X]), expand_term(T1,T), write_term(T,
[variable_names(['X'=X])]), nl.
q([X,X|_D],_D):-true

Am Samstag, 2. Juni 2018 16:19:46 UTC+2 schrieb Ulrich Neumerkel:

[burs...@gmail.com]

Well the more appropriate test case for SWI-Prolog,
whether it uses variable_names/1 in the top-level
or not, would be this one:

Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.15)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.

?- [user].
q --> [X,X].

?- listing(p/2, [source(true)]).
% From database (decompiled)
p([A, A|B], B).

true.

You see, it doesn't keep some variable names in
the database. Although this would be very cheap.
You can store variable names for static clauses,

when consulted, by one extra pointer, and for dynamic
clauses, when there was an assertz etc.., you simply
don't store any variable names. Not a big deal.

I don't know how they do the source(true) thing,
when there is a source. But I guess that in case
there is no source, they have no variable_names/1

feature for clauses. You can also make it switchable,
with a on off switch somewhere, like compilers that
do or do not place source information in a compiled

result, in case you want less memory usage. I had
this switch for the runtime. Variable names were
switched off for the runtime in the past. But now

its switched on for the runtime. A Prolog flag is
not yet defined for that. Its only an internal flag
somewhere. A Prolog flag could be defined in the future.

Last remark. My PrologReader/PrologWriter are open
source for a few days. I also made the "intelligent"
variable names open source. Its relatively simple:

public static int derefCount
https://github.com/jburse/jekejeke-devel/blob/master/jekrun/headless/jekpro/model/pretty/NamedDistance.java#L100

public static void addPriorized
https://github.com/jburse/jekejeke-devel/blob/master/jekrun/headless/jekpro/model/pretty/NamedDistance.java#L120

Thats all that is used during building the print map.

If you see a problem, please document it.

[j4n bur53]

See my other posts about listing/1 and using variable
names. And that some usage is still lacking in SWI-Prolog.

BTW: O-Prolog has a lot of potential:

O-Prolog Ver0.90
| p(X,X).
| :- listing.
p(X,X).

On the other hand where there is a lot of light, there
is also a lot of shadow. This is not Ok:

O-Prolog Ver0.90
| :- assertz(q([X,X|L],L)).
| :- listing.
q([[],[]],[]).

Pitty O-Prolog doesn't have GitHub or some such, to easily
raise issues. So I made some screenshots for my gist:

"variable_names/1 can be very helpful for listing/[0,1]. It seems
only a few Prolog systems use it so far correctly."
https://gist.github.com/jburse/baa1a055a1e2fb28f4defa539b787d1c#gistcomment-2608268

burs...@gmail.com schrieb:

[j4n bur53]

Hi Ulrich,

I just notice, if you want really to test archived versions,
maybe I should make more versions than only 1.0.9b available.
In 1.0.9b [user] consult was broken. But the old versions
didn't have variable names in clause listing.

At least I get for this old historical version:

Jekejeke Prolog, Runtime Library 1.0.1
(c) 1985-2014, XLOG Technologies GmbH, Switzerland
?- [user].
p --> [X,X].

Yes
?- listing.
p([A,A|B], B).

Yes

The new versions do have this feature. It came with version 1.0.4.
Namely in version 1.0.4 I see for the first time. Obviously
I was working on the listing/[0,1] predicates, there is also a
% user comment now:

Jekejeke Prolog, Runtime Library 1.0.4
(c) 1985-2014, XLOG Technologies GmbH, Switzerland
?- [user].
p --> [X,X].

Yes
?- listing.
% user

p([X,X|A], A).

Yes

The easiest for you Ulrich, would just use the newest version,
like version 1.2.6, as you also do for ECLiPSe Prolog, there you
test also version 7.0.x. Don't bother with

dead Prolog systems. Thats good for academic archeology. But
if you want to pursue academic archeology, you can also ask me.
I have all old versions here, and can quickly answer questions

for you, or if you want I can send you a ZIP with all versions
from past to present (only interpreter.jar). Just drop me
an E-mail if you would like that...


j4n bur53 schrieb:

[j4n bur53]

Or I put a archeologist ZIP on my web site, for noisy
people like Ulrich. Possibly an academic sport, who invented
what first. Ha Ha. Interesting perspective...

We got no time for that:

Ain't Nobody Got Time for That! - Sweet Brown
https://www.youtube.com/watch?v=zGxwbhkDjZM

j4n bur53 schrieb:

[burs...@gmail.com]

You guess it, what comes next? Testing Tau Prolog.
But I guess its too early. I get right now:

?- listing.
uncaught exception: error(existence_error(procedure, listing/0), top_level/0)

Or a Web based Prolog, which has some Prolog text
in some notebooks, will decide to never have a listing/[0,1]
predicate? listing/[0,1] can also show asserted facts, etc..

how the folklore solution is implement. But indeed
we don't find it in the ISO core standard. The
builtin-in listing/[0,1] is not reguired by

the ISO core standard. There is only:

8.8 Clause retrieval and information ....................... 77
8.8.1 clause/2 ................................... 77
8.8.2 current-predicate/l ............................ 78

And you cannot bootstrap it from the two. Since
clause/2 doesn't give you variable names. Also
current_predicate/1 might not help you finding

private predicates, that a Prolog system might
nevertheless list, although they are not exported
to the top-level. It could be that you are debugging

your own code, and your own code might use privates.

[burs...@gmail.com]

Looks like variable names in listing is a far east thing. Or a thing
found in far east Prolog systems. I gave it a try for K-Prolog. Looks nice!

I downloaded the Prolog system from here:
http://www.kprolog.com/archives/

K-Prolog Compiler version 5.1.5 (C) KLS Research, Inc.

1: ?- [user].
p(X,X).
^Z
user 88636 words free.

yes
2: ?- listing.
p(X,X).


yes
3: ?- assertz(q([X,X|L],L)).

X = X,
L = L

4: ?- listing.
p(X,X).

q([A,A|B],B).


yes
5: ?-

For pictures see here:
https://gist.github.com/jburse/baa1a055a1e2fb28f4defa539b787d1c#gistcomment-2608297

[burs...@gmail.com]

K-Prolog can do the nasty cut, but it has a funny
way of listing clauses. It does pretty printing,

between2(L,H,X) :-
((L=H ->! ; true)),
X=L.
between2(L,H,X) :-
Y is L+1,
between2(Y,H,X).

But the above has slightly too many parenthesis.
The title of the Prolog system says compiler. But

it could be that user input is only interpreted.
it beats me in the follow small test:

10: ?- statistics, (between(1,100,_), search([1,2,3,4,5,6,7,8,9],[],_), fail; true), statistics.

Heap free 87998
Local free 44892
Global free 143040
Atom 30278
Cpu time 182355
Heap GC 0
Stack GC 0

Heap free 87998
Local free 44878
Global free 143026
Atom 30278
Cpu time 185687
Heap GC 0
Stack GC 0

So it does 100-times full 9-queens in 3'332 ms,
I did it in 3'594 ms. But it seems that it
doesn't have bignums:

13: ?- X is 2<<100.

X = 32 ;

[Mostowski Collapse]

After so many years, I am ISO core standard compatible
concerning the variable_names/1 write option. Until now
it slipped my attention that the standard Corrigendum 3

is relatively precise. It says:

7.10.4 Write-options list
"variable_names(VN_list) — Each variable V is output as the
sequence of characters defined by the syntax for the atom A
iff a term A = V is an element of the list VN_list. If more than
one element applies, the **leftmost** is used. VN_list is a list
of terms A = T with A an atom and T any term, possibly a variable."
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/WDCor3

So a test case that will be satisifed by the upcoming
release 1.5.0 is this one:

?- A = Roger, write_term(foo(A+Roger,A+H),
[variable_names(['A'=A,'Roger'=Roger,'_'=H])]), nl.
foo(A+A,A+_)

I check these Prolog systems SWI-Prolog, SICStus Prolog,
GNU Prolog, they also behave the same. The following
Prolog systems didn't have a variable_names/1 write

option: XSB, YAP, Ciao, TauProlog. But for some of these
Prolog system where the option is missing, I am not sure
whether have the fetched the newest version.