Now there are some interesting news, we might soon
see SWI-Prolog performing the following feat:

?- A = ४२.
A = 42.

This works already for a while in Dogelog, although
it had a bug, which was only fixed yesterday.

You can try:
http://www.xlog.ch/izytab/moblet/docs/18_live/10_reference/example01/package.html

One could further extend it to Hex. Like for example:

?- A = 0xＢＡＢＥ.
A = 47806.

Works in Dogelog Player and formerly Jekejeke Prolog.
Again I only did it because Java can already do it.

Take this Java code:

int val = Integer.parseInt("ＢＡＢＥ", 16);
System.out.println("val="+val);

It gives me:

val=47806

Mostowski Collapse schrieb am Freitag, 24. Juni 2022 um 10:24:47 UTC+2:
> Now there are some interesting news, we might soon
> see SWI-Prolog performing the following feat:
>
> ?- A = ४२.
> A = 42.
>
> This works already for a while in Dogelog, although
> it had a bug, which was only fixed yesterday.
>
> You can try:
> http://www.xlog.ch/izytab/moblet/docs/18_live/10_reference/example01/package.html

I could also imagine that this feature is banned from
consulting Prolog texts or reading Prolog terms, and
only works for number_codes/2. But somehow there is

a conflict in the ISO Prolog core standard, number_codes/2
refers to the Prolog text syntax. In Java the feature is also
banned from Java texts. This here doesn’t compile:

int val = 0xＢＡＢＥ;
System.out.println("val="+val);

I get this Java compiler error:

java: illegal non-ASCII digit

So its only Integer.parseInt() thingy and not a Java texts
thingy. But I don’t see for number_codes/2 that the ISO
Prolog core standard would be aware of such a difference.

So at the moment its easier to make a solution that conflates
the two, Prolog texts and some built-ins like number_codes/2.

Mostowski Collapse schrieb am Freitag, 24. Juni 2022 um 10:32:13 UTC+2:
> One could further extend it to Hex. Like for example:
>
> ?- A = 0xＢＡＢＥ.
> A = 47806.
>
> Works in Dogelog Player and formerly Jekejeke Prolog.
> Again I only did it because Java can already do it.
>
> Take this Java code:
>
> int val = Integer.parseInt("ＢＡＢＥ", 16);
> System.out.println("val="+val);
>
> It gives me:
>
> val=47806
> Mostowski Collapse schrieb am Freitag, 24. Juni 2022 um 10:24:47 UTC+2:
> > Now there are some interesting news, we might soon
> > see SWI-Prolog performing the following feat:
> >
> > ?- A = ४२.
> > A = 42.
> >
> > This works already for a while in Dogelog, although
> > it had a bug, which was only fixed yesterday.
> >
> > You can try:
> > http://www.xlog.ch/izytab/moblet/docs/18_live/10_reference/example01/package.html

Now I am picking up new vibes for Dogelog Player, its still
a young Prolog system, and the streams are also still pretty
primitive. Maybe some new ideas might even spill back

to formerly Jekejeke Prolog. So whats on the todo list next?
I find that the following goodies concerning open/4 are missing,
its even the case that we even only have an open/3 so far:

- bom(Bool)
Specify detecting or writing a BOM.
- encoding(Atom)
Specify a file encoding.

BTW: This is an interesting read:

> Microsoft compilers and interpreters, and many pieces of software
> on Microsoft Windows such as Notepad treat the BOM as a required
> magic number rather than use heuristics. These tools add a BOM when
> saving text as UTF-8, and cannot interpret UTF-8 unless the BOM is
> present or the file contains only ASCII.
> https://en.wikipedia.org/wiki/Byte_order_mark#UTF-8

So you might find a BOM also for UTF-8 files, not only UTF-16 and other
encodings. The usual heuristic is to choose UTF-8 if there is no BOM, but
the above suggests to throw an error if there is no BOM

and some non-ASCII, i.e. > 7 bit.

Don’t know if any Prolog system throws such an error. One could
make the input stream aware that there was no BOM, and then bark
on a > 7 bit character coming from the stream. Could give more security.

Makes me currious to check what Java, JavaScript and Python do,
whether they have some reader object with such a feature. In the
worst case one could realize this feature in the Prolog systems

streams itself. Again bom(Bool) is not mentioned in the ISO Prolog
core standard, similar to encoding(Atom), but it has already some
support across Prolog systems. For example in formerly Jekejeke

Prolog I have the same, and SWI-Prolog has it as well. Not sure
what newer Prolog systems such as Scryer Prolog provide.
Need to check.

Mostowski Collapse schrieb am Samstag, 25. Juni 2022 um 11:22:01 UTC+2:
> Now I am picking up new vibes for Dogelog Player, its still
> a young Prolog system, and the streams are also still pretty
> primitive. Maybe some new ideas might even spill back
>
> to formerly Jekejeke Prolog. So whats on the todo list next?
> I find that the following goodies concerning open/4 are missing,
> its even the case that we even only have an open/3 so far:
>
> - bom(Bool)
> Specify detecting or writing a BOM.
> - encoding(Atom)
> Specify a file encoding.
>
> BTW: This is an interesting read:
>
> > Microsoft compilers and interpreters, and many pieces of software
> > on Microsoft Windows such as Notepad treat the BOM as a required
> > magic number rather than use heuristics. These tools add a BOM when
> > saving text as UTF-8, and cannot interpret UTF-8 unless the BOM is
> > present or the file contains only ASCII.
> > https://en.wikipedia.org/wiki/Byte_order_mark#UTF-8
>
> So you might find a BOM also for UTF-8 files, not only UTF-16 and other
> encodings. The usual heuristic is to choose UTF-8 if there is no BOM, but
> the above suggests to throw an error if there is no BOM
>
> and some non-ASCII, i.e. > 7 bit.