Re: Is Safe Haskell intended to allow segfaults?

I'm hearing that Safe Haskell is great for pure use cases (lambda bot). But that doesn't depend on being able to write arbitrary IO code inside the Safe bubble, does it? In fact *all* of IO could be outside the safe boundary for this use case, could it not? Are there any existing cases where it

Re: enumFromThenTo for Doubles

Turns out the accumulated error is even worse: Prelude> let old x y z = let eftt i j = i : eftt j (j+j-i) in let d = y - x in maximum $ takeWhile (<= z + d) $ eftt x y Prelude> old 0.0 0.1 86400.0 86400.005062 Prelude> let new x y z = let d = y - x in let go i = i : go (i + d) in maximum $

Re: Is Safe Haskell intended to allow segfaults?

On Tue, Aug 9, 2016 at 4:19 PM, Edward Z. Yang wrote: > If you can execute subprocesses, you could always spawn gdb to > attach via ptrace() to the parent process and then poke around > memory. > Don't even need that if you're just talking segfaults, you can always spawn a

Re: Is Safe Haskell intended to allow segfaults?

I see three major stories here: 1.) If you remove IO from being able to be compiled inside Safe code _at all_ most packages I have that bother to expose Safe information will have to stop bothering. I'd have to cut up too many APIs into too many fine-grained pieces. This would considerably reduce

Re: Is Safe Haskell intended to allow segfaults?

Heh, ok, segfaults themselves are a red herring. More precisely: The operational semantics for a SafeIO language should always accurately model its memory state. The application should not compute (take a step in the semantics) in a way that exposes corrupt memory or arbitrary undefined

enumFromThenTo for Doubles

Noticed this today: ghci> let xs = [0.0,0.1 .. 86400.0] in maximum xs 86400.005062 enumFromThenTo is implemented by numericEnumFromThenTo: https://github.com/ghc/ghc/blob/a90085bd45239fffd65c01c24752a9bbcef346f1/libraries/base/GHC/Real.hs#L227 Which probably accumulates error in

Re: Is Safe Haskell intended to allow segfaults?

On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov wrote: > > Yes, this can be done with JNI, see e.g. [1]. Additionally, by using > sun.misc.Unsafe [2], one can cause segfaults even from pure Java. > [1] https://www.cs.princeton.edu/~appel/papers/safejni.pdf > [2]

Fwd: Help on first ticket

-- Forwarded message -- From: Richard Fung Date: Tue, Aug 9, 2016 at 8:33 AM Subject: Re: Help on first ticket To: Simon Peyton Jones It's been a while but I've been able to spend more time on it recently made some progress. I

Re: Is Safe Haskell intended to allow segfaults?

I've always treated Safe Haskell as "Safe until you allow IO" -- in that all 'evil' things get tainted by an IO type that you can't get rid of by the usual means. So if you go to run pure Safe Haskell code in say, lambdabot, which doesn't give the user a means to execute IO, it can't segfault if

Re: Is Safe Haskell intended to allow segfaults?

If you can execute subprocesses, you could always spawn gdb to attach via ptrace() to the parent process and then poke around memory. Yes this is a "dumb" example but I think it goes to show how important it is to correctly characterize what the threat model is. A "no-segfault" fragment of