On 15 July 2012 14:53, Yitzchak Gale <g...@sefer.org> wrote:
> On Sun, Jul 15, 2012 at 7:03 AM, Mark Lentczner
> <mark.lentcz...@gmail.com> wrote:
>> ...I went back and looked
>> at Vector and now I see that there are large set of ".Safe" variants that
>> are no more than re-exports of the exact same functions from the non .Safe
>> versions of the modules with an extra safe haskell declaration added....
>> I think the state of affairs stinks. It will do nothing but confuse the heck
>> out of users
>
> Simon already pointed out that, in his opinion, the
> correct way to support SH would be:
>
>  - rename M to M.Internal (or suitable alternative)
>  - rename M.Safe to M
>  - add a (small) M.Unsafe where necessary
>
> But that would break backwards compatibility for the
> unsafe parts of the API. It's up to the package maintainers
> whether or not they want to do that. If not, I would say revert
> to no Safe Haskell support and accept it in the platform.
> However, add a haddock comment something like this:
>
> "Safe Haskell: If you do not use any functions in this
> module whose name contains the word 'unsafe', you
> can mark your module as 'Trustworthy'. Otherwise,
> please consult <Simon's SH paper>."

To be fair, regardless of SH, I'd consider it good API design to put
unsafe things into a separate module.  I'd be interested to know what
exactly the problem is with moving these functions into a separate
module.  If the only argument for not making this change is to avoid
breaking the API then we should do it *before* including vector into
the platform.

P.S.: I really wish we had a tool like "gofix" that automates trivial
API updates. That way simple API changes could be automated. There are
tools like this for Java and C, too.

_______________________________________________
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform

Reply via email to