Safe Haskell and Haskell Platform: near-term tactics

[David Terei]

So I'll chime in then as the principle author of Safe Haskell.

I don't manage the Haskell Platform so I think they should do what
they feel most comfortable with. Supporting such software is a lot of
work and pretty frustrating at times.

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.

Basically, to transition to Safe Haskell we as a community should do
the following:

1) Make sure your modules are properly split along safe / unsafe
lines. Label unsafe modules and functions accordingly. Those that
aren't should be split, using deprecation and a transition period as
is normal practice.

2) Modules that are safe but use unsafe internals (e.g ByteString)
should have a {-# LANGUAGE Trustworthy #-} pragma slapped on them.

3) Safe inference should now infer the rest of the modules correctly
as safe or unsafe.

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

The nice thing about the above is you shouldn't run into any issues of
packages not building due to Safe Haskell. You may run into
regressions / mismatches where modules that are safe aren't inferred
safe due to some dependency not be Trustworthy. That for an initial
transition strikes me as the better tradeoff than using the Safe
pragma directly and having to have a huge version bump / transition
flag day that could work but could easily be hell.

Basically, it shouldn't be a big deal at all.

Cheers,
David

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

On 11 July 2012 23:15, Mark Lentczner <mark.lentczner at gmail.com> wrote:
> There is already a thread discussing "safe" - this thread is to discuss Safe
> Haskell in the context of our near-term (6 mos. to a year) work on Haskell
> Platform.
>
> It is my observation that Safe Haskell is a very new feature, and one that
> is not yet widely used in the libraries. Further, there seems to be
> considerable lack of experience, and clarity, even among the Haskell
> heavy-weights, on how it should be applied, what the best practices are, how
> to explain it to developers, etc....
>
> Therefore, it seems to me that it can hardly be considered, at this point in
> time, a stable main-stream dependable aspect of the system. I think we
> should not consider it a requirement of libraries for addition to the
> platform for the upcoming release (2012.4.0.0), nor the release after
> (2013.2.0.0).
>
> We should make Safe Haskell a featured part of the platform at the point at
> which the ecology demonstrates a stable, consistent, inclusion of the
> feature in the libraries, with understood best practices.
>
> I recognize there is a bit of a chicken-and-egg problem here: My
> understanding (murky at best) of Safe Haskell, is that one needs to have a
> majority of libraries using it for the system to reap the benefits. I
> suspect that making Safe Haskell a featured part of the platform it will
> require significant library coordination. For this reason, if none other,
> I'd say that a plan to make Safe Haskell a prevalent part of the platform
> should target 2013.4.0.0, and start now.
>
> - Mark
>
>
> _______________________________________________
> Haskell-platform mailing list
> Haskell-platform at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
>