On 16/07/2012 16:17, Roman Leshchinskiy wrote:
Simon Marlow wrote:
Ah ok, so your concern was that you couldn't easily find out whether
runST was safe or not? If you look at the library docs:
Whether runST is safe or not has a huge impact on what ST code I can
declare Trustworthy even if I d
Simon Marlow wrote:
>
> The fact that you can't do arbitrary side effects in ST follows from the
> definition of safety and the fact that runST injects ST computations
> into pure computations. So there's really no design choice here. The
> same applies to the Par monad, and any monad that inject
Simon Marlow wrote:
Perhaps I gave the wrong impression: of course you should carefully
consider every use of unsafePerformIO, just as we already do. You
should only mark an interface as Trustworthy if you really believe that
it is.
How firm should your belief be? Well, you could ask the sa
Re-adding haskell-platform@, which I assume you left off by accident?
On Tue, Jul 17, 2012 at 7:05 PM, Yitzchak Gale wrote:
> Gregory Collins wrote:
> > This slightly underestimates the amount of work required. Each package's
> api
> > must be carefully audited for unsafe functions, you can't ju
Gregory Collins wrote:
> From the paper:
>
> "A module that is declared to be Trustworthy is claimed by the
> author to expose a safe interface, even though its implementation
> might make use of unsafe features."
>
> Putting a Trustworthy on the top of a module means that "I, the module
> author,
On Tue, Jul 17, 2012 at 8:51 PM, Yitzchak Gale wrote:
> So by my reading, it is enough just to look over the
> API to make sure nothing apparently unsafe is
> exported
That's an audit :). I'm just saying that it ought to be done quite
carefully. If we care about Safe Haskell being useful at all
On 17/07/12 10:28, Roman Leshchinskiy wrote:
Simon Marlow wrote:
The fact that you can't do arbitrary side effects in ST follows from the
definition of safety and the fact that runST injects ST computations
into pure computations. So there's really no design choice here. The
same applies to t
#200: Can't build for compatibility with Eclipse
+---
Reporter: es...@ieee.org |Owner: dons
Type: defect | Status: new
Priority: major |Milestone:
Component: Platform
