| From: Matthew Flatt <xxxxxx@cs.utah.edu>
 | 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.