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