get_char/1 panic

[flexoron]

v0.9.4-286-g00e6e323

$ scryer-prolog -f
?- get_char(A).
a
   A = a.
?- get_char(a).
a
   true.
?- get_char(End_of_file).
^D
   End_of_file = end_of_file.
?- get_char(end_of_file).
^D
thread 'main' panicked at src/machine/system_calls.rs:3469:50:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$

UWNs Findings:

even
?- get_char(end_of_file).
a
thread 'main' panicked at src/machine/system_calls.rs:3485:50:
called `Option::unwrap()` on a `None` value

in other words::
?- get_char(end_of_file).
   inputs("a"),
   false. % expected, but not found

However,
?- open('/dev/null',read,S),get_char(S,end_of_file).
   S = '$stream'(0x638d31165ea0).
?- open('/dev/null',read,S),get_char(S,end_of_file),close(S).
   S = '$dropped_value'.

Many thanks!

[flexoron]

v0.9.4-614-gaa3d8b8f

?- get_char(End_of_file).
^D  End_of_file = '\n'.
?-

Usuallay ^D means EOF, the newline comes from the dark?

[UWN]

Mnmnm. This alone could make sense at the top-level loop.

?- get_char(Ch).
   Ch = '\n'.
?- get_char(Ch). 
   Ch = ' '. % there was a space after the dot
?- get_char(Ch).%
   Ch = '%'. % yes, good
?- get_char(Ch),get_char(Ch2).
   Ch = '\n', Ch2 = '\n', unexpected. % This is definitely a problem
``

[flexoron]

?- get_char(Ch),get_char(Ch2).%
   Ch = '%', Ch2 = '\x16\'.      % expected, there was ^V^V after the %
?- get_char(Ch),get_char(Ch2).
^V^V
   Ch = '\x16\', Ch2 = '\x16\'.  % expected
?- get_char(Ch),get_char(Ch2).
error(syntax_error(unexpected_char),read_term/3:0).  ^V^V directly after the dot seems unwanted
?-

?- get_char(C).%
   C = '%'.
?- get_char(C).x

Question: Why % or Space are read but no x, for example.

[triska]

The lexer seems to think that .x can still be completed to a token, the query is not even posted. For example, we have:

?- write(hello),get_char(C).%
hello   C = '%'.
?- write(hello),get_char(C).x
waits

[UWN]

The lexer seems to think that .x can still be completed to a token, ...

.x are two tokens. The . and x which may be extended further since (6.4):

A token shall not be followed by characters such that concatenating the characters of the token with these characters forms a valid token ...

3.148 read-term: A term followed by an end token (see 6.2.2, 6.4.8).

end token (* 6.4.8 *)
   = end char (* 6.4.8 *) ;

end char (* 6.4.8 *) = "." ;

An end char shall be followed by a layout character or a %.

In other words, the end of a read-term still depends on the next character (which must be peek_ed).

This is a frequent source of misunderstanding, see s#270 and 271. Scryer is conforming here. The only thing that is odd is

?- get_char(Ch),get_char(Ch2).
   Ch = '\n', Ch2 = '\n', unexpected. % This is definitely a problem

Or more generally:

?- length(Cs,9),maplist(get_char,Cs).
   Cs = "\n\n\n\n\n\n\n\n\n", unexpected.

where I had to press one Return and nine times C-d. But this could be related to Rust itself.