This page is part of the web mail archives of SRFI 10 from before July 7th, 2015. The new archives for SRFI 10 contain all messages, not just those from before July 7th, 2015.
> Treating `#(' as `(' doesn't shift the burden of dealing with an > error, it hides the fact that there ever was one. How can the caller > deal with an error that it can no longer detect? Suppose an application reads an input data stream: 1.0 2.0 3.0 #,(pi) 4.0 Suppose a reader failed to make sense of the #,(pi) form, and per SRFI-10 suggestion, has read is as (pi). It appears likely that the application will detect this error as the application expects the read function return inexact numbers rather than lists. Furthermore, consider the following Scheme code: (let ((factor #,(pi))) (body)) Suppose again that the reader failed to understand #,(pi) and read it as a one-element list (pi). When this code runs, it likely runs into an error: unbound identifier pi or identifier pi not bound to a thunk. Of course a user could've defined pi to be a thunk, in which case the error is truly masked. The more I write about this the more I wonder why I have put that phrase about erroneous #,() forms in the first place. I really don't want to get into reading exceptions, syntax error reporting and all that. Although Scheme reports do not mandate signaling syntax errors, most of the implementations have some way of voicing their displeasure at an ill-formed input. This error reporting ability could be employed to deal with #,() errors as well. It is best therefore to remove the offending phrase from SRFI-10. I'll submit the modification request shortly. Thank you, Oleg