Re: Is Safe Haskell intended to allow segfaults?

Hi, On 9 August 2016 at 01:32, David Terei wrote: > I imagine in Java, that I can construct an invalid pointer in foreign > code, and then cause segfaults without the Java code having any > issues. Just guessing at this, so very interested to know how it's > prevented if I

Re: Is Safe Haskell intended to allow segfaults?

Thanks for bringing this up Ryan, it's an interesting direction of thought. It's been a while since we originally designed SafeHaskell, so I can't remember our thinking very well with this area. I believe it came down to the following: * Our primary concern was to be able to 'trust the types',

Re: Is Safe Haskell intended to allow segfaults?

I think what you are proposing is reasonable. I wasn't present when Safe Haskell's design was originally fleshed out so I don't know why this route wasn't taken. Edward Excerpts from Ryan Newton's message of 2016-08-08 16:00:38 -0400: > Hi Ed, > > Thanks, I went back to the paper and read

Re: Is Safe Haskell intended to allow segfaults?

Hi Ed, Thanks, I went back to the paper and read those sections. It sounds like this design heavily reflects the untrusted-code use case. I believe ceding the entire IO monad is too pessimistic, and it's also against the *spirit* of the type safety guarantee mentioned in the paper: "Type

Re: Improving cost center reports to show residency?

Hello Omer, I don't quite understand; is +RTS -hc what you want? That will output a heap profile per cost center, which will give you residency. Is the problem that you need a heap profile every minor GC rather than major GC (e.g. something like https://ghc.haskell.org/trac/ghc/ticket/8504 ?)

Re: Is Safe Haskell intended to allow segfaults?

Hello Ryan, The guarantee that Safe Haskell gives with regards to IO is a little subtle and is mentioned in Section 3.1 of the paper, and detailed in Section 5.1. Essentially, to use Safe Haskell, you are responsible for defining the type at which untrusted code is to be called. Using an

Re: Is Safe Haskell intended to allow segfaults?

> > Pretty sure it's impossible to allow IO without enabling all of it one way > or another. And as soon as you allow *any* IO, you're open to various kinds > of failures including segfaults. The only way you will get your type system > to prevent that is fully specified dependent typing both in

Re: Is Safe Haskell intended to allow segfaults?

On Mon, Aug 8, 2016 at 1:27 PM, Ryan Newton wrote: > As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe > language you can trust the types", and I'd always assumed that meant Safe > Haskell is a type safe language, even in the IO fragment. Pretty sure

Is Safe Haskell intended to allow segfaults?

We're trying to spend some cycles pushing on Safe Haskell within the stackage packages. (It's looking like a slog.) But we're running up against some basic questions regarding the core packages and Safe Haskell guarantees. The manual currently says:

Improving cost center reports to show residency?

One thing that we can't currently see in cost center reports is the residency and because of that cost centers can't be used for fixing memory leaks or reducing max. memory residency. For example, I can have a function that returns an `Int` but allocates lots of intermediate data on the way. In