bug#38398: non-obvious SCM_EOF_VAL rationale

[John Cowan <cowan@ccil.org>]

[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]

On Wed, Nov 27, 2019 at 2:45 AM Zefram via Bug reports for GUILE, GNU's
Ubiquitous Extension Language <bug-guile@gnu.org> 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?



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Pour moi, les villes du Silmarillion ont plus de realite que Babylone.
                --Christopher Tolkien, as interviewed by Le Monde

[-- Attachment #2: Type: text/html, Size: 3394 bytes --]