On 10 July 2012 22:58, Johan Tibell wrote:
> Hi Simon,
>
> Sorry for the late reply, I was on vacation.
>
> Let me preface my response below by saying that I think SafeHaskell
> (SH) is an interesting and worthwhile research project and this isn't
> meant as a diss of SH as whole. Also, my argumen
Hi Bas,
On Wed, Jul 11, 2012 at 10:54 AM, Bas van Dijk wrote:
> I don't think the goal of using SH in base was to catch bugs in base.
> I think the goal was to mark which parts of base are safe and, most
> importantly, which parts are unsafe.
But what is the goal then? Simon suggested that SH is
On Wed, 11 Jul 2012, Johan Tibell wrote:
Trustworthy obviously doesn't mean no-bugs. It just means that the
module author claims that the API of the module can't be used to
violate certain guarantees. Whether you trust his claim and how to
establish this trust is up to you. For some application
On 11 July 2012 20:49, Henning Thielemann wrote:
> I think the idea was to have Unsafe modules and move the unsafe functions
> there. :-)
Indeed. I don't see the point about having .Safe modules. Modules
should be safe by default as you mentioned before. I guess the reason
we have .Safe modules i
On Wed, Jul 11, 2012 at 11:49 AM, Henning Thielemann
wrote:
> I think the difference is that currently we have to know the set of unsafe
> functions like unsafePerformIO and search for them in an imported package.
> This work is now done by the compiler which tells me if there is something
> suspi
On Wed, Jul 11, 2012 at 2:11 PM, Bas van Dijk wrote:
> On 11 July 2012 20:49, Henning Thielemann
> wrote:
>> I think the idea was to have Unsafe modules and move the unsafe functions
>> there. :-)
>
> Indeed. I don't see the point about having .Safe modules. Modules
> should be safe by default a
On Wed, 11 Jul 2012, Bas van Dijk wrote:
The ideal, but currently, impossible way of dealing with this is to
mark the _export_ of unsafe functions in a module as DEPRECATED and in
a later version remove the unsafe functions and mark the module as
Trustworthy. However this requires support for d
On 11 July 2012 23:45, Johan Tibell wrote:
> On Wed, Jul 11, 2012 at 2:11 PM, Bas van Dijk wrote:
>> On 11 July 2012 20:49, Henning Thielemann
>> wrote:
>>> I think the idea was to have Unsafe modules and move the unsafe functions
>>> there. :-)
>>
>> Indeed. I don't see the point about having
On 11 July 2012 23:46, Henning Thielemann wrote:
>
> On Wed, 11 Jul 2012, Bas van Dijk wrote:
>
>> The ideal, but currently, impossible way of dealing with this is to
>> mark the _export_ of unsafe functions in a module as DEPRECATED and in
>> a later version remove the unsafe functions and mark t
On Wed, Jul 11, 2012 at 3:08 PM, Bas van Dijk wrote:
>> But why? The number of people who will benefit from this mass
>> deprecation/mass migration is tiny.
>
> While I agree that the number of people who will benefit is tiny I
> don't think it's a "mass" deprecation. In base there are only 7
> fu
On Wed, Jul 11, 2012 at 7:27 PM, Johan Tibell wrote:
> For example, most functions in bytestring are unsafe because their
> implementation uses unsafePerformIO. To be very concrete, if 'map' on
> ByteStrings is unsafe it needs to be moved from
>
While I share your distrust of the whole Safe Haske
Stepping back a bit -
This thread seems like a poor place to discuss the objectives and merits of
Safe Haskell.
It is also a poor place to discuss Safe Haskell in the context of Haskell
Platform. That is a good discussion we should have, so let's start a new
thread for that... See my next post.
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
On Wed, Jul 11, 2012 at 4:38 PM, Brandon Allbery wrote:
> unsafePerformIO is unsafe.
>
> Data.ByteString.map is only unsafe if it allows unsafePerformIO to be
> abused.
>
> If it can verify that nothing actually unsafe takes place — which it does,
> by dint of the promise inherent in it being expo
14 matches
Mail list logo
