This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
| From: Matthew Flatt <mflatt@xxxxxxxxxxx> | Date: Fri, 2 Dec 2005 21:58:24 -0700 | | At Fri, 2 Dec 2005 14:43:25 -0500 (EST), Aubrey Jaffer wrote: | > Does SRFI-83 allow some way for a module to import, wrap, then | > export an identifier? | | Yes - renaming (either on import, export, or both) supports this | kind of wrapping. The only question is whether the exported name | can be imported elsewhere without further renaming. | | > Does SRFI-83 allow redefinition and export of R5RS procedures? | | Yes, as above. However, no SRFI-83 library would be able to import | the names without prefixing them or renaming, since every SRFI-83 | library imports "scheme://r6rs". There are four language extensions in SLIB which redefine builtin R4RS procedures: "array.scm" equal? Even if no other procedures are affected, the introduction of a new type will often require changes to `equal?'. "cring.scm" +, *, /, -, zero? "dynwind.scm" call-with-current-continuation Because R5RS includes `dynamic-wind', this isn't a problem in practice. "record.scm" vector?, vector-ref?, vector-set!, vector->list, vector-fill!, display, write If R6RS includes the record datatype, then this won't be an issue. I find five SRFIs which redefine builtin syntax: srfi-5 let srfi-17 set! srfi-46 syntax-rules srfi-61 cond srfi-71 let, let*, letrec | If we manage to at least agree on libraries that are all in the | "scheme://r6rs" (e.g., this SRFI), then we may eventually be able | to agree on ways to portably define new languages --- where a new | language could provide alternate bindings for names exported by | "scheme://r6rs". This SRFI, meanwhile, doesn't support it. | | I forgot the simpler possibility, which is that we define | additional pre-defined languages, including one that only binds | `import', `export', and `indirect-export'. This seems likely to | me. So module extension of the language would be disallowed; one must create a new language for each extension, whether its procedures can be made R6RS backward-compatible or not! That would mean that extended languages could not be combined without defining a combination language. I think that for practical purposes, R6RS would then have reserved identifiers; namely the builtin procedures and syntax. If that is the case, and given that "no reserved identifiers" motivated much of the macro system, this change should be explicitly stated.