Hello,

On Mon, Dec 17, 2012 at 2:05 PM, Andreas Rottmann <a.rottmann@gmx.at> wrote:

> I think this is my assumption that you seem to disagree on: by using the
> binding of `read' from `(rnrs io simple)', instead of the one provided
> by Guile's core, the writer of the code using that binding has declared
> that he wishes `read' to adhere to R6RS.


I actually disagree with this assumption too, but let me explain why. I
think there are some situations where it is right and some where it is
wrong.

A program will want strict R6RS semantics (as Rotty says) if it is, for
instance, reading from a data file in a strictly-defined format. In that
case, it might have written its parser assuming an R6RS-compliant `read'
function, and it could fail if it gets an extended `read'.

However, the R6RS reader would be wrong for a program that wants to, say,
read a file of Scheme code as S-expressions and manipulate it. The program
would have to be written using R6RS libraries to be portable, but the right
thing for it to do in any particular Scheme implementation is to read
exactly the same syntax as that implementation. (This is a bit of a
contrived example, but I hope you can see my point that some programs don't
want strict R6RS semantics as much as they want to integrate with whatever
extensions their host implementation has made to `read', and that what they
really want is a portable way to access the built-in `read'.)

If you believe both of these examples, then programs need to be able to
choose their own meaning. Perhaps the solution is a procedure like
`strict-r6rs-read-options' for programs that want that, or alternatively
`native-read-options' for programs that don't.

Regards,
Noah