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
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.