Safe Haskell and Haskell Platform: near-term tactics

[Mark Lentczner]

On Fri, Jul 13, 2012 at 9:09 AM, David Terei <davidterei at gmail.com> wrote:

> I would have agreed with your thoughts Mark when SH was as it was in
> 7.2, I think the design of 7.4 and safe inference changes this.
>

As 7.2 got limited use, and 7.4 has only been out for a while, I'd still
claim we have little practical experience with Safe Haskell.

And, as Simon pointed out, the paper about SH isn't even out yet - the only
material is the GHC manual section. There really isn't enough information
or experience with SH out there yet.


> 1) Make sure your modules are properly split along safe / unsafe
> lines.


This is where the problem lies: There isn't enough experience to know how
to do this well. The vector package, for example, hasn't worked out so
well: Duplicating almost every module with a .Safe version seems a poor
solution. I don't mean to open up this for discussion in this thread, just
to point out that it is far from obvious how library developers should
structure their APIs.


> 4) Use either '-fwarn-safe' or '-fwarn-unsafe' on modules to check this
> and catch regressions in the future.
>

Again, I don't think it is clear to library writers how to handle this.

Further - for users of libraries, it isn't clear when one should or
shouldn't pay attention to the "safe" system. Alas, the name sounds like
something that all developers should be worried about - but the only use
cases I know of deal with plug-able code systems which are pretty rare for
most development. Hence, we don't yet have a real set of guidelines of how
to think about SH.

P.S just started a two week holiday in Argentina so probably will be flakey
> in replying if at all.


That sounds like fun... we'll expect pictures when you're back!

 - Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20120714/b733e15a/attachment.htm>