On Tue, Jun 9, 2026 at 2:37 PM Ulrich Neumerkel < ulrich@a4.complang.tuwien.ac.at> wrote:
about the treatment of closed streams.
Closed streams are still of the form a stream. Thus any attempt to use them any further will either lead to
- an existence error
?- open('/tmp/myfile',write,S),close(S), close(S). existence_error(stream, ...).
- failure, in case of a query about it
?- open('/tmp/myfile',write,S), close(S), current_input(S). false.
Thanks, that resolves it. To confirm I've understood: a closed handle is still a stream-term (the right kind of term), so the domain_error clause of 8.11.1.3 does not apply. Since current_input/1 is a query, it simply fails. I've checked that GNU Prolog works that way. SICStus, Trealla, or SWI does not.
Just to follow:
- current_input/1 lists only domain_error(stream, S) and no existence_error.
So SWI returning existence_error(stream, S) here raises an error the predicate's table does not allow.
- By your reasoning, SICStus's domain_error(stream, S) is equally non-conforming for a closed handle: domain_error is appropriate only when the term can never be a stream-term, which a closed handle can be. That is what some conformance suite currently (incorrectly?) encodes as the expected result, e.g. LogTalk:
https://github.com/LogtalkDotOrg/logtalk3/blob/36a64c4d24448813af25c48a1966c...
https://github.com/LogtalkDotOrg/logtalk3/blob/36a64c4d24448813af25c48a1966c...
- stream_property/2 only lists domain_error(stream, S), no existence_error.
I understand that stream_property/2 on a closed stream must also fail and not raise an existence error. Same suite's expectation for the closed-handle cases:
https://github.com/LogtalkDotOrg/logtalk3/blob/36a64c4d24448813af25c48a1966c...
https://github.com/LogtalkDotOrg/logtalk3/blob/36a64c4d24448813af25c48a1966c...
A domain error is only appropriate if the term can never be a
stream-term. This indeed depends on an implementation which has here some freedom see 7.10.2.1.
?- close(1+1). domain_error(stream_or_alias,1+1). % provided 1+1 is not chosen ...