Hi Ryan,<br><br> Thanks for your generous response. " By the way, you don't want to use typeclasses here; they solve the<br>problem of having more than one possible interface at runtime, whereas<br>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.)
<br><br>Kind regards, Bill<br><br><div><span class="gmail_quote">On 10/22/07, <b class="gmail_sendername">Ryan Ingram</b> <<a href="mailto:ryani.spam@gmail.com">ryani.spam@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, note that it's really easy to hide all the CPP uglyness in a<br>single file, or do it with Makefiles, or something along those lines.<br><br>By the way, you don't want to use typeclasses here; they solve the
<br>problem of having more than one possible interface at runtime, whereas<br>you only care about compile-time. The easiest way to solve that<br>problem is through the module system. An example follows.<br><br>with this directory tree:
<br>System/Abstraction.hs<br>System/Abstraction/POSIX.hs<br>System/Abstraction/Windows.hs<br><br>in System/Abstraction.hs:<br><br>module System.Abstraction (<br>#if POSIX<br> module System.Abstraction.POSIX<br>#elsif WINDOWS
<br> module System.Abstraction.Windows<br>#endif<br>) where<br><br>#if POSIX<br>import System.Abstraction.POSIX<br>#elsif WINDOWS<br>import System.Abstraction.Windows<br>#else<br>#error Unknown system type<br>#endif<br>
<br>Now you can write POSIX.hs and Windows.hs independently to implement<br>whatever OS/foreign interface you care about, and your other code can<br>import System.Abstraction without needing -cpp.<br><br>Alternatively you can make
POSIX.hs and Windows.hs just declare<br>themselves as "module System.Abstraction" and use your build system to<br>compile the correct one.<br></blockquote></div><br>