Hello Neil, Monday, August 6, 2007, 4:36:54 PM, you wrote:

...

important question - what it should return on cygwin (and win32-emulating environments on unix if such ones exist)

Very good question. I guess we should return the host operating system - i.e. Windows on Windows, and Unix on Unix. The emulation is generally for programs that aren't cross compatible, if you've taken the time to figure out what OS you are really on, you can probably be compatible to it.

i think it's better to ask people which has cygwin experience overall, i agree with you - it will be great to add isWindows now. details of its behavior may be outlined based on further experience (i bet that there are no cygwin haskell developers at this moment). my only anxiety that it should be put outside of base -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Ian Lynagh wrote:

Finally, it needs to remain in base if we are to use it for ifdef-removal in the base libraries (and as low down in base as possible).

Would it be helpful to know the full set of platform-tests base currently uses, so we know a minimum of what tests we need in base? And... there is always the "code duplication" approach, if anything needs to be used in base as well as being upgradable, although I would not recommend that approach (unless with a detailed consideration) :-) Isaac

On Mon, Aug 06, 2007 at 06:04:41PM -0300, Isaac Dupree wrote:

Thomas Schilling wrote:

...

On 6 aug 2007, at 12.26, Neil Mitchell wrote:

...

.... = os == "mingw"

This is wrong on so many levels!

I agree, but

...

Proposal:

Add System.Info.isWindows :: Bool

is hardly better, because this opens the door to political issues (why not have isLinux, isFreeBSD, isNetBSD, ...?) And I'm not even sure returning True for every Windows incarnation is the right thing in most use cases. In general you want to test for APIs--not the OS per se.

Like it or not, Windows is a very significant, special case, where programs often transform themselves, more than they need to, based on a simple judgment of whether they're on "windows" or not, even when POSIX APIs are available, etc., etc. ***I don't like it either.*** But defining APIs is hard work, Windows is in practice much different from almost anything else, much more important, and many of us aren't interested in expending too much hard work to support (flexibly, in detail,) stupid closed-source platforms. Developers tend to want to check for isWindows anyway: they already do, with os=="mingw" and other hacks. ***I think isWindows is necessary, at least as a intermediate solution***... if someone makes more, API-specific queries sometime, then it will be easier to search existing code for the unified "isWindows" and find everywhere that might be improved.

Yes. I agree, I wouldn't want to see an enumerated data type, because you really want to query features the environment supports, not necessarily what OS. (like, ReactOS provides the win32 api) so, I'd actually like to see two isWindows :: Bool isPosix :: Bool where they say whether the given APIs are available (to some reasonable approximation). for instance, windows under mingw would be True,False, while windows under cygwin would be True,True and linux would be False,True. This covers the 'special' cases that most people have to worry about. I have nothing against a more complete API, but these two special cases are common and important enough that I think they should have special support. John -- John Meacham - ⑆repetae.net⑆john⑈

On Wed, Aug 15, 2007 at 03:40:56PM +0100, Neil Mitchell wrote:

By modifying your proposal ever so slightly (and probably as you intended anyway):

...

data OSFlavour = Linux | Windows | MacOS | BSD | Solaris | Other String deriving Eq

(who wants to add an Ord instance? then we can really debate whether Windows > Linux or vice versa)

We probably ought to have one, because sooner or later someone is bound to want to use OSFlavour as a map key or something. And Show, Read, Data and Typeable too. Thanks Ian

Hi

Yes, Eq, Ord, Show and Read.

I'm not sure it's possible to make it an instance of Data or Typeable is it? Doesn't that require a dependency on the generics package but System.Info is in the base package.

This is going to keep coming up, if we move the Data and Typeable classes out...

Is everyone ok with the type name? OSFlavour, OSKind, OSType ? We can't use OSName since it's not that specific.

OSFlavour - dislike, flavour pretty much means "it tastes like". Windows+Cygwin has flavours of both Windows and Unix. We want to say this is the OS you are using, its not just "a bit like" this one, but it really is, and it can only be one. OSType - seems fine. OSKind - again, has a slight "kind of like", and again Windows+Cygwin is kind of like multiple things. OSName - the name of your operating system - this is the one I would have picked. OS - nothing wrong with short names, especially when they are common abbreviations OperatingSystem - but no point optimising for character's when people are doing something we don't want them to be doing :-) I think in the end I'd pick OperatingSystem, as its very clear what it is. Thanks Neil

On Wed, 2007-08-15 at 18:05 +0100, Neil Mitchell wrote:

Hi

...

Yes, Eq, Ord, Show and Read.

I'm not sure it's possible to make it an instance of Data or Typeable is it? Doesn't that require a dependency on the generics package but System.Info is in the base package.

This is going to keep coming up, if we move the Data and Typeable classes out...

That's what I keep saying. I must sound like a broken record.

...

Is everyone ok with the type name? OSFlavour, OSKind, OSType ? We can't use OSName since it's not that specific.

OSFlavour - dislike, flavour pretty much means "it tastes like". Windows+Cygwin has flavours of both Windows and Unix. We want to say this is the OS you are using, its not just "a bit like" this one, but it really is, and it can only be one.

OSType - seems fine.

