[Haskell-cafe] Re: A suggestion for the next high profile Haskell project [Was: Re: What is a hacker?]

[Joachim Durchholz]

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