The documentation isn’t very accessible yet (although apropos/1 and help/1 give the up-to-date docs). This flag may change to
prefer_rationals as this is its ECLiPSe name. Only, in ECLiPSe is doesn’t affect the syntax as well because their
1_3 syntax is otherwise not valid Prolog. SWI-Prolog uses the underscore to allow for
1_000_000, which is also highly appreciated by some users. So, we have a problem
I haven’t really sorted out why. We had several discussions on this. Normally
'$' predicates are locked as non-debug predicates, but using
?- set_prolog_flag(access_level, system). re-enables debugging (with some tweaks that it starts debugging SWI-Prolog internals, so the experience is a little less human friendly). In fact this could all be relaxed. SWI-Prolog only uses
'$' predicates in
init.pl that is loaded into the module
system. Anyway, that is a side topic.
2016/07/12 is normally a totally valid Prolog term. The issue is whether we want to sacrifice this, allowing for
1/3 as most languages that support rationals use or do we want an awkward syntax for rationals? According to @ridgeworks we have the following prior art (last line by me).
P/Q : Common Lisp, Python (fractions), OWL, Guile, Wolfram
P//Q : Julia (also allows Q to be signed)
P/Qr : Ruby
P_Q : ECLiPSe
None of these work in SWI-Prolog. The
P/Qr solution could be made to work as
1/3R), which is invalid Prolog syntax, but notable Joachim objects, claiming it is too much stress on the tokenizer to demand that much look-ahead. I don’t like it for being ugly as well as hard to handle but could live with it if it was widely used. But, it is only Ruby and then we also need to make a variation. Joachim also suggested
P_/Q, which indeed breaks nothing, but hurts my eyes a bit :(.
So, I started to play with the idea to be brave and simply turn
1/3 into a rational. I’ve ran a lot of my Prolog programs through it and found only issues in some unit tests (e.g, using
A is 1/0 to test error handling but now
1/0 is an illegal number an load time rather than an evaluation error at run time). You found a more serious counter example. Is this a show-stopper? Or can/should we provide a work-around? Possible work-around are
- Not make the rational canonical, so the application can turn them loss-free back to a term in places where a term is expected.
- Provide an option in read_term/3, though that would basically turn rational syntax off for Logtalk.