Sorry for hijacking this discussion.
Why are system names case sensitive at all? Wouldn't it be more sane to just make them case-insensitive?
It is more complicated to perform case-insensitive file search on a case-sensitive filesystem, of course.
On 25 Feb 2014, at 19:40, Faré wrote:
On Tue, Feb 25, 2014 at 1:19 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Faré wrote:
I recommend we just let the user choose between PATHNAME-EQUAL and PATHNAME-EQUALP, or some such.
The only question about this would be whether this is visible to the user or not?
I'd rather the user be in control.
Looking into ASDF we find the following calls to PATHNAME-EQUAL:
- BINARY-OP calls PATHNAME-EQUAL to see if it will inadvertently
overwrite the system .asd file
- Under ECL and MKCL, when building a bundle, we use pushnew with
PATHNAME-EQUAL; if this is wrong, and PATHNAME-EQUALP is right, then we could get duplicates in the bundle
- FIND-SYSTEM calls PATHNAME-EQUAL to see if the system definition
source file has been changed. A false positive here will cause unnecessary reloads.
- SAME-PACKAGE-SYSTEM-P uses PATHNAME-EQUAL to check and see if two
package-systems are the same.
I don't see how these problems can be resolved by punting to the user: the user doesn't have access to this level of control.
For FIND-SYSTEM and SAME-PACKAGE-SYSTEM-P, remember that these happen within the context of a same configuration. foo.asd will be searched for system "foo", and "Foo.asd" for system "Foo". To ASDF, these are different systems (NB: symbols are downcased), so it's OK for PATHNAME-EQUAL to distinguish them. Then, if the directories are case-sensitive unequal, but case-sensitive equal, that means that you found one file in the first one in configuration order, and the other file in the second one in configuration order, which is proof enough that they are different files. And if configuration changed and case with it, that's also a good reason to reload.
Remains the bundle issues. The first one is avoiding to overwrite a .asd file; the second is trying to avoid having the uiop library twice in the archive. Both would require quite some custom asdf methods to have the asd file (respectively uiop library) as output-files of some user system yet with a case-tweaked pathname. Yes, it's possible to do it wrong, but the user has to try hard for it, at which point I think it's OK to concede defeat.
While I agree that a heuristic for deciding whether pathnames are case-sensitive is not ideal, I don't see an alternative to supplying one.
I suspect that committing myself to a mental institution might be a sane alternative to trying to supply a heuristic for case-sensitivity of a filesystem without using CFFI.
But perhaps there's a different way out? At any rate, we'd have to figure out how to handle the above cases.
You're right of course that handling those cases right is important, but I believe they are already handled as right as can be. Trying to double-guess the user based on a flaky case-sensitive heuristic is only the recipe for debugging madness either for you or for the poor user who'll be double-guessed wrong.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you could ask a unique question to a computer during a Turing test, what would you ask? — Douglas Hofstadter, Metamagical Themas