Library proposal: Add System.Info.isWindows

[Duncan Coutts]

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

> >> data OSFlavour = Linux | Windows | MacOS | BSD | Solaris | Other String
> >
> > test like (osFlavour == Windows)
> > note some people may try to spell it as "osFlavor"
> 
> Which is a point against the name.

Agreed.

> > I don't like the way that enumeration scheme interacts with new OS's. 
> > What happens when/if Hurd or ReactOS or who-knows-what become viable 
> > OSes.  Are they different enough from the other OSes that they should go 
> > in Other or (breakingly for any code that tries to detect it) be added 
> > to the enumeration?  Seems to make an "isUnixLike" difficult to 
> > implement in terms of it... unless it's a feature test :)
> 
> Yes.  This is guaranteed to be incomplete, and Other tells me nothing
> useful.

Yes, as Issaac suggests perhaps we should drop the String parameter to
OtherOS since it tells you nothing useful.

Of course it's guaranteed to be incomplete but that doesn't make it
useless. In reality it takes time to port a Haskell implementation to a
completely new OS and the number of programs that might need to treat
that platform specially is likely to grow only slowly, so there's enough
time to get new enumeration values added.

> > None of the existing OSes get subtypes... what if "Other" is also 
> > standalone, not having a String argument (and whenever someone wants to 
> > detect some other OS, I guess they petition to have the enumeration 
> > expanded and it will be promptly) - how is that on the problem scale??
> 
> 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.

> 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, there are many many situations
where little distinctions are convenient.

> isWin32 :: Bool, isPosix :: Bool, hasDTrace::Bool, hasXlib::Bool are
> useful.

Sure, but what about things which are really just proxies for the
particular OS:

usesWindowsStyleProgramInstallationLayout :: Bool

> 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. As Neil said
in the first place, 90% of platform tests are actually:

case osType of
  Windows ->
  _       ->


So the model I'd advocate is to have a usable OS enumeration but look to
identify what the common distinctions that people use it for and add
specific feature tests for those common cases. We can accumulate more
feature tests as they prove to be useful, but for the ones that slip
through the gaps there's still a reasonably reliable fallback mechanism.

We should collect suggestions for the some common ones, that might help
this discussion. The obvious ones that have been suggested before
include file extensions for certain file types like executables, shared
libraries and object files.

Duncan