[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
load versus Macintosh
Date: Thu, 21 May 92 18:11:28 -0700
From: William Clinger <email@example.com>
My point was that (load <filename>), where <filename> is a string, is
not completely compatible with the Macintosh file system because, on
the Macintosh, a program can access many distinct files that have
identical names. Yes, even identical full pathnames, because you can
have distinct disk volumes with identical names. On the Macintosh you
need a volume reference number or working directory number in addition
to the pathname, and that number is used to disambiguate. You can't
make that number part of the pathname because it is allocated dynamically
by the Macintosh file system. Hence there cannot be an implementation
of Scheme on the Macintosh that is fully compatible with both the R4RS
and with the Macintosh file system.
I agree that filenames should not be required to be strings. One
certainly doesn't want to be popping multiple dialog boxes in order to
load a large program consisting of several files. Vicinities, which I
proposed earlier, are an attempt to deal with these problems.
(in-vicinity <vicinity> <filename>) procedure
Returns a filename suitable for use by load, open-input-file,
open-output-file, etc. The returned filename is <filename> in
<vicinity>. For most systems in-vicinity is string-append.
IN-VICINTITY does not require pathnames to be strings.
And from R4RS:
(load filename) essential procedure
Filename should be a string naming an existing file ...
LOAD, call-with-input-file, and call-with-output-file are different
from open-input-file, open-output-file, and transcript-on in that the
filename SHOULD, as opposed to MUST, be a string. Vicinities are at
least compatible with LOAD, call-with-input-file, and
call-with-output-file in allowing other objects to describe pathnames.
I expect that this difference in wording is accidental. I would like
to see the requirement that filenames be strings be relaxed.