So the SWI-Prolog master wrote:
I wouldn’t call it an “ancient status”.
Its ancient status because its not Unicode
ready. It says, it doesn’t account for the
new universal atom and strings in SWI-Prolog.
Historical note: Unversal strings marked the
transition from Python 2.x to Python 3.x.
- we might be able to use the current locale
to include the appropriate code page.
(Does that really make sense?)
https://www.swi-prolog.org/pldoc/doc_for?object=is_text_code/1
But anyway I have retracted my swi2.pl.log
from GitHub and blocked Jan. W. for the first
time in my life. I really have lost all hope
concerning SWI-Prolog and given up
once and for ever...
Mild Shock schrieb:
Using again my super powered library(portray_text):
?- set_prolog_flag(double_quotes, codes).
true.
?- set_prolog_flag(back_quotes, chars).
true.
?- set_portray_text(enabled, true).
true.
?- maplist(char_code, `abc`, X).
X = "abc".
?- maplist(char_code, X, "abc").
X = `abc`.
So if you have a Prolog system that has chars, you
could bootstrap as follows:
atom_codes(X, Y) :-
var(X), !,
atom_chars(Z, Y),
maplist(char_code, X, Z).
atom_codes(X, Y) :-
atom_chars(X, Z),
maplist(char_code, Z, Y).
Or if you have a Prolog system that has codes, you
could bootstrap as follows:
atom_chars(X, Y) :-
var(X), !,
atom_codes(Z, Y),
maplist(char_code, Z, X).
atom_chars(X, Y) :-
atom_codes(X, Z),
maplist(char_code, Y, Z).
Mild Shock schrieb:
Full source code here:
swi2.pl.log
https://github.com/SWI-Prolog/swipl-devel/issues/1373#issuecomment-2997214639
Since it has a dual use hook, works fine simultaneously:
?- set_portray_text(enabled, false).
true.
?- X = [a,b,c].
X = [a, b, c].
?- X = [0'a,0'b,0'c].
X = [97, 98, 99].
And then:
?- set_prolog_flag(double_quotes, codes).
true.
?- set_prolog_flag(back_quotes, chars).
true.
?- set_portray_text(enabled, true).
true.
?- X = [a,b,c].
X = `abc`.
?- X = [0'a,0'b,0'c].
X = "abc".
Mild Shock schrieb:
Hi,
Even the SWI-Prolog master not wide awake,
doing day-sleeping.
I don’t know whether they realised that you
cannot meaningfully support both in the same
system and surely not in the same application.
Maybe you didn’t notice this nifty detail.
Thats all you need:
The ISO core standard is silent about a flag back_quotes
Its more a naming problem. Have two libraries
library(portray_codes) and library(portray_chars),
Or one library(portray_text).
Just add one more rule:
user:portray(Chars) :-
portray_text_option(enabled, true),
'$skip_list'(Length, Chars, _Tail),
portray_text_option(min_length, MinLen),
Length >= MinLen,
mostly_chars(Chars, 0.9),
portray_text_option(ellipsis, IfLonger),
quote2(C),
put_code(C),
maplist(char_code, Chars, Codes),
( Length > IfLonger
-> First is IfLonger - 5,
Skip is Length - 5,
skip_first(Skip, Codes, Rest),
put_n_codes(First, Codes, C),
format('...', [])
; Rest = Codes
),
put_var_codes(Rest, C),
put_code(C).
The use of maplist/3 is elegant, and works since we do
not print open lists, right?
Mild Shock schrieb:
Hi,
The most radical approach is Novacore from
Dogelog Player. It consists of the following
major incisions in the ISO core standard:
- We do not forbid chars, like for example
using lists of the form [a,b,c], we also
provide char_code/2 predicate bidirectionally.
- We do not provide and _chars built-in
predicates also there is nothing _strings. The
Prolog system is clever enough to not put
every atom it sees in an atom table. There
is only a predicate table.
- Some host languages have garbage collection that
deduplicates Strings. For example some Java
versions have an options to do that. But we
do not have any efforts to deduplicate atoms,
which are simply plain strings.
- Some languages have constant pools. For example
the Java byte code format includes a constant
pool in every class header. We do not do that
during transpilation , but we could of course.
But it begs the question, why only deduplicate
strings and not other constant expressions as well?
- We are totally happy that we have only codes,
there are chances that the host languages use
tagged pointers to represent them. So they
are represented similar to the tagged pointers
in SWI-Prolog which works for small integers.
- But the tagged pointer argument is moot,
since atom length=1 entities can be also
represented as tagged pointers, and some
programming languages do that. Dogelog Player
would use such tagged pointers without
poluting the atom table.
- What else?
Bye
Mild Shock schrieb:
Technically SWI-Prolog doesn't prefer codes.
Library `library(pure_input)` might prefer codes.
But this is again an issue of improving the
library by some non existent SWI-Prolog community.
The ISO core standard is silent about a flag
back_quotes, but has a lot of API requirements
that support both codes and chars, for example it
requires atom_codes/2 and atom_chars/2.
Implementation wise there can be an issue,
like one might decide to implement the atoms
of length=1 more efficiently, since with Unicode
there is now an explosion.
Not sure whether Trealla Prolog and Scryer
Prolog thought about this problem, that the
atom table gets quite large. Whereas codes don't
eat the atom table. Maybe they forbit predicates
that have an atom of length=1 head:
h(X) :-
write('Hello '), write(X), write('!'), nl.
Does this still work?
Mild Shock schrieb:
Concerning library(portray_text) which is in limbo:
Libraries are (often) written for either
and thus the libraries make the choice.
But who writes these libraries? The SWI Prolog
community. And who doesn’t improve these libraries,
instead floods the web with workaround tips?
The SWI Prolog community.
Conclusion the SWI-Prolog community has itself
trapped in an ancient status quo, creating an island.
Cannot improve its own tooling, is not willing
to support code from else where that uses chars.
Same with the missed AI Boom.
(*) Code from elsewhere is dangerous, People
might use other Prolog systems than only SWI-Prolog,
like for exampe Trealla Prolog and Scryer Prolog.
(**) Keeping the status quo is comfy. No need to
think in terms of programm code. Its like biology
teachers versus pathology staff, biology teachers
do not everyday see opened corpses.
Mild Shock schrieb:
Inductive logic programming at 30
https://arxiv.org/abs/2102.10556
The paper contains not a single reference to autoencoders!
Still they show this example:
Fig. 1 ILP systems struggle with structured examples that
exhibit observational noise. All three examples clearly
spell the word "ILP", with some alterations: 3 noisy pixels,
shifted and elongated letters. If we would be to learn a
program that simply draws "ILP" in the middle of the picture,
without noisy pixels and elongated letters, that would
be a correct program.
I guess ILP is 30 years behind the AI boom. An early autoencoder >>>>>>> turned into transformer was already reported here (*):
SERIAL ORDER, Michael I. Jordan - May 1986
https://cseweb.ucsd.edu/~gary/PAPER-SUGGESTIONS/Jordan-TR-8604-OCRed.pdf
Well ILP might have its merits, maybe we should not ask
for a marriage of LLM and Prolog, but Autoencoders and ILP.
But its tricky, I am still trying to decode the da Vinci code of >>>>>>>
things like stacked tensors, are they related to k-literal clauses? >>>>>>> The paper I referenced is found in this excellent video:
The Making of ChatGPT (35 Year History)
https://www.youtube.com/watch?v=OFS90-FX6pg
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)