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.