load versus Macintosh

[William Clinger <will@skinner.cs.uoregon.edu>]

Jinx:
    The point was made (I believe by Will Clinger) that to be completely
    consistent with the Macintosh philosophy, LOAD would have to accept no
    arguments, and then it would pop up a dialog box for the user to
    specify the file to load.

Freeman:
      So why is this a reason to do away with LOAD?  I did a Scheme for the
  Macintosh in which (load <filename>) loads the file, (load) pops up a
  dialog box to specify the file, and Command-L...also pops up the dialog box....

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.

So what does MacScheme do?  MacScheme is compatible with the R4RS but
not with the Macintosh file system:  If you try to use multiple disks
with identical names, then you lose.  It sounds as though Freeman's
implementation must have the same bug.

As in Freeman's system, there is a way to work around this bug in
MacScheme, but that doesn't change the fact that the R4RS semantics
for load is incompatible with the Macintosh file system.  This isn't
very important in practice, because most people have sense enough
to give their disks distinct names, but I occasionally run across
this bug myself because I have a lot of floppy disks named "temp"
that I use to carry files between Macintoshes.

William Clinger