Rational number syntax can be extended to null, false and true?

General
1

Just notice I made a big mistake, or maybe not? I used the following
syntax for reference data type in Prolog:

reference :==  "0" "r" name .

Isn’t this in conflict to rational numbers syntax:

rational :== integer "r" integer .

Not really a rational number would have a digit after “r”, whereas
a reference data type wouldn’t have a digit after the “r”.
Now I can input output the beasts on JavaScript and Python,

and even sorting them now works:

?- sort([1,0rFalse,3.14,0rNone], L).
L = [3.14, 1, 0rNone, 0rFalse].

?- compound(0rTrue).
fail.

?- reference(0rTrue).
true.

Edit 16.03.2023
Will also bring them to Java. Although JPL proposes @(null),
@(false) and @(true)? But the advantage of the 0r syntax,
it gives a data type, which is not a compound.

Motivation to introduce these constants. JavaScript wanted
me a boolean attribute value for the attribute name “disabled”
on a DOM element. But I guess another application area

would be JSON parsing and unparsing.

2

When doing the “version 7 extensions” I proposed to introduce constants that are not atoms. A remain of that is the functor used for dicts:

?- functor(_{}, F, _).
F = C'dict'.

Now, while there is a write syntax, this constant cannot be read. The use case I had in mind where things like SQL NULL, JSON true/false, JavaScript undefined, etc. There was a lot of opposition against this idea and eventually it did not mature. The dict functor and the SWI-Prolog list constructor are some remains. Possibly there is renewed interest?

In part SWI-Prolog’s strings resolve this issue, using e.g., "true" and true for the string and the boolean. Downside is that, while it is typically ok to have read strings as a Prolog string, many strings in e.g. JSON are in fact values from an enumeration or other (controlled) vocabulary that you typically want as atoms.

4

As is, true, false, null and undefined are translated to the corresponding JavaScript value. Strings are always converted to strings and atoms other than the above are translated to strings. There is, if I recall correctly, the prefix operator syntax #Term that translates any term to a JavaScript string.

That works fairly well. The main nuisance is the other way around, where any JavaScript string becomes a Prolog string while in many cases you want an atom. Some null/undefined/true/false does not help for that. Well, it would allow using atoms for all JavaScript strings. That may also have disadvantages, surely if the target Prolog has no atom-GC.

6

How did you make this work? When I tried it, I got

?- sort([1,0rFalse,3.14,0rNone], L).
ERROR: Syntax error: Operator expected
ERROR: sort([1,
ERROR: ** here **
ERROR: 0rFalse,3.14,0rNone], L) .
8

Conceptually, that is a perfect match I guess. In practice the usage is quite different and I doubt that would make anyone happy :frowning:

10

Currently I get an error when I use string keys:

/* SWI-Prolog 9.1.4 */
?- current_prolog_flag(double_quotes, X).
X = string.

?- X = _{"abc": 123.46, "def": 67}.
ERROR: Syntax error: key_expected

Also there is the annoying need for an underscore functor.

With string keys I could directly embed JSON?
In this case null, false and true could be easily an atom.
Thats kind of solving the constant problem from another angle.

But this other angle would only work inside JSON.
There is still a problem with ordinary Prolog code, and
for example the disabled setter. If we want to avoid some

bottle neck of translating structures back and forth.