On Mon, Feb 23, 2009 at 12:15 PM, William D Clinger <[email protected]> wrote: > Sam TH wrote: >> The IEEE Scheme standard does not include macros, which is precisely >> what makes the example I presented difficult. How would you propose >> to change section 5 to accomodate macros? > > The obvious way is with a one-pass algorithm that assumes > any reference to an as-yet-undefined identifier is a > reference to some identifier that will later be defined > as a value (not a macro).
I believe that this would cause the `define-inline' example to produce an error, just as it does in current implementation of REPLs for interacting with R6RS programs, such as Larceny's ERR5RS mode. >> Additionally, the IEEE standard supports the REPL at the cost of >> making the following program "an error" > > As I explained in my earlier response to Mike Sperber, > that explicit ambiguity resulted from compromise, just > as many similar ambiguities in the R6RS resulted from > similar compromises. As a technical matter, removing > that ambiguity would be absolutely trivial. Would this be accomplished by making the suggestion of section 5.2.1 a requirement, and thus making this a portable program: (set! this-id-does-not-exist 42) ? >> Would a single pass algorithm have resulting in the program I gave >> being portably exception-raising? Or would it simply be non-portable? > > Both of your examples would be flat-out portable if the > semantics of R5RS section 7.2 were adopted along with > the macro semantics sketched above. I'm confused. The semantics of R5RS section 7.2 (the non-normative denotational semantics) does not specify the behavior of macros, and the "macro semantics" I believe you were referring to (from the top of the message I'm replying to) make my `define-inline' example produce an error. Are you referring to a different "macro semantics" that I missed? There have been lots of emails, I certainly might have missed one. > If you prefer, however, you could also design a semantics > in which one or both of your examples is non-portable, or > you could design a semantics in which one or both portably > raises an exception. > > Designing a non-portable or exception-raising semantics > would be more difficult than just adopting the flat-out > portable semantics based on R5RS 7.2. > > To repair the R6RS, I would suggest using the semantics > of R5RS 7.2 only for top-level programs. REPLs could > then have exactly the same syntax and semantics as > top-level programs. That would not make the semantics > any less consistent, because the syntax and semantics of > R6RS top-level programs already differ from the syntax > and semantics of R6RS libraries. Again, the semantics of R5RS Section 7.2 does not mention macros, so we'd have to come up with some fix for that, perhaps along the lines of what you've suggested above. However, the semantics you suggested above are not the same as the semantics that R6RS assigns to top-level programs, in which the `define-inline' example I provided displays the expected string. In summary, I'm very confused by what you have written. Is your suggestion that (a) It would be easy to specify a semantics for a REPL in which my `define-inline' example would work at the REPL and in R6RS-style top-level programs, (b) It would be easy to specify a semantics for a REPL in which my `define-inline' example would not work, and my example would work in an R6RS-style top-level program, but the REPL would otherwise behave like an R6RS top-level program, (c) It would be easy to specify a semantics for a REPL in which my `define-inline' example would not work, and to change the semantics of R6RS-style top-level programs so it wouldn't work there either, or (d) Something else entirely. > That is not to say that R6RS programs are less portable > overall than R5RS programs. Standardization of lexical > syntax, particular libraries, and arithmetic improved > portability relative to the R5RS, and those things matter > more in practice than the kinds of things you are talking > about. I certainly agree with that. -- sam th [email protected] _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
