Dear all,
According to O'Keefe [1,2], char_coversion/2 was a mistake.
Ciao Prolog does not implement char_conversion/2 at all. Support in other traditional systems is mixed (implemented for a small range 0-255, limited, or just drafted). More recent systems like Scryer or Trealla (if I am not wrong) seem to expose no implementation at all. There seems to be little incentive to implement a feature narrowly conceived, scarcely used, and dangerous in effect.
I would like to propose flagging char_conversion/2 as obsolescent (still conforming, but marked as removal in any future revision, with existing implementations explicitly free to retain it as an extension). The C language had a similar issue with trigraphs, which have been removed (C23), and Fortran maintains a formal obsolescent-features list; so there is ISO precedent for retiring features.
Cheers,
[1] https://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm [2] https://www.complang.tuwien.ac.at/ulrich/iso-prolog/pllib-2015-02-11.htm
According to O'Keefe [1,2], char_coversion/2 was a mistake.
For one, O'Keefe was not involved in the ISO process. Nevertheless, in preparation of Cor.2 his pllib-page got its own column [1].
He did, however, pioneer many language features much before actual standardization took place. In fact, his 1984 Draft Proposed Standard for Prolog Evaluable Predicates [2] not only included logically correct definitions for many built-ins like functor/3, but also proposed call/N for the first time.
As for char_conversion/2 and related features, these were meant for specific character sets, "for example" Japanese JIS. On CNC machines with barely any operating system present - except the Prolog which was the operating system. To my understanding, it is of less use for, say, code development in general.
For its current support by actual implementations, there is IF/Prolog, GNU and SICStus. Other implementations do some hearsay-ish implementation, if at all. Supporting it with a JIS PCS (Processor Character Set) does make sense, and definitely on those machines. In any case, the two built-ins, and the name of the Prolog flag all are taken "forever".
?- current_char_conversion(a,a). % 8.14.6 true, unexpected. % in SWI false. % 8.14.6.1 (2) which reads
and (2) `In_char` is not equal to `Out_char`.
[1] https://www.complang.tuwien.ac.at/ulrich/iso-prolog/built-in_predicates
[2] https://www.complang.tuwien.ac.at/ulrich/iso-prolog/#pllib
On Tue, Jun 9, 2026 at 3:13 PM Ulrich Neumerkel < ulrich@a4.complang.tuwien.ac.at> wrote:
According to O'Keefe [1,2], char_coversion/2 was a mistake.
For one, O'Keefe was not involved in the ISO process. Nevertheless, in preparation of Cor.2 his pllib-page got its own column [1].
He did, however, pioneer many language features much before actual standardization took place. In fact, his 1984 Draft Proposed Standard for Prolog Evaluable Predicates [2] not only included logically correct definitions for many built-ins like functor/3, but also proposed call/N for the first time.
As for char_conversion/2 and related features, these were meant for specific character sets, "for example" Japanese JIS. On CNC machines with barely any operating system present - except the Prolog which was the operating system. To my understanding, it is of less use for, say, code development in general.
For its current support by actual implementations, there is IF/Prolog, GNU and SICStus. Other implementations do some hearsay-ish implementation, if at all. Supporting it with a JIS PCS (Processor Character Set) does make sense, and definitely on those machines. In any case, the two built-ins, and the name of the Prolog flag all are taken "forever".
?- current_char_conversion(a,a). % 8.14.6 true, unexpected. % in SWI false. % 8.14.6.1 (2) which reads
My concern is less this one feature than what "forever" implies for the conformance criterion itself. ISO conformance is binary (a feature is required or it is not) so any conformance measure built on it must weight char_conversion/2, meant for 1980s JIS character sets, exactly as the features used in every program. A standard that can only add to its mandatory set and never retire from it has a conformance bar that necessarily drifts from practical relevance over time. Without proper documentation, users and implementors have no way to distinguish "missing something central" from "missing something vestigial".
Obsolescence is the mechanism that addresses precisely this. That is, not removing a feature anyone dislikes, but letting the criterion say "still provide it if you must, but it no longer counts against you". If I am not wrong, Fortran's obsolescent annex and C's future-directions clause serve this purpose. So my question behind "forever": is it a procedural fact about ISO Prolog that a core feature can never be marked obsolescent? If it is fixed for Prolog in a way it is not for those languages, I would like to understand whether that is specific to WG17's situation or to ISO standards generally.
and (2) `In_char` is not equal to `Out_char`.
[1] https://www.complang.tuwien.ac.at/ulrich/iso-prolog/built-in_predicates
[2] https://www.complang.tuwien.ac.at/ulrich/iso-prolog/#pllib
our considerations will be of relevance, when we are preparing a new version of the standard. And then, a lot of things might have changed. And we cannot predict them at all. Starting with ISO and JTC1 rules. Discussing these currently here will pretty much lead to nothing concrete. Also, comparisons to other working groups are pretty difficult, since we have stakeholders that have not adopted the standard in so many areas within 31 years. This is not the case in e.g. WG14.
For the moment, we have very concrete work to do that affect programmers in a much stronger way than to this one aspect you seem more interested in.
1st syntax-conformity
2nd built-in conformity
3rd the Prolog prologue
and much more.
In all of these areas it is absolutely vital to have concrete implementations that can be compared to each other and to the specifications rigorously. Just producing documents without concrete implementations isn't useful.
Understood. On the Ciao side, although we have no public release yet, we have been fixing more than 100 previously failing conformance tests. We'll be happy to notify you when it ships.
That effort is also the reason char_conversion/2 came up now: we reached it in the course of fixing those cases. Almost everything up to it we simply tried to correct against the standard; char_conversion/2 was the one we paused on rather than implement blindly, because its conforming behaviour for a Unicode reader was unclear to us, which is why I raised it here. This may be relevant now as well given the recent Unicode documents.
On deprecation, I agree. That is a next-version matter and we'll leave it parked until then.
On Tue, Jun 9, 2026 at 5:18 PM Ulrich Neumerkel < ulrich@a4.complang.tuwien.ac.at> wrote:
our considerations will be of relevance, when we are preparing a new version of the standard. And then, a lot of things might have changed. And we cannot predict them at all. Starting with ISO and JTC1 rules. Discussing these currently here will pretty much lead to nothing concrete. Also, comparisons to other working groups are pretty difficult, since we have stakeholders that have not adopted the standard in so many areas within 31 years. This is not the case in e.g. WG14.
For the moment, we have very concrete work to do that affect programmers in a much stronger way than to this one aspect you seem more interested in.
1st syntax-conformity
2nd built-in conformity
3rd the Prolog prologue
and much more.
In all of these areas it is absolutely vital to have concrete implementations that can be compared to each other and to the specifications rigorously. Just producing documents without concrete implementations isn't useful. _______________________________________________ Prolog-standard mailing list -- prolog-standard@software.imdea.org To unsubscribe send an email to prolog-standard-leave@software.imdea.org
prolog-standard@software.imdea.org
-
Jose F. Morales -
Ulrich Neumerkel