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.
> If I see > #,(f32 1.0 2.0 3.0) > in a program all I know is that the value will be the result returned > by applying some arbitrary function to `(1.0 2.0 3.0). This doesn't > tell me very much about what the program means. Still, as you said you do know that #,(f32 1.0 2.0 3.0) stands for a value produced by a constructor that is associated with a tag f32. It is this understanding that is the major thrust of SRFI-10. To learn what the tag f32 actually means and what kind of value the constructor produces, one has to consult a third-party registry. The situation is very similar to SRFI-0: <blockquote cite="SRFI-0#Rationale"> Features are identified by feature identifiers. In order for the semantics of this construct to be well-defined, the feature identifier must of course refer to a feature which has a well-defined meaning. There is thus a need for a registry, independent of this SRFI, to keep track of the formal specification associated with each valid feature-identifier. The SRFI registry is used for this purpose. It is expected that features will eventually be assigned meaningful names (aliases) by the SRFI editors to make reading and writing code less tedious than when using "srfi-N" feature identifiers. </blockquote> For instance, consider an Example from SRFI-0: (cond-expand (command-line (define (program-name) (car (argv))))) Notation (argv) tells us that argv is bound to a procedure or a syntax rule. What exactly it returns (in particular, whether the program name is the part of the result, and whether this name is the absolute path to an executable) is unknown. One has to locate and consult the corresponding SRFI. Now consider (cond-expand ((and srfi-4 srfi-10 srfi-10-4) (define sample-vector '#,(f32 1.0 2.0 3.0)))) The situation is the same: one has to consult SRFIs to figure out the meaning of the expression. Finally, let's compare #,(f32 1.0 2.0 3.0) with #f32(1.0 2.0 3.0) as per SRFI-4. Without any further information, both expressions are obscure. However, if SRFI-10 is in effect, the first expression can be "parsed" as a read-time application. The second expression cannot be parsed at all without reading a specific SRFI. Suppose somebody will introduce a new kind of a uniform vector -- of signed 128-bit integers. Without SRFI-10, he probably has to specify an external representation of these vectors as #s128(1 2 3), thus asking a conformant system to extend its reader to handle yet another hashsign-xxx notation. With SRFI-10, one can introduce external forms #,(s128 1 2 3) or even #,(s128vector 1 2 3). One does not need to extend the reader or fight for the remaining letters that may be specified after the hashsign. I will add a clarification about define-reader-ctor being merely a recommendation. Thank you for the suggestion. I will wait a couple of days to batch the updates, so to speak.