[Haskell-cafe] Re: A suggestion for the next high profile Haskell
project [Was: Re: What is a hacker?]
jo at durchholz.org
Tue Dec 19 06:52:17 EST 2006
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
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
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.
More information about the Haskell-Cafe