Besides GUI stuff, in what modules are the platform neutral stuff implemented? Or how > do I look for this code?

Most of the code is platform neutral. A few specific bits (System.Posix, System.Win32) are limited to one operating system, but that's hardly any of it. If you just write code, there is a strong chance it will work perfectly on both operating systems. I've only ever developed Haskell on Windows, and I've never had a Linux user have a problem with any of it. About the only thing to be "careful" about with platform differences is that you should make use of the System.FilePath module to manipulate filepaths, if you are doing that to any great extent. If you say what you are tying to do, and why you suspect it might not "just work" in a cross platform manner, people might be able to address your specific concerns. Thanks Neil On 10/22/07, Neil Mitchell wrote:

Hi Bill,

...

In the Haskell libraries, is there an OS abstraction module, that would "hide" the POSIX API and Win-32 API? If not, this would be nice so that Haskell "programs" could be written in an OS independent manner!

Yes, Haskell provides a fairly complete API in the base libraries, which is platform neutral. If you want platform neutral GUI programs then you have Gtk2hs.

Thanks

Neil

On 10/22/07, Galchin Vasili wrote:

Hi Neil,

I am really talking about a module or perhaps a Haskell class that provides notion for multiple threads of execution, semaphores, .. that "hides" POSIX vs Win32 APIs .. i.e. the underlying OS APIs would be totally hidden. The reason I bring this up is that OS abstraction layers are very common in "mainstream" languages like C++. Any code written using an OS abstraction layer is absoutely portable. IMO if Haskell (or say OCaml) want to be accepted by industry this kind of functionality is absolutely critical.

Sure, that would be Concurrent Haskell: http://haskell.org/haskellwiki/GHC/Concurrency If that's not what you're looking for, post again. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "in a recent future, this is past" -- James Keelaghan

Hi Bill

I am really talking about a module or perhaps a Haskell class that provides notion for multiple threads of execution, semaphores, .. that "hides" POSIX vs Win32 APIs .. i.e. the underlying OS APIs would be totally hidden.

I think you are thinking in a "C" way. In Haskell, portable is the default. If you want to stop your code being portable, you have to go out of your way. Haskell is a much higher level language than others (such as C). Because the language is higher level, it tends to promote much higher level abstraction in the libraries - hiding platform idiosyncrasies in the process.

IMO if Haskell (or say OCaml) want to be accepted by industry this kind of functionality is absolutely critical.

It is critical. Perhaps if C wants to be taken seriously it should provide portability, which has been present in Haskell since the beginning :-) Thanks Neil

PS so far there are only a hand full of FPL shops .. like http://www.galois.com, http://www.skydesk.com, http://www.janestcapital.com/ . On 10/22/07, Galchin Vasili wrote:

Hi Neil,

You misunderstand me. I am really tired of imperative langauges like C/C++ .. I work in industry (for a long time) and have programmed in ANSI C for more than 10 years. Please see my interleaves below.

Regards, Bill

On 10/22/07, Neil Mitchell wrote:

...

Hi Bill

...

I am really talking about a module or perhaps a Haskell class that provides notion for multiple threads of execution, semaphores, .. that

...

"hides" POSIX vs Win32 APIs .. i.e. the underlying OS APIs would be totally hidden.

I think you are thinking in a "C" way. In Haskell, portable is the default. If you want to stop your code being portable, you have to go

^^ how? If I define something like "class OS where ...." and define a POSIX instance of "class OS" and a Win32 API instance.. function calls will be to the instances and hence the OS APIs are visible. Yes?

out of your way. Haskell is a much higher level language than others

...

(such as C). Because the language is higher level, it tends to promote much higher level abstraction in the libraries - hiding platform idiosyncrasies in the process.

...

IMO if Haskell (or say OCaml) want to be accepted by industry this kind of functionality is absolutely critical.

It is critical. Perhaps if C wants to be taken seriously it should provide portability, which has been present in Haskell since the beginning :-)

^^ the problem is that C/C++ is taken seriously even though they are high level assemblers. C/C++ have monopoly (as I am sure) in industry. It is almost impossible to convince the software industry to consider FPLs (assuming they even know what an FPL is). It is the FPL community that has to proof itself if is to break into the software industry.

Thanks

...

Neil

Hi Bill,

...

...

I am really talking about a module or perhaps a Haskell class that provides notion for multiple threads of execution, semaphores, .. that "hides" POSIX vs Win32 APIs .. i.e. the underlying OS APIs would be

totally

...

hidden.

I think you are thinking in a "C" way. In Haskell, portable is the default. If you want to stop your code being portable, you have to go

^^ how? If I define something like "class OS where ...." and define a POSIX instance of "class OS" and a Win32 API instance.. function calls will be to the instances and hence the OS APIs are visible. Yes?

OK, I think I'm slowly figuring out what you are meaning. You want to write some code which runs on POSIX, and some which runs on Win32, each of which bind to some foreign library which is different on both operating systems. The key thing to note about this is that whether a program is running on Windows or Posix is fixed at compile time. Things like classes can do some of what you seem to be after, but it tends to be easier to reach for the C pre processor. Let's take a simple login scenario. In Linux you enter the user name using the call getLine, and in Windows you call something else like getInputString. The way I would structure this would be: getUserName :: IO String #ifdef WINDOWS getUserName = getInputString #else getUserName = getLine #endif (Note - it wouldn't be WINDOWS - I can't remember what the blessed CPP for distinguishing Windows and Posix is) Then your logic code can call getUserName, and the platform differences are papered over. You could use classes, but for something which is OS dependent, I'd tend to use the CPP. Thanks Neil

yep .... FFI On 10/22/07, Neil Mitchell wrote:

Hi Bill,

...

...

...

I am really talking about a module or perhaps a Haskell class

