Prolog-standard June 2026

prolog-standard@software.imdea.org

5 participants
5 discussions

Status of Archive changed?
by Ulrich Neumerkel 11 Jun '26

11 Jun '26

The link to https://lists.software.imdea.org/hyperkitty/list/prolog-standard@software.i… now just shows the message: This mailing list is private. You must be subscribed to view the archives. this worked so far. Is this change intended?

2 2

current_input/1, stream_property/2, set_input/1 on a closed stream handle
by Jose F. Morales 09 Jun '26

09 Jun '26

Dear all, I ran into something I don't quite understand about the treatment of closed streams. Take a closed stream handle: open(f, write, W), close(W), open(f, read, S), close(S) then: set_input(S) stream_property(S, _) reports existence_error(stream,S) while the ISO standard expects that: current_input(S) reports domain_error(stream, S). On the implementation side, it feels natural to share stream checking code, which would lead to a more uniform existence_error(stream,S) error for the three predicates (like SWI Prolog does). Am I missing something? Thanks, -- Jose

3 8

char_conversion/2
by Jose F. Morales 09 Jun '26

09 Jun '26

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 -- Jose

2 4

max_integer flag on unbounded system
by Jose F. Morales 03 Jun '26

03 Jun '26

Hi Ulrich, Quick one about current_prolog_flag/2 when a standard flag is conditionally absent. On a system with bigints, flags max_integer and min_integer are not present. So what should ?- current_prolog_flag(max_integer, X). do there: fail, or raise domain_error(prolog_flag, max_integer)? At least Scryer (I've not checked other compliant systems) fails. Thanks, -- Jose

2 2

max_arity vs max_procedure_arity
by Jose F. Morales 03 Jun '26

03 Jun '26

Dear all, representation_error(max_arity) is defined relative to the max_arity flag. That's fine for predicates like functor/3 and (=..)/2, but it's also specified for predicate-indicator predicates like abolish/1 and current_predicate/1. The trouble is that some systems make compound-term arity unbounded (or quite large) while still limiting predicate arity. On SWI: ?- functor(H, foo, 2000). % ok ?- functor(H, foo, 2000), assertz(H). % representation_error(max_procedure_arity) SWI Prolog solves the issues by splitting max_arity from max_procedure_arity (the latter isn't ISO). Eclipse Prolog also has two different limits but error is underreported (ambiguous). Picat, although not a Prolog system, also has two different limits (probably rooted in B-Prolog). That is definitely a problem and most of the ISO tests suites I have available either fail here or ignore those cases. Some possible directions: a) force one limit for terms and predicates (simplest but not a solution) b) raise limit for predicate arity (but that can be a *significant* implementation effort with low ROI) c) use max_procedure_arity (and push for future standardization) d) keep reporting max_arity for both limits, use error context (not standard) to disambiguate which arity limit has been reached I lean towards (c) looking for a possible change in the standard, or (d) as a temporary solution. (b) is difficult because some limits are intrinsically hard to raise in some engines (every reasonable computer language has some kind of procedure argument limits). A fallback calling convention may help but the implementation cost is not trivial. What are your opinions? Thanks, -- Jose

2 8

2026

2025

2024

2023

2022

2021

2020

Prolog-standard June 2026