Library proposal: Add System.Info.isWindows

[Duncan Coutts]

On Fri, 2007-08-17 at 00:55 +0000, Aaron Denney wrote:
> On 2007-08-16, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> 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