On 13/11/2012 03:08, Ian Lynagh wrote:
On Mon, Nov 12, 2012 at 02:19:38PM +0000, Simon Marlow wrote:
On 10/11/2012 02:47, Ian Lynagh wrote:
On Fri, Nov 09, 2012 at 05:46:05PM -0800, David Terei wrote:
On 9 November 2012 17:36, Ian Lynagh <i...@well-typed.com> wrote:
On Fri, Nov 09, 2012 at 04:34:20PM -0800, David Terei wrote:
+ Safe Haskell, however, <emphasis>does not offer</emphasis> compilation
+ safety.
Is this a bug? A few lines lower down the docs say that "Compiling and
executing untrusted code" is one of the two use cases for Safe Haskell.
What matters is, does this problem make Safe Haskell unusable. I'd
argue no,
FWIW, I'd say yes, as it doesn't allow the use cases I can think of (OK,
it does work for lambdabot/tryhaskell, but only because they only allow
toy expressions to be evaluated).
What's wrong with using a sandbox?
According to the docs, "Compiling and executing untrusted code" is one
of the two use cases Safe Haskell has been designed for. If "use a
sandbox" is an acceptable part of the answer, then why did we need Safe
Haskell for that use case at all? Isn't the entire use case solved by
"use a sandbox"?
Well yes. So don't get me wrong, the intention has always been to tackle
compilation safety too, but we realised it's an orthogonal issue to
language safety, so we were able to deal with one problem at a time, and
language safety is the harder (and more interesting) of the two.
Would you like to look at compilation safety? I don't think either I or
David has any immediate plans to do so, and as you say it's an important
next step. Someone will need to audit all the flags and compiler
features and think about whether they can be used maliciously - do you
have a devious mind? :)
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
