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.
Date: Fri, 8 Oct 1999 19:16:03 GMT From: oleg@xxxxxxxxx You said it very well. SRFI-10'th intent is indeed to extend the grammar for external representations; SRFI-10 indeed does not aim to specify all the details (where tag-symbols are stored, how they come into being, etc). SRFI-10 however resolves to provide #,() interpretation guidelines -- an interface so to speak. It appears that comparison with the Reader Algorithm of CL illustrates very well what the latter phrase means: [... quote elided ...] The quote above defines the interface of a reader macro function, and specifies what it can or cannot do. SRFI-10 aims to do the same with regards to reader-constructors. The above could be reduced to `yes, but no'. You agree with me that SRFI-10 is proposing a convention for future SRFI's, and then go on about `reader-constructors' and implementing some form of read-time evaluation. If what I said was correct there is no need to talk about implementation at all. Future SRFI's that contain concrete proposal for extensions can talk about implementations. You have nothing to implement. Consider the first of your implementation strategies: - offer a _fixed_ set of specific symbolic tags and associated constructor procedures; Every Scheme implementation already has this: it implements SRFI-10 with an empty set of symbolic tags. Suppose that SRFI-X is a new version of SRFI-4 (Homogeneous numeric vector datatypes) that follows SRFI-10's suggested protocol. Instead of SRFI-4's #u8(0 #e1e2 #xff) it has #,(u8 0 #e1e2 #xff) and so on. If Erewhon Scheme implements SRFI-X does it implement SRFI-10? It might or it might not. Does the user care? No, because the user cannot tell the difference. An SRFI can comply with SRFI-10; it is meaningless to ask if an implementation does. The bottom line is that SRFI-10 is not about implementations, it is about other SRFIs. This is fine, and even a good idea, but you need to make it much clearer. Drop all the stuff about read-time application and Common Lisp read macros. It just confuses the issue. -Richard Kelsey