Draft PIP-0110-format

Prolog Improvements Forum - PIPS PIP-0110
1

Drafting and testing for PIP-0110 for format/2,3 threw up quite a number of inconsistencies between implementations. Here is a list of issues, together with my suggestion for how to resolve the issue in the PIP. Please comment if you have strong feelings…

Topic Alternatives Suggestion
Types to allow for the format string various all text-like types: chars, codes, atom (and string if applicable)
Allow expressions in ~d, ~e, etc? error/allow allow, because widely implemented
Accept floats in ~d/D/r/R? error/truncate/round error, because conversion ambiguity
Accept integers in ~e/E/f/g/G? error/allow allow, but do not specify whether handled by coercion or special treatment
Allow expression in ~c ? error/allow allow for consistency, although not widely implemented
Accept expressions in arguments for ~* error/allow allow, but only integer expressions
Specify ~W format (with two arguments) as interface to write_term/3 yes/no yes, although not yet widely supported
Support ~@ format? yes/no no, requires meta-argument and redirecting the output stream
Support layout formats ~| ~t and ~+ ? yes/no yes - only useful with monospace fonts, but widely implemented and used
Treatment of supernumerary arguments? error/ignore error
Treatment of numeric parameter in formats that do not support one, e.g. ~3a error/ignore ignore, to allow extensions without violating the PIP
Accept non-atoms in ~a error/accept error, to avoid ambiguities with [ ]
Accept non-code-lists in ~s error/accept accept codes, chars, atom (and string if applicable)
Treatment of illegal radix (such as 0, 1, 37) in ~r error/use default of 8 error
Interpretation of ~0n print nothing or 1 newline print nothing
Treatment of numeric parameter in ~N, e.g. ~3N error/ignore/interpret ignore, since interpretation unclear
Interpret numeric parameter as print depth in ~w ~q ~k (Paulo’s suggestion) yes/no no, meaningful only for ~w, not widely implemented, and expressible via ~W

Other discrepancies in implementations concern the error terms thrown, but I’m inclined to leave this unspecified in the PIP.

2 Likes
4

Any intention to support Unicode? Possible behaviours:

a) Because in UTF-16 the 𝄞 is two words 0xD834 0xDD1E
the column is filled with 6 spaces:

?- char_code(X, 0x1D11E), atom_concat(X,'~8|:',Y), format(Y, []), nl.
𝄞      :

b) If UTF-32 code points were counted, then it would be
filled with 7 spaces:

?- char_code(X, 0x1D11E), atom_concat(X,'~8|:',Y), format(Y, []), nl.
𝄞       :

This is only a heuristic, I have seen some chinese pictograms
still being two characters wide in a monospace font. So don’t know
yet how to measure to be format/[2,3] suitable. The same problem

might appear if a caret is used to indicate a syntax error location.

BTW: The test case can also extend to PIP-0105, for those Prolog
systems that bootstrap PIP-0110 from an extended write_term/[2,3].
Especially when format/[2,3] has a slight compositional interaction

with write_term/[2,3], when it comes to a stream state line_position/1:

?- char_code(X, 0x1D11E), write(X), format('~8|:', []), nl.
𝄞       :
X = 𝄞 .