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 <ryani.spam@gmail.com> 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.