Re: DIRECTORY and symlinks
Faré <[email protected]> Sat, 1 Dec 2012 18:17:58 -0500
| Newsgroups | gmane.lisp.cmucl.devel |
|---|---|
| Message-ID | <CAN7nBXeYRU2Lutob79o6op+Fx5WC7ZZK+Qbu6=aiPs7BvM+dCg@mail.gmail.com> |
>> 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.
It's important that something ELSE can be used to traverse directories,
and becomes a new 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.
>>> 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.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
"Reality is that which, when you stop believing in it, doesn't go away".
— Philip K. Dick
_______________________________________________
cmucl-imp mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-imp