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: Wed, 13 Oct 1999 19:58:16 GMT From: oleg@xxxxxxxxx Let me try to restate your suggestions, to make sure I know what you were saying. ... SRFI-10 proposes another, formal and generic, way of extending external representations of scheme values, namely, via a #,(<symbol> <datum>*) form. A particular SRFI-X that introduces a new data type simply should pick up the appropriate <symbol> and decide upon <datum>-arguments. ... Am I right it representing your position? It's not *my* position, it's my guess as to *your* position. My suggestion dealt with new external representations in general, not just external representations of new data types. This would include an SRFI with your #,(pi) #,(epsilon) #,(Infinity) #,(NaN) for example. Furthermore, consider "variable constants", for example, #,(os-type). When the reader scans the code, it replaces #,(os-type) with a literal symbol, e.g., Solaris, HP-UX. ... Why not just use macros for this? As soon as you add a new level you get problems because later levels cannot talk to earlier ones. If the program cannot make use of the information before macro-expansion time there is no utility in providing it at read time. You're saying that SRFI-10 has nothing to implement. Yet it extends the syntax of Scheme, and thus requests that a Scheme reader at least recognize the #,() form. Currently it does not. It does not extend the syntax of Scheme. You say so yourself: When a non-SRFI-10 compliant reader comes across a #,(foo) form, it immediately throws an error. When a SRFI-10 compliant reader sees the same form and does not know what to make of the 'foo' tag, the reader reports generally a different kind of error. The Scheme reports say nothing about the behavior of programs that are grammatically incorrect, including whether an error is reported. All legal programs that use SRFI-10 are just as legal without it. SRFI-10 does not extend the syntax or change the language in any way. I guess you were saying that SRFI-10 was way overloaded. I am saying that I do not understand what SRFI-10 is proposing. It talks about read-time evaluation without providing a mechanism for doing read-time evaluation. Either remove the talk or add the mechanism. -Richard