Hello Ivan, Saturday, July 3, 2010, 3:24:34 PM, you wrote:
haskell code is easily ported between OSes, unlike C one. when i ported my application from Win to Linux, i spend one day on haskell code and 3 days on C one, despite the fact that haskell code dealed with OS interaction and C used purely for computations
Care to provide more details? This story intrigues me (even though I've never really used C that much, and would prefer to keep it that way).
since 2004 i'm developing FreeArc archiver, something like winzip. in 2007 i've ported it to Linux. the only Haskell part that required was my own I/O library: i developed it in 2005 since ghc doesn't supported large files and unicode filenames at that time. my library used Win-specific calls and i, naturally, required to add some Unix way to compile it - i just used standard Haskell I/O calls generally speaking, as far as your program utilizes only existing Haskell libraries, it just work. problems starts only when existing Haskell libraries can't serve your needs and you start binding to some C or OS-specific code for the C part, i have found that some APIs i've used in mingw were in fact MSVC-compatibility ones, and was absent in Linux gcc i just looked at my darcs repository. Unix-specific patches were:
added /dev/urandom as entropy source for Unix Unixifying: dir.size:=0 Added Unix support for GetPhysicalMemory, GetProcessorsCount Unix: config files in "/etc"; fixed compilation scripts Unix: look for SFX in /usr/lib Unix: UTF8 for filelist/screen/filenames/cmdline encoding Unix: getThreadCPUTime CUI: hidden password input now works on Unix too
so, the main catch for C part were OS-specific calls like GetPhysicalMemory - i spent lot of time reading mans. for Haskell part, main changes were about default directories -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com