Library proposal: Add System.Info.isWindows

[Duncan Coutts]

On Wed, 2007-08-15 at 18:05 +0100, Neil Mitchell wrote:
> Hi
> 
> > Yes, Eq, Ord, Show and Read.
> >
> > I'm not sure it's possible to make it an instance of Data or Typeable is
> > it? Doesn't that require a dependency on the generics package but
> > System.Info is in the base package.
> 
> This is going to keep coming up, if we move the Data and Typeable
> classes out...

That's what I keep saying. I must sound like a broken record.

> > Is everyone ok with the type name? OSFlavour, OSKind, OSType ? We can't
> > use OSName since it's not that specific.
> 
> OSFlavour - dislike, flavour pretty much means "it tastes like".
> Windows+Cygwin has flavours of both Windows and Unix. We want to say
> this is the OS you are using, its not just "a bit like" this one, but
> it really is, and it can only be one.
> 
> OSType - seems fine.
> 
> OSKind - again, has a slight "kind of like", and again Windows+Cygwin
> is kind of like multiple things.
> 
> OSName - the name of your operating system - this is the one I would
> have picked.

Only it isn't the name, it's a general categorisation. The os name might
be "Windows Vista(tm)" or "FreeBSD" but the os type is just Windows or
BSD.

> OS - nothing wrong with short names, especially when they are common
> abbreviations
> 
> OperatingSystem - but no point optimising for character's when people
> are doing something we don't want them to be doing :-)
> 
> I think in the end I'd pick OperatingSystem, as its very clear what it is.

I think I'd pick OSType as its very clear what it is. :-)

The other thing is what the variable is called. We can't take
System.Info.os since that already exists. If we pick OSType then it's
easy, we pick System.Info.ostype. If it's OperatingSystem what would you
pick?

If we were starting from scratch I might advocate os :: OS and osName ::
String, but we're not, we've already got os :: String.

Duncan