> This article was inspired by an exchange of messages between
> Dr. Clinger and Dr. Feeley about external representation of uniform
> vectors, which are proposed in SRFI-4. This post attempts to make a
> rather sweeping generalization of Dr. Clinger's suggestion. It
> proposes an extensible, new old way for external representation of
> Scheme values: read-time _application_.

As far as I am concerned your proposal has little to do with SRFI 4
per se.  I will respond to it here but maybe you should consider
submitting it as a separate SRFI.

Although I am favourable to an extensible reader I think that your
proposal is premature.  You propose to allow extending the reader by
evaluating a form such as:

        (define-reader-ctor 'vector vector)

which would allow reading "#`(vector 1 2 3)" as the vector #(1 2 3).
This assumes that there is only one "reader", which is not a very
modular approach (two modules may need to extend the reader in
different ways, perhaps even overloading a certain constructor name).
Better would be to have the ability to create readers and configure
them separately (basically the "readtable" idea from CommonLisp).  But
then, a problem this introduces is how to tell the "read" procedure
which readtable to use: should it be an extra parameter to "read",
some dynamically bound variable (e.g. (current-readtable)), some
configurable parameter on port objects?

Moreover the "write" procedure must also be told which readtable to
use so that a call to "read" with the same readtable will restore the
object written (i.e.  for write/read invariance).  This means that
just specifying a constructor is not enough, you also need to specify
some mechanism for writing objects which have no standard external
representation.  This could be done for example by specifying a
type-predicate and a "type-to-list" procedure to extract the fields of
the object, as long as the external representation is restricted to
the form #`(<constructor> <field1> <field2>...):

 (define-reader-syntax (current-readtable) 'vector vector vector? vector->list)

Extra information may also be needed for the pretty-printer to do a
good job (this is less of an issue if the syntax of the syntax
extensions uses a simple pattern, as in the previous example).

But perhaps this kind of reading/writing information should be
specified when a new datatype is defined.  I believe Chez Scheme uses
this approach (you can specify the name to be used when reading a
record, and a "print" method).  This means reader syntax extensions
are limited to records, but this is OK if the builtin datatypes
(including those that are builtin extensions to R5RS such as
f32vectors) have their own builtin syntax.

I hope this shows that there is a wide space of solutions and
certainly more thought on reader syntax extensions is required.

Marc