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

R5RS meeting at Xerox PARC

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. Why go out of your way to reveal implementation
details? 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

  (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>))