OSKind - again, has a slight "kind of like", and again Windows+Cygwin is kind of like multiple things.

OSName - the name of your operating system - this is the one I would have picked.

Only it isn't the name, it's a general categorisation. The os name might be "Windows Vista(tm)" or "FreeBSD" but the os type is just Windows or BSD.

OS - nothing wrong with short names, especially when they are common abbreviations

OperatingSystem - but no point optimising for character's when people are doing something we don't want them to be doing :-)

I think in the end I'd pick OperatingSystem, as its very clear what it is.

I think I'd pick OSType as its very clear what it is. :-) The other thing is what the variable is called. We can't take System.Info.os since that already exists. If we pick OSType then it's easy, we pick System.Info.ostype. If it's OperatingSystem what would you pick? If we were starting from scratch I might advocate os :: OS and osName :: String, but we're not, we've already got os :: String. Duncan

On Wed, Aug 15, 2007 at 06:05:41PM +0100, Neil Mitchell wrote:

...

I'm not sure it's possible to make it an instance of Data or Typeable is it? Doesn't that require a dependency on the generics package but System.Info is in the base package.

This is going to keep coming up, if we move the Data and Typeable classes out...

They can move to below most other packages, and for those few that have to be lower down the instances can be put in the generics package. This won't be happening for 6.8, though. Thanks Ian

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" 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) 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. I suspect that people too often assume that the same features are available on all unixes, given how common it is to break on some of them. 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) 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 :) 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'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). If only there was a decent package system- but I digress, Isaac

Aaron Denney wrote:

...

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.

One should never have a case for "Other" anyway. Either case ... of Windows -> ... Linux -> ... _ -> ... --default behavior or case ... of Windows -> ... Linux -> ... --intentionally broken on unimplemented platforms --or _ -> error "not implemented on unknown platforms" should be used, anyway. That's good practice for anything like this, not just in Haskell, that is not inherently a fixed set: "isOther" is nonsensical to check for. (I am recalling that anti-"other" conclusion for file/directory/... information flags in C++ Boost.) Isaac

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

On Thu, 2007-08-16 at 01:39 +0100, Ian Lynagh wrote:

On Thu, Aug 16, 2007 at 01:24:05AM +0100, Duncan Coutts wrote:

...

Yes, as Issaac suggests perhaps we should drop the String parameter to OtherOS since it tells you nothing useful.

You can match on

OtherOS "BeOS"

while you wait for the BeOS alternative to be added, although you do need a dash of CPP to support both old and new compilers once it has been added.

Hmm, but how is the base lib going to be set up to return OtherOS "BeOS"? This would have to be done during porting, wouldn't it be just as easy for said porter to add BeOS to the OSType enumeration? Duncan

On Thu, Aug 16, 2007 at 02:05:30AM +0100, Duncan Coutts wrote:

On Thu, 2007-08-16 at 01:39 +0100, Ian Lynagh wrote:

...

On Thu, Aug 16, 2007 at 01:24:05AM +0100, Duncan Coutts wrote:

...

Yes, as Issaac suggests perhaps we should drop the String parameter to OtherOS since it tells you nothing useful.

You can match on

OtherOS "BeOS"

while you wait for the BeOS alternative to be added, although you do need a dash of CPP to support both old and new compilers once it has been added.

Hmm, but how is the base lib going to be set up to return OtherOS "BeOS"? This would have to be done during porting, wouldn't it be just as easy for said porter to add BeOS to the OSType enumeration?

I was thinking of uname output, but it's true that GHC at least will just fail if it doesn't recognise the platform. I'm not sure about the other impls. Thanks Ian

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

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

On Fri, 2007-08-17 at 00:55 +0000, Aaron Denney wrote:

...

On 2007-08-16, Duncan Coutts 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Wed, Aug 15, 2007 at 03:28:19PM +0100, 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

I really really dislike the 'Other String' thing, it is pretty much always a sign of bad design. Why would some OS's be delegated to 'Other' status just because we happened to not know about them at some point? will all code have to become bloated by saying case os of Linux -> doLinux Other s | s == "Linux" -> doLinux .... or have to use CPP to figure out if other hardcoded values of OSFlavor exist and must be checked for? the data type isn't "normalized" in some sense. there are multiple representations of the same thing, and it arbitrary elevates a few choices to special cases for no good reason. ones that make sense would be either

data OSFlavor = Linux | Windows | MacOS | BSD | Solaris

-- returns OSFlavor if we know it. getOsFlavor :: Maybe OSFlavor

or

newtype OSFlavor = OSFlavor String

However, I don't think either is really needed (but wouldn't hurt) because the practical question we want answered is not whether we are on Solaris or Linux usually, but rather we are on a machine that supports POSIX or if we are on a machine that supports the Win32 API. it is entirely possible to be both (cygwin under windows) for instance. We really should not hard code anything like this in data types. if we want a fast special purpose API (like what was originally proposed) then 'isWindows' is perfect. if we want a general way to query the system type, then a String (perhaps wrapped in a newtype) is the way to go. the halfway approach is the worst of both worlds and just complicates code so, avoid the 'Other'! it will make your code faster, smaller, and more clearly designed and understood. John -- John Meacham - ⑆repetae.net⑆john⑈