Re: Library proposal: Add System.Info.isWindows

Hi A question for everyone: Excluding Cabal and GHC (which are where the platform specific dependency stuff should be painfully explicit) has anyone written a Haskell program which tests for a specific "feature" of the host platform, i.e. os == "mingw32" or other? For Win32 vs not Win32 I can list several: FilePath, lhs2tex, at least 5 or 6 I've flamed for the mingw32 bit... Has anyone ever actually tested for anything else? Thanks Neil On 8/17/07, Duncan Coutts wrote:

On Fri, 2007-08-17 at 00:55 +0000, Aaron Denney wrote:

...

On 2007-08-16, Duncan Coutts wrote:

...

On Wed, 2007-08-15 at 22:02 +0000, Aaron Denney wrote:

...

It looks like a problem to me. If nothing else, as it expands, old packages get nasty warnings about incomplete pattern matches on old systems, and still don't work on new systems, as the package doesn't know how to handle this case.

As Isaac says, you'd code these in a way where you pick out the exceptional cases and leave the rest for a default, so nothing should break if a new enum value is added.

In many places there is no such thing as an exceptional case. This is tell us about things that aren't standardized. Not knowing how to do something tells us we can't do this, and need to abort. A feature test is exactly what we want.

...

...

I don't care what exact operating system I'm running on, I care about features implemented, and APIs.

This could be coded poorly on top of this, or coded directly. The enumeration adds /no/ value.

I think that's taking things to a bit of an extreme. Yes, feature tests are to be preferred where they can be clearly specified but there is some overhead to adding feature tests,

And also overhead to adding Enumeration types. Changing exposed datatypes breaks versioning.

...

there are many many situations where little distinctions are convenient.

Then they should be feature tests, of coures.

And for little one-off feature tests, how should they be implemented in the absence of knowing the OS. Sure some can be specifically tested for, but some are not testable features exactly, they're just platform conventions...

...

...

usesWindowsStyleProgramInstallationLayout :: Bool

I think you mean: defaultPackageInstallationDirectory :: FilePath (which should be entirely overrideable, of course.)

But it's actually a good deal more complex that that, in that style it'd be:

defaultPackageInstallationDirectory :: IO FilePath defaultBindir, defaultLibdir, ... :: IO FilePath

in fact, I'm not sure it can be done in that style at all. Since on windows we're supposed to do relocatable installs and we're supposed to arrange to call the Win32 function to find the Program Files directory on the target machine and we have to generate source code to find the installation directory at runtime. This doesn't fit neatly into a generic test, any test would just be a proxy for isWindows.

Really, the simplest method in this situation is just to have different code for Windows vs non-Windows. Some generic test(s) gains us nothing here.

So given that such cases exist, lets allow people to do them slightly more reliably. Then in addition as we spot common patterns where generic feature tests would help we should try to standardise them.

...

...

...

Adding a new feature test doesn't break old packages that don't use that feature.

Nor should adding enum values, tests should have a default.

No, they shouldn't: defaults mean "oh, I haven't actually thought about this case. I'll assume it works like this." What happens when two OSes get added that treat something differently? An old package has no choice but to assume the same thing about both of them, and is guaranteed to be wrong about one, no matter how much foresight they have.

Having default cases or not doesn't make any difference, old programs can be broken on new OSs.

So yes, that is certainly the advantage of feature tests but as I've pointed out not all cases fit neatly into nice generic feature tests.

...

Special per-OS hacks are simple, but wrong. A system that tells you what features work (such as GNU autoconfigure (or even perl's)) are the right thing, though can certainly be implemented better.

I am not arguing against feature tests! Where they work they're definitely nicer and more maintainable (though slightly more work to set up in the first place). However they do not cover all cases. Sometimes even it's necessary to implement a feature test as just a mapping from OS (eg directory separator char or text file line ending). This doesn't help as much with the maintainability at least it helps to collect OS specific info into one place in a program which makes porting easier.

So I'm saying we need both.

Duncan

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries