[cmucl-imp] DIRECTORY and symlinks

[Faré]

On Sat, Dec 1, 2012 at 7:23 PM, Helmut Eller <heller at common-lisp.net> wrote:
>> 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.
>
In my experience, "reasonable" doesn't sound well in a sentence
involving CL pathnames, all the less where portability is intended.

>> 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.
>
It is also immutable and only covering a tiny subset of interesting APIs.
Instead of trying to change it then convince 15 implementations to
change and piss off their user base used to the current situation,
what about developing a new API that makes sense from day one and
doesn't require backwards incompatibility or fighting with stubborn
maintainers?

> 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.
>
It is useless indeed. Welcome to the realization that not all of the
CL standard is useful.

The question is how to fix it. You're saying: "let's fight the system
for a tiny gain",
I'm saying "let's build something else that has a consistent API
without having to fight anyone".

>> 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.
>
That's still not portable, until you get all 9 actively maintained
implementations to agree on the *same* reasonable interpretation of
the standard (not talking about the 6 semi-surviving legacy
implementations).

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Every program has at least one bug and can be shortened by at least one
instruction — from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.