Re: [Haskell-cafe] Safe Haskell at the export symbol granularity?

I have a related-seeming question: Say I have a type class with methods, and some functions implemented on top of it. The class methods are inherently unsafe. Instances of the class are supposed to satisfy some conditions, and if those conditions are met, the functions built on top are safe. So say I put the class in an Unsafe module, and re-export the class without its methods along with the derived functions in a Safe module. For anything unsafe to happen, the Unsafe module has to be imported somewhere. But if someone imports it and implements a bad instance, the Safe module *also* becomes potentially unsafe! What's the recommended practice here? (I can't really tell if this is the same question as originally posed by Ryan, but I think it's not.) On Thu, May 17, 2012 at 4:53 PM, Ryan Newton wrote:

Good point, Antoine!

I think that does the trick.

On Thu, May 17, 2012 at 10:48 AM, Antoine Latter wrote:

...

On Thu, May 17, 2012 at 8:50 AM, Ryan Newton wrote:

...

Thanks David.

I'm glad to see it was discussed in the wiki.  (Btw, my 2 cents is that I like the comment pragmas more than new keywords.)

The issue that I think doesn't make it into the wiki is of splitting, not modules, but type-classes. That's where I think it becomes a more serious issue.

Do you think a symbol-level Safe Haskell would be able to distinguish one method of a type class as unsafe, while the others are safe?

You can still do this at the module level, with the down-side of potentially not being able to implement a class with the safe version:

...

module Unsafe where

class MyClass a where   safeOp :: a -> Int -> IO ()   unsafeOp :: a -> Int -> IO ()

instance MyClass A where ...

...

module Safe   (MyClass(safeOp))   where

import Unsafe

I think this works.

Antoine

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Work is punishment for failing to procrastinate effectively.