[Haskell-cafe] Crash!

[Robert Greayer]

--- On Fri, 10/24/08, Derek Elkins <derek.a.elkins at gmail.com> wrote:
> > Just what is the concise, compelling, unembellished
> claim regarding
> > Haskell's inherent robustness?
> 
> The concise, compelling, unembellished claim is: if your
> "pure*" Haskell
> program segfaults (or GPFs) then it's the
> implementation's fault, not
> yours. [unless your OS/Arch is stupid]
> 
> This isn't unique to Haskell, every memory-safe
> language has it.
> 
> * "pure" as in "100% pure Java" which
> has similar claims

But Java's 'claim' actually works out to be easier to reason about: generally, with Java, no matter what 3rd party code you are using, without looking at the source, you know the only way (excluding a JVM/platform bug) that your code will segfault or otherwise corrupt the runtime system is if the 3rd party code includes native libraries (i.e. is non-100% pure Java -- the third party code is more than just collection of jar files).  

Whereas with Haskell code, you can't really know if it is safe (in this sense) without looking at the code in the Haskell libraries you're using.  A library that is 100% Haskell can be doing unsafe things *in Haskell*.  Further, many safe Haskell libraries require the use of 'unsafe' functions, so there's no (afaik) simple rubric for determining if a library is safe, and hence whether a program will be segfault (or memory corruption) free.

With the advent of the 'haskell platform' it seems to me that the situation could improve -- given that the platform has been 'blessed', you could reason that as long as you stick to libraries that are in the platform or libraries that are free of 'unsafe' functions or FFI (or any other known pitfalls), you've got a safe executable (and then, if it segfaults, you can blame the platform).  It would be extremely clever if your build tool could take advantage of this and tell you whether your executable was 'safe' in this sense, based on its analysis of the packages (or even functions) used to build it.  (Or perhaps this is already a solved problem and I just don't know about it!)