[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wrapping procedures
| 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
Even if no other procedures are affected, the introduction of a new
type will often require changes to `equal?'.
"cring.scm" +, *, /, -, zero?
Because R5RS includes `dynamic-wind', this isn't a problem in
"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-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
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
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