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