...

provides notion for multiple threads of execution, semaphores, ..

that that

...

"hides" POSIX vs Win32 APIs .. i.e. the underlying OS APIs would be totally hidden.

I think you are thinking in a "C" way. In Haskell, portable is the default. If you want to stop your code being portable, you have to go

^^ how? If I define something like "class OS where ...." and define a POSIX instance of "class OS" and a Win32 API instance.. function calls will be to the instances and hence the OS APIs are visible. Yes?

OK, I think I'm slowly figuring out what you are meaning. You want to write some code which runs on POSIX, and some which runs on Win32, each of which bind to some foreign library which is different on both operating systems.

The key thing to note about this is that whether a program is running on Windows or Posix is fixed at compile time. Things like classes can do some of what you seem to be after, but it tends to be easier to reach for the C pre processor.

Let's take a simple login scenario. In Linux you enter the user name using the call getLine, and in Windows you call something else like getInputString. The way I would structure this would be:

getUserName :: IO String #ifdef WINDOWS getUserName = getInputString #else getUserName = getLine #endif

(Note - it wouldn't be WINDOWS - I can't remember what the blessed CPP for distinguishing Windows and Posix is)

Then your logic code can call getUserName, and the platform differences are papered over.

You could use classes, but for something which is OS dependent, I'd tend to use the CPP.

Thanks

Neil

Hi Ryan, Thanks for your generous response. " By the way, you don't want to use typeclasses here; they solve the problem of having more than one possible interface at runtime, whereas you only care about compile-time" .. in reality I do care about decisions made at run-time (this just struck me as I am writing). I am trying to avoid "ifdef's" and have all decisions made at run-time (maybe given the nature of Haskell .. i..e static/compile-time type checking this is impossible) ... Trust me as i said in a previous post I am not a big fan of C++. I guess we are talking about strong type checking .. but static vs dynamic .. in the case of C++ it is a mixture, e.g. when a C++ class's member function is not "virtual" then "call resolution" is done at compile-time vs "virtual" when it is done at run-time via the virtual function table. Everybody ... by no means am I a booster of C++ .. i.e. "done it, seen it ...". Maybe a previous "poster" addressed my concerns. In discussing this OS Abstraction Layer, I think I am thinking of some notion of "laziness" (read ... decisions made at run-time .. not compile-time .. otherwise I think we have to resort to ifdefs which are not so nice and require a lot of code maintenance.) Kind regards, Bill On 10/22/07, Ryan Ingram wrote:

Also, note that it's really easy to hide all the CPP uglyness in a single file, or do it with Makefiles, or something along those lines.

By the way, you don't want to use typeclasses here; they solve the problem of having more than one possible interface at runtime, whereas you only care about compile-time. The easiest way to solve that problem is through the module system. An example follows.

with this directory tree: System/Abstraction.hs System/Abstraction/POSIX.hs System/Abstraction/Windows.hs

in System/Abstraction.hs:

module System.Abstraction ( #if POSIX module System.Abstraction.POSIX #elsif WINDOWS module System.Abstraction.Windows #endif ) where

#if POSIX import System.Abstraction.POSIX #elsif WINDOWS import System.Abstraction.Windows #else #error Unknown system type #endif

Now you can write POSIX.hs and Windows.hs independently to implement whatever OS/foreign interface you care about, and your other code can import System.Abstraction without needing -cpp.

Alternatively you can make POSIX.hs and Windows.hs just declare themselves as "module System.Abstraction" and use your build system to compile the correct one.

On Tue, Oct 23, 2007 at 09:10:02AM -0400, Isaac Dupree wrote:

Galchin Vasili wrote:

...

In discussing this OS Abstraction Layer, I think I am thinking of some notion of "laziness" (read ... decisions made at run-time .. not compile-time .. otherwise I think we have to resort to ifdefs which are not so nice and require a lot of code maintenance.)

It is difficult on existing systems to make a binary that can link with multiple alternate sets C functions. Also you may need the corresponding header-files when compiling. (But non-binary implementations such as Yhc might be able to lazily only look up a foreign-imported function once it's called, it perhaps being _|_ if not found). I can't speak to how much there are code maintenance issues of ifdefs... but if you don't have a Windows system to test against, for example, then you'll *never* know if Windows-specific parts of your code work, ifdefs or not.

You would, at least, know that the Windows-specific Haskell bindings themselves compile. I don't think this is worth the ugliness, but it is something anyhow. -- David Roundy Department of Physics Oregon State University

David Roundy wrote:

On Mon, Oct 22, 2007 at 09:44:11PM -0500, Galchin Vasili wrote:

...

Hi Ryan,

I am trying to avoid "ifdef's" and have all decisions made at run-time (maybe given the nature of Haskell .. i..e static/compile-time type checking this is impossible) ...

I don't see how in any language you could introduce working run-time-determined os-specific code. How would you link with the windows libraries under linux, and vice versa? And moreover, why would you do so? Unless you're talking about running under an interpreter, I don't see how you'd construct a binary that would be able to run under both windows and linux.

A FFI supporting dynamic linking, plus a lot of hope? The binary wouldn't run under both OS's, but the program could pick which library to link against at runtime. -- Tommy M. McGuire mcguire@crsr.net

Galchin Vasili wrote:

I am really talking about a module or perhaps a Haskell class that provides notion for multiple threads of execution, semaphores, .. that "hides" POSIX vs Win32 APIs ..

I wonder if this discussion is missing the point: if you only want to do threads, then Haskell (or GHC, to be more precise) already provides thread abstractions that hide the OS-specific implementation details. In fact, doing it yourself with the FFI is likely to cause a lot of problems. Take a look at the Control.Concurrent module, and GHC's -threaded option. Cheers, Simon