On Thu, Aug 30, 2012 at 3:09 AM, Roman Leshchinskiy
As I said earlier, I will definitely remove the .Safe modules. I'm not particularly keen on adding .Unsafe modules but in the scheme you're proposing, they'll just reexport a few functions and are (hopefully) easy to generate automatically so if there really is demand for it, I'll add them. Although I'd like to point out that with these scheme, vector won't have any SafeHaskell-safe modules so I'm not entirely sure what the point is, given that the entire discussion was because people objected to removing support for SafeHaskell.
My main interest is having the .Safe modules removed. I wanted to present a compromise that'd allow people that care about Safe Haskell to still use vector. I'm hoping that having .Unsafe modules will be less work than having .Safe modules. My intention was to move from: * M - Unsafe * M.Safe - Trustworthy to: * M - Trustworthy * M.Unsafe - Unsafe I just had a look at Data.Vector and the haddock docs claim that it's Safe-inferred. So I guess I don't understand the current setup even. Why aren't the M modules Unsafe, given that they use IO in their implementation?
A caveat: I will only add the .Unsafe modules if they are generated automatically. I *hope* that's easy to do but can't make any promises as to how long it will take at this point. If someone else wants to have a go at automatic generation, I'll gladly accept patches.
Fair enough. Could you remove the .Safe modules before that?
Or is this impossible and will I have to do this?
module Foo (unsafeFoo) where
-- | (Deprecated) Very long comment unsafeFoo :: Very Long Type unsafeFoo = ...
module Foo.Unsafe(unsafeFoo) where import qualified Foo
-- | Very long comment unsafeFoo :: Very Long Type {-# INLINE unsafeFoo #-} unsafeFoo = Foo.unsafeFoo
I'm afraid so.
Last question: do the +1 comments mean "yes, sounds good" or "yes, this is something I will use"?
For me it is "removed the .Safe modules please". -- Johan