Library proposal: Add System.Info.isWindows

[Aaron Denney]

On 2007-08-15, Isaac Dupree <isaacdupree at charter.net> wrote:
> 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
>
> test like (osFlavour == Windows)
> note some people may try to spell it as "osFlavor"

Which is a point against the name.

> MacOSX is completely different architecturally than the pre-X Mac OS 
> (the latter of which, practically no one tries to support anymore, but 
> at least _used to_ be worth mentioning in enumerations)

...

> 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.

> 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. 

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.

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

Adding a new feature test doesn't break old packages that don't use that
feature.

> Plain Solaris is rather different than Solaris spammed with GNU 
> utilities etc... in the Unix world, OS's are not always so clear - but 
> the core, kernel, stuff makes it clear as far as I'm aware of, and the 
> rest is where particular feature tests are used.

What libraries are available is a big thing.

> The common feature-set will likely be provided by haskell libraries
> anyway (in which case the libraries have to decide how to implement on
> each platform... okay)

When feasible, yes.  But if a system lacks SysV IPC, it's not going to

> It's a difficult question, taken generally.  In some cases a 
> haskell-program-user may even want to specify how to treat their 
> environment (cygwin comes to mind).  

Yeah.  

-- 
Aaron Denney
-><-