[cmucl-imp] DIRECTORY and symlinks

[Helmut Eller]

On Sun, Dec 02 2012, Faré wrote:

>>> No, but the assumption is that implementations will take steps to
>>> compute this truename, which might result in errors, and it is not
>>> portable to assume otherwise.
>>
>> That would be a strange assumption.
>>
> Yet, it's how things actually are today. Welcome to Common Lisp!
>
>> It's important that DIRECTORY can
>> be used to traverse directories.
>>
> It's important that it CANNOT, because that defeats the standard.

If that is true, then other implementations (e.g. SBCL, Allegro) defeat
the standard.  But I don't believe that it's true.

The standard does not specify what the relation of symlinks and
truenames is.  Since the meaning of truenames is implementation
dependent, CMUCL can choose whatever meaning is useful without defeating
the standard.  Therefore it can also choose not to signal errors when
DIRECTORY encounters symlinks.  It could also filter them out.  Anyway,
there is plenty of room for reasonable solutions.

> It's important that something ELSE can be used to traverse
> directories, and becomes a new de facto standard.

Well, the standard is the de facto standard.

>> But I can't call anything else to traverse directories besides
>> DIRECTORY.
>>
> What do you call to connect to a socket?
> What do you call to play a sound?
> What do you call to create a symlink?
>
> The CL standard does not cover everything. Get over it.
> Now work on stuff beyond the CL standard.

I want to list the files in my home directory.  That's about the most
mundane task DIRECTORY should be able to do.  If it can't be used for
that then it would be truly useless to have it in the standard.

>>>> Well, asdf-utils:directory* is full of #+.  That's the kind of code I
>>>> like to avoid.
>>>>
>>> The whole point is that it has the #+ for each and every of the 9
>>> active implementations plus 6 more, so you don't have to. (And yes
>>> there might be bugs or missing #+'es, but at least they only have to
>>> be fixed in one place.) Alternatively, there's IOLib.
>>
>> I shouldn't need to install third party libraries just to list the files
>> in a directory.
>>
> In the real world, the choice is between:
> 1- be not portable
> 2- use a bad portability layer
> 3- greenspun your own bad a portability layer
> 4- use and contribute to a good portability layer, one that is robust
> and comprehensive enough that it becomes the defacto standard and
> deserves to be included in a future formal standard (if any).
>
> I say 4.

5. ask my friendly CMUCL wizard to apply a reasonable interpretation of
the standard.

Helmut