Library proposal: Add System.Info.isWindows

John Meacham john at
Fri Aug 17 21:00:02 EDT 2007

On Wed, Aug 15, 2007 at 03:28:19PM +0100, Duncan Coutts wrote:
> We have not reached consensus on this issue yet.
> Based on informal chats with interested people, here is another concrete
> proposal:
> Instead of adding isWindows, isBeOS, isNixOS etc we have a simple
> enumeration of the major OS flavour:
> data OSFlavour = Linux | Windows | MacOS | BSD | Solaris | Other String

I really really dislike the 'Other String' thing, it is pretty much
always a sign of bad design. 

Why would some OS's be delegated to 'Other' status just because we
happened to not know about them at some point? will all code have to
become bloated by saying

case os of
        Linux -> doLinux
        Other s | s == "Linux" -> doLinux

or have to use CPP to figure out if other hardcoded values of OSFlavor
exist and must be checked for? 

the data type isn't "normalized" in some sense. there are multiple
representations of the same thing, and it arbitrary elevates a few
choices to special cases for no good reason.

ones that make sense would be either

> data OSFlavor = Linux | Windows | MacOS | BSD | Solaris
> -- returns OSFlavor if we know it.
> getOsFlavor :: Maybe OSFlavor 


> newtype OSFlavor = OSFlavor String

However, I don't think either is really needed (but wouldn't hurt)
because the practical question we want answered is not whether we are on
Solaris or Linux usually, but rather we are on a machine that supports
POSIX or if we are on a machine that supports the Win32 API. 

it is entirely possible to be both (cygwin under windows) for instance.

We really should not hard code anything like this in data types. if we
want a fast special purpose API (like what was originally proposed) then
'isWindows' is perfect. if we want a general way to query the system
type, then a String (perhaps wrapped in a newtype) is the way to go. the
halfway approach is the worst of both worlds and just complicates code

so, avoid the 'Other'! it will make your code faster, smaller, and more
clearly designed and understood.


John Meacham - ⑆⑆john⑈

More information about the Libraries mailing list