Re: [spr8220] Modifying DIRECTORY

[smh@franz.com (Steve Haflich)]

[This matter has been assigned the tracking identifier "spr8220".
Please refer to it in any followup communication.  Also, be sure
to cc bugs@franz.com so that if I am unavailable someone else will
be able to respond.]

This is some followup on the allegro-cl discussion over the last few
days.

   From: berger@cs.uchicago.edu
   Date: Wed, 21 Apr 93 16:05:23 CDT

   The Allegro (4.1) CL version of the function DIRECTORY returns its
   list of pathnames in modification-date order (ala ls -c). I'm using
   code written elsewhere which uses this function, but assumes the
   pathnames are in alphabetical order.

Ummm, one thing everyone seems to have missed is that this isn't true.
It may happen some of the time on some platforms, but on others the
order is the order entries appear in the directory.  Perhaps you're
running under Mach?

   The Allegro Manual warns against
   messing with the package-lock system, but can anyone tell me what sort
   of disaster I might be courting by doing the following?

   (let ((oldirectory (symbol-function 'directory)))
     (excl:without-package-locks
      (defun DIRECTORY (&rest args)
	(sort
	 (apply oldirectory args)
	 #'string-lessp
	 :key #'file-namestring))
      )
     )

First, the order of the list returned by the DIRECTORY function is not
specified by the language standard, so any code depending on it is
broken in the sense of not being portable Common Lisp.

I don't know of anything your proposed advice will break, but what you
are doing is making a global modification to the function defuned on
the public symbol common-lisp:directory, and I agree with the opinion
of Kevin Gallagher that this is dangerous.  If no one else cares about
the returned order, that's fine, but if some other code depends on the
order of the returned list, you might break it.  Worse, if some other
implementor tries to do some similar (but not identical) kludge for
some other purpose, one or the other of you will lose.  For example,
you might want case-sensitive sorting, but other might want
case-insensitive.

I think the morale is first that the Garnet code is slightly broken in
depending on non-standard behavior of a standard function.  If you
can't bring yourself to modify its source locally, then it is
preferable to find some way to modify its behavior in a way that
doesn't affect other applications running in the lisp world.
Shadowing the symbol seen by the package seen by the Garnet code seems
the way to do this, if it is practical, as was suggested by both
Gallagher and Oliver Christ.

If it's not possible, then your advice isn't particularly dangerous,
but consider yourself warned.

On the notion of adding keyword arguments to the directory function,
there isn't any reason why it wouldn't be practical, but it hardly
solves the problem of portability unless X3J13 makes them mandatory
additions to the language.  X3J13's current philosophy is that further
features shouldn't be added to the language (at least for this round)
unless the features are both important and cannot easily be programmed
by the user (with acceptable efficiency, etc.).  Clearly sorting the
list returned by directory fails the second test.  It is just as easy
and more flexible for user code to wrap its own sort around the call
to directory.  This, IMO, is what the Garnet code should have done.