Appendix A defines various libraries - for example (scheme file).
What happens if a future scheme standard wants to add new
procedures (or macros) to this list?

For example one might want to add a move-file function.
This would logically belong in the (scheme file) library.
However, adding new procedures to a library may cause old
code to break.  So R8RS can create (scheme file-extended)
or (r8rs file) or something.  This is ugly and complicates
instructional materials.  (What should a Scheme tutorial use?)

My suggestion is to rename all of the (scheme XXX) libraries
to (r7rs XXX), but to add aliases for (scheme XXX).  The latter
is defined as an alias for (SPEC XXX) where SPEC is r7rs or
whether is the most recent Scheme specification supported by
an implementation.

Thus a program can use either:
   (import (scheme file))
or
   (import (r7rs file))
Programs that want to be careful with names and don't
want to risk clashes with future standards can use
the (r7rs file) form, while others can use the
(scheme file) form.  The latter makes sense for Scheme
tutorials.  It also makes sense for more casual programmers
who occasionally change the code and prefer not change
import statements and don't mind fixing an occasional name
clash.

Alternatively, rename all the (scheme XXX) libraries to
(r7rs XXX) libraries.  Just add (scheme all) as an alias
for all the names defined in the "current" specification.
I suspect most programmers would prefer this convenience,
rather than having to list (r7rs base) (r7rs write)
(r7rs char) and so on.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports