On Tue, 2006-11-07 at 21:10 +0000, Neil Mitchell wrote:
Hi
Well I guess that's just the issue. Cabal also isn't an existing dependency. It'd be pretty bad to make every library & program depend on Cabal. Perhaps it's just as bad to make it depend on Win32, but I think it's probably less bad. Or it could go in base or we could leave it as is as an FFI import.
The options:
* Depend on win32 - plenty of users won't have this installed (since its no longer bundled by default)
It's not? Ok, I'm a bit surprised.
* Depend on FFI - most WinHugs users won't have C installed
So WinHugs isn't going to support the FFI spec? It's not clear that you need a C compiler to support the FFI. Python and GHC can compile without a C compiler and still do FFI.
* Depend on Cabal - everyone with WinHugs or GHC will definitely have this installed.
* Depend on base - everyone everywhere will have this installed, but requires changing base and there is no equivalent function on Posix (otherwise this would be a useful general purpose function)
My vote goes in the direction of Cabal or base, since if its not one of those two I probably just won't bother using the Path functionality for Hoogle.
But you see that it means that every package built with Cabal must then depend on Cabal? ie it'd have to go in build-depends for every single package! This would be very bad. What's more, it would mean that people would not do it on unix and it'd work, but then fail on windows because only on windows would the Paths_<pkg> module need Cabal. Actually that also applies to using the Win32 package or any non-base package. It's not something that people would really like to put into base because it's not portable. There really is no equivalent to GetModuleFileName in Unix (indeed deliberately so because you can delete the binary while the program is still running). I don't see a good solution apart from the current FFI solution. Duncan