Library proposal: Add System.Info.isWindows

[Neil Mitchell]

Hi

A question for everyone: Excluding Cabal and GHC (which are where the
platform specific dependency stuff should be painfully explicit) has
anyone written a Haskell program which tests for a specific "feature"
of the host platform, i.e. os == "mingw32" or other?

For Win32 vs not Win32 I can list several: FilePath, lhs2tex, at least
5 or 6 I've flamed for the mingw32 bit...

Has anyone ever actually tested for anything else?

Thanks

Neil



On 8/17/07, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
> On Fri, 2007-08-17 at 00:55 +0000, Aaron Denney wrote:
> > 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.
>
> And for little one-off feature tests, how should they be implemented in
> the absence of knowing the OS. Sure some can be specifically tested for,
> but some are not testable features exactly, they're just platform
> conventions...
>
> > > usesWindowsStyleProgramInstallationLayout :: Bool
> >
> > I think you mean:
> > defaultPackageInstallationDirectory :: FilePath
> > (which should be entirely overrideable, of course.)
>
> But it's actually a good deal more complex that that, in that style it'd
> be:
>
> defaultPackageInstallationDirectory :: IO FilePath
> defaultBindir, defaultLibdir, ... :: IO FilePath
>
> in fact, I'm not sure it can be done in that style at all. Since on
> windows we're supposed to do relocatable installs and we're supposed to
> arrange to call the Win32 function to find the Program Files directory
> on the target machine and we have to generate source code to find the
> installation directory at runtime. This doesn't fit neatly into a
> generic test, any test would just be a proxy for isWindows.
>
> Really, the simplest method in this situation is just to have different
> code for Windows vs non-Windows. Some generic test(s) gains us nothing
> here.
>
> So given that such cases exist, lets allow people to do them slightly
> more reliably. Then in addition as we spot common patterns where generic
> feature tests would help we should try to standardise them.
>
> > >> 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.
>
> Having default cases or not doesn't make any difference, old programs
> can be broken on new OSs.
>
> So yes, that is certainly the advantage of feature tests but as I've
> pointed out not all cases fit neatly into nice generic feature tests.
>
> > 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.
>
> I am not arguing against feature tests! Where they work they're
> definitely nicer and more maintainable (though slightly more work to set
> up in the first place). However they do not cover all cases. Sometimes
> even it's necessary to implement a feature test as just a mapping from
> OS (eg directory separator char or text file line ending). This doesn't
> help as much with the maintainability at least it helps to collect OS
> specific info into one place in a program which makes porting easier.
>
> So I'm saying we need both.
>
> Duncan
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>