Safe Haskell at the export symbol granularity?

David Terei dave.terei at gmail.com
Thu May 17 21:14:16 CEST 2012


On 17 May 2012 23:50, Ryan Newton <rrnewton at gmail.com> 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.)

Sure, the proposed syntax wasn't a serious proposal as it has
backwards compatibility issues so pragmas are the better choice. It's
just a clearer syntax when discussing the semantics of the idea.

>
> 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.

Thanks, I'll keep that in mind. Let me know how Antoine's suggestion
works out for you and any other feedback you have please.

>
> 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?

I think so. I'm not very familiar with the type checker in GHC or
typechecking in general but looking through the code just then it
seems doable. There doesn't seem anything other than maybe some hard
engineering work that would prevent this.

~ David

>
>   -Ryan
>
> P.S. In my two examples --
>    There's only one "Acc" type and Accelerate's "fold" can pretty easily be
> moved into an .Unsafe module, though it breaks the
> one-giant-module-for-the-whole-programming-model thing it has going now.  In
> the Par example on the other hand type classes are used to abstract over
> different implementations, so that's where we run into the safe/unsafe
> factoring problem.



More information about the Libraries mailing list