Tomasz Zielonka schrieb:
On Mon, Dec 18, 2006 at 12:14:36AM +0100, Joachim Durchholz wrote:
Magnus Therning schrieb:
There is of course the possibility that Haskell would bring a whole slew of yet-to-be-determined security issues. I doubt it will be worse than C though. Haskell might be prone to denial-of-service attacks. E.g. sending it data that cause it to evaluate an infinite data structure.
That would be a bug in the implementation of an algorithm, not an inherent Haskell problem.
In the same way one could argue that running over the end of an array in C is a bug in the implementation of an algorithm, not an inherent C problem. IOW it's the same kind of problem: a kind of bug that the language, by its very nature, allows. The Haskell designers decided that the advantages (more flexibility in code reuse) outweighs the disadvantages (having bottom in every domain, potential for driving Haskell programs into nontermination by feeding them cleverly constructed inputs). I'm not sure that this problem really exists. It's just a potential problem that's difficult to diagnose. In other words, this kind of problem won't get much notice until people start attacking Haskell code in earnest. That's the reason why I'd like to see this kind of problem addressed before Haskell systems become both large and widely-used.
Still, I'd want to have the results of a strictness analysis attached to Haskell software.
Why? In case the strictness analyzer was buggy?
I'd be perfectly happy if that analysis were just a note saying "run ghc with such-and-these options and inspect the intermediate code for function foo to see that the strictness analyzer determined it will always terminate". I'm after checkability, not after making life miserable for programmers :-)
Then again, avoiding global state and using a language with garbage collection, a strong type discipline and checked pointer dereferencing (say: Java, Ruby, Python, whatever) would probably go a far way towards safer software, even if it's not an FPL.
But implementing deeply mathematical concepts in a mathematically oriented language (like Haskell) seems to be a better idea, if only to make the implementation closer to specification.
The equational properties of Haskell expressions make programming easier. I wouldn't expect them to help particularly for expressing mathematical concepts: for once, the bulk of GPG code is still about moving around and transforming data, not about mathematics; second, I'd expect that non-mathematical concepts benefit from equational reasoning just as much. Regards, Jo