[Haskell-cafe] bytestring, array and Safe Haskell

2012-05-08 Thread Francesco Mazzoli
Why are 
http://hackage.haskell.org/packages/archive/bytestring/0.9.2.1/doc/html/Data-ByteString-Unsafe.html 
and 
http://hackage.haskell.org/packages/archive/array/0.4.0.0/doc/html/Data-Array-Unsafe.html 
Safe-inferred?


The first one uses inlinePerformIO, so it clearly shouldn't be marked as 
Safe. Maybe Safe Haskell doesn't check that function?
The second is a bit messier since it uses unboxed types and primitive 
operations... But they clearly should be marked as Unsafe, and it 
surprises me that Safe Haskell is that relaxed when checking for safe 
functions.


Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] bytestring, array and Safe Haskell

2012-05-08 Thread Austin Seipp
The reasoning is outlined in the user manual here:

http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-haskell.html#safe-inference

Basically, these modules will compile without error if they were to be
compiled with -XSafe enabled. Thus, they are safe-inferred. The check
does not scrutinize individual functions in any way; all of SH works
on the level of module boundaries, as well as packages (whether or not
to enforce package trust when compiling clients.) As to why they are
safe-inferred, considering they are importing primitive
libraries/modules, and the module inlinePerformIO lives in should be
marked unsafe, well, I don't know. This is just a simple check, and
anything more powerful would likely be considerably more complex and
difficult to get right.

They should be marked as -XUnsafe since their use in a safe program
could cause crashes. It's likely not a conscious choice that this is
the case, as much as it is probably an oversight. Many of the core
libraries have needed refactoring/changes at the module level due to
Safe Haskell (and hence there is now a proliferation of *.Unsafe and
*.Safe modules, a la ForeignPtr.)

I do not know if the next major version of the ByteString library
(0.10) or array has marked these as unsafe or not. They should be if
not.

Perhaps someone else who's more aware of the new Safe Haskell design
can comment further.

On Tue, May 8, 2012 at 3:03 PM, Francesco Mazzoli f...@mazzo.li wrote:
 Why are
 http://hackage.haskell.org/packages/archive/bytestring/0.9.2.1/doc/html/Data-ByteString-Unsafe.html
 and
 http://hackage.haskell.org/packages/archive/array/0.4.0.0/doc/html/Data-Array-Unsafe.html
 Safe-inferred?

 The first one uses inlinePerformIO, so it clearly shouldn't be marked as
 Safe. Maybe Safe Haskell doesn't check that function?
 The second is a bit messier since it uses unboxed types and primitive
 operations... But they clearly should be marked as Unsafe, and it surprises
 me that Safe Haskell is that relaxed when checking for safe functions.

 Francesco.

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



-- 
Regards,
Austin

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] bytestring, array and Safe Haskell

2012-05-08 Thread Francesco Mazzoli

On 08/05/12 21:45, Austin Seipp wrote:

The reasoning is outlined in the user manual here:

http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-haskell.html#safe-inference


Yes, I was looking at that while writing that message.

Mine wasn't that much a complaint regarding the wrong inference (even if 
it looks like  it should be possible to fix the inference those instance 
- especially the bytestring one), but rather regarding the fact that 
those modules should be marked unsafe manually.


Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe