R5RS meeting at Xerox PARC

[Aubrey Jaffer <jaffer@martigny.ai.mit.edu>]

   Date: Fri, 8 May 92 12:49:20 PDT
   From: rpg%inferno@lucid.com (Richard P. Gabriel)

   This proposal (?) seems to want to hide the details of the file system
   implementation, but it goes awry here and there. Presumably the idea
   is that you either deal with strings to name files, directories, and
   the like, or else you deal with vicinities. So far, so good. But
   SCHEME-FILE-SUFFIX appears to reveal the fact that most (all?) systems
   use suffixies or extensions to assign types (as used by language
   processors) to files.

SCHEME-FILE-SUFFIX was not part of the original vicinity system.  I
added it when Brian Hanson of Control Data Corporation
(brh@ahse.cdc.com) pointed out that "." is the directory separator
character on NOS/VE systems.

   Why go out of your way to reveal implementation details?

Other than making a poor choice of name, I don't think I have.  My
intent is that SCHEME-FILE-SUFFIX not be optional depending on whether
the system uses a file suffix; but that it be optional depending on
the use of the file.  It should be used in all cases where a Scheme
file is being accessed.  It should not be used in cases where a
non-Scheme file (like a copyright notice) is being accessed.  Systems
which do not have file suffixes should just have (SCHEME-FILE-SUFFIX)
return "".

   It would seem to me better for SCHEME-FILE-SUFFIX to be
   renamed SCHEME-FILE-TYPE-CONSTRUCTOR, and have it return a procedure
   which, when given a filename, returns a filename with the same `base
   name' but with type SCHEME. Then IN-VICINITY should take this optional
   procedure.

     (in-vicinity <vicinity> <filename>)			procedure
     (in-vicinity <vicinity> <filename> <type-constructor>)procedure

   or, better yet, eliminate the extra argument and let people write:

     (in-vicinity <vicinity> ((scheme-file-type-constructor) <filename>))

I would prefer if vicinity functions dealing with static paths (those
known at compile time like library-vicinity, implementation-vicinity,
and program-vicinity) were allowed (but not required) to be syntax so
that compilers could reliably integrate these calls.  This is the case
with the #include <???.h> and #include "???.h" syntax in C.  A version
of your idea above which would allow this is:

  (in-vicinity <vicinity> (scheme-file <filename>))

If it is the case that LOAD in all Scheme systems automatically checks
for the scheme file extension then SCHEME-FILE-SUFFIX would be
unneccessary.  Is this the case?  I think this would be a much better
solution because it would allow LOAD to similarly load compiled
versions if they exist.  Is this a possibility for R5RS?