Library proposal: Add System.Info.isWindows

[Aaron Denney]

On 2007-08-16, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
> On Wed, 2007-08-15 at 22:02 +0000, Aaron Denney wrote:
>> 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.

In many places there is no such thing as an exceptional case.  This is
tell us about things that aren't standardized.  Not knowing how to do
something tells us we can't do this, and need to abort.
A feature test is exactly what we want.

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

And also overhead to adding Enumeration types.  Changing exposed
datatypes breaks versioning.

> there are many many situations where little distinctions are
> convenient.

Then they should be feature tests, of coures.

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

I think you mean:
defaultPackageInstallationDirectory :: FilePath
(which should be entirely overrideable, of course.)

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

No, they shouldn't: defaults mean "oh, I haven't actually thought about
this case.  I'll assume it works like this."  What happens when two OSes
get added that treat something differently?  An old package has no
choice but to assume the same thing about both of them, and is
guaranteed to be wrong about one, no matter how much foresight they
have.

> As Neil said
> in the first place, 90% of platform tests are actually:
>
> case osType of
>   Windows ->
>   _       ->

Yes, but that's really
case osType of
    Windows -> ...
    Unix -> ...

If you're on something _truly_ different, such as VMS, or FooBazOS3.7 it
/should fail/ instead of being treated as a Unix.  Conversely, if it can
work because it is just like a Unix in the features you need, it should
work.  We can get this by just looking at those features.

If it has implementation for generic unix, and windows, then
the proper test is
if isWindows then ... else
if isUnix then ... else
error "No suitable implementation because..."

Special per-OS hacks are simple, but wrong.  A system that tells you
what features work (such as GNU autoconfigure (or even perl's)) are the
right thing, though can certainly be implemented better.

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

That's a reasonable start.

One thing that has been brought up before is cygwin.  Should it
be considered a separate operating system?  Well, not really, but 
it has much different conventions than standard windows.  What we
really want is not the underlying OS, but the "operating environment".
What assumptions should the code make to work in the environment for
which it is intended?  This doesn't make much difference, except in
terms of naming.

-- 
Aaron Denney
-><-