[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wrapping procedures

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

  "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

  "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