> 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