This page is part of the web mail archives of SRFI 4 from before July 7th, 2015. The new archives for SRFI 4 contain all messages, not just those from before July 7th, 2015.
> 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