On Wed, Nov 27, 2019 at 2:45 AM Zefram via Bug reports for GUILE, GNU's Ubiquitous Extension Language <
address@hidden> wrote:
It's fairly obvious
that it's a value that can't be returned by read-char, and therefore is
not itself a character, but that's quite a different matter.
On the contrary: the EOF object is not a character, but it *can* be returned by read-char . Indeed it *is* returned by read-char just in case read-char is called after the last character of its input port has been read. This makes it possible to distinguish between two cases: read-char returns a character if there are any in the input port, and the EOF object if there are none.
By the same token, read can return either a datum value or an EOF object. It returns a datum value if the remaining characters in its input port constitute at least one datum (what R6RS calls an "external representation") or the EOF object if no characters are available, and raises an exception if the available characters do not constitute a datum. An input port containing just "(", for example, will not return an EOF object; it will raise an exception.
The lack of
s-_expression_ representation actually comes from the entirely unobvious,
and undocumented in Guile, use of the EOF value with the read function.
It's true that section 6.18.2 of the Guile 2.2.x manual is rather terse and does not document this behavior. However, section 4.1 says that Guile is fully compliant with R5RS. This means that it incorporates by reference the R5RS specification, and in particular section 6.6.2, which restates at greater length the rules I have given above. The definition of read in R6RS defers to the definition of get-datum (both are in library section 8.2.9), which is yet another restatement of the same rules.
This poor design precludes RnRS specifying read syntax for any
EOF object.
Why do you believe it to be a poor design? It seems quite appropriate to me for the EOF object not to be a datum value, for the same reason that it should not be a character. You nowhere state what purpose such a read syntax would serve. Do you wish to be able to use read to input a list of EOF objects, for instance? What would you do with them?