On 2007-08-16, Duncan Coutts
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 -><-