On Mon, Oct 8, 2012 at 4:58 AM, Simon Marlow wrote:
> On 25/09/2012 15:29, Johan Tibell wrote:
>> * Using SafeHaskell in the platform in general, and in vector in
>> particular. This would be a large commitment for the platform, as we'd
>> implicitly be telling our users that we've deemed the pa
On 25/09/2012 15:29, Johan Tibell wrote:
Hi all,
After discussing this proposal at ICFP and with the Haskell Platform
committee, we've decided that there's a rough consensus for adding
vector to the platform.
We will leave the following open issue for the future:
* Using SafeHaskell in the p
Hi all,
After discussing this proposal at ICFP and with the Haskell Platform
committee, we've decided that there's a rough consensus for adding
vector to the platform.
We will leave the following open issue for the future:
* Using SafeHaskell in the platform in general, and in vector in
particu
On Wed, 25 Jul 2012, Bryan O'Sullivan wrote:
So. On the "pro" side, vector is already widely used and liked.
On the "con" side, there's the Safe Haskell question. Simon is quite reasonably
in favour of SH, and also
very reasonably not treating this question as a blocker. I'll admit to not
ha
On Fri, Jun 15, 2012 at 2:45 PM, Johan Tibell wrote:
> I am, with Roman's support, making a formal proposal to have the
> vector package included in the Haskell Platform:
>
We've had six weeks of intermittent discussions now, but I haven't seen
anything potentially dangerous to the proposal excep
Am 16.07.2012 01:41, schrieb Gábor Lehel:
On Wed, Jul 4, 2012 at 5:33 PM, Roman Leshchinskiy wrote:
[...] It still uses
"unsafe" to distinguish between functions that do bounds checking and
those that don't. What would be the benefit of moving functions like
unsafeIndex into a separate module (
Am 15.07.2012 17:11, schrieb Thomas Schilling:
On 15 July 2012 14:53, Yitzchak Gale wrote:
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 neces
On 17/07/12 10:28, Roman Leshchinskiy wrote:
Simon Marlow wrote:
The fact that you can't do arbitrary side effects in ST follows from the
definition of safety and the fact that runST injects ST computations
into pure computations. So there's really no design choice here. The
same applies to t
Simon Marlow wrote:
>
> The fact that you can't do arbitrary side effects in ST follows from the
> definition of safety and the fact that runST injects ST computations
> into pure computations. So there's really no design choice here. The
> same applies to the Par monad, and any monad that inject
On 16/07/2012 16:17, Roman Leshchinskiy wrote:
Simon Marlow wrote:
Ah ok, so your concern was that you couldn't easily find out whether
runST was safe or not? If you look at the library docs:
Whether runST is safe or not has a huge impact on what ST code I can
declare Trustworthy even if I d
Simon Marlow wrote:
>
> Ah ok, so your concern was that you couldn't easily find out whether
> runST was safe or not? If you look at the library docs:
Whether runST is safe or not has a huge impact on what ST code I can
declare Trustworthy even if I don't use runST at all. IMO, the fact that
ST c
On 16/07/2012 15:25, Roman Leshchinskiy wrote:
Simon Marlow wrote:
On 16/07/2012 13:55, Roman Leshchinskiy wrote:
Simon Marlow wrote:
Just to repeat what I said earlier, I don't see there being any
objection to putting unsafeRead with the other unsafe functions in
vector, even though technica
On Mon, Jul 16, 2012 at 3:58 PM, Simon Marlow wrote:
> On 16/07/2012 13:18, Gábor Lehel wrote:
>
>> With apologies for repeating myself, isn't the fact that unsafeRead
>> and unsafeWrite can access arbitrary memory locations a problem? Does
>> memory safety not matter?
>
>
> The definition of safe
Simon Marlow wrote:
> On 16/07/2012 13:55, Roman Leshchinskiy wrote:
>> Simon Marlow wrote:
>>>
>>> Just to repeat what I said earlier, I don't see there being any
>>> objection to putting unsafeRead with the other unsafe functions in
>>> vector, even though technically it is safe.
>>
>> Actually,
On 16/07/2012 13:18, Gábor Lehel wrote:
With apologies for repeating myself, isn't the fact that unsafeRead
and unsafeWrite can access arbitrary memory locations a problem? Does
memory safety not matter?
The definition of safety in Safe Haskell requires type safety, it does
not impose any ext
On 16/07/2012 13:55, Roman Leshchinskiy wrote:
Simon Marlow wrote:
Just to repeat what I said earlier, I don't see there being any
objection to putting unsafeRead with the other unsafe functions in
vector, even though technically it is safe.
Actually, this particular bit probably isn't a prob
Simon Marlow wrote:
>
> Just to repeat what I said earlier, I don't see there being any
> objection to putting unsafeRead with the other unsafe functions in
> vector, even though technically it is safe.
Actually, this particular bit probably isn't a problem. I actually
simplified the example sligh
On Mon, Jul 16, 2012 at 1:44 PM, Simon Marlow wrote:
> On 16/07/2012 11:01, Roman Leshchinskiy wrote:
>>
>> Thomas Schilling wrote:
>>>
>>> To be fair, regardless of SH, I'd consider it good API design to put
>>> unsafe things into a separate module.
>>
>>
>> I'll ask again: why is putting unsafe*
On 16/07/2012 11:01, Roman Leshchinskiy wrote:
Thomas Schilling wrote:
To be fair, regardless of SH, I'd consider it good API design to put
unsafe things into a separate module.
I'll ask again: why is putting unsafe* functions into a separate module
preferable to just following the unsafe* nam
Mark Lentczner wrote:
> If we don't, please, let's take these out of the package before
> committing it to the platform (where we have to make a commitment to the
> API).
I know I'm woefully uninformed about the platform requirements but this
caught my eye. What exactly is the commitment to the AP
Roman Leshchinskiy wrote:
> Simon,
>
> I'm still trying to figure out if there is a sane way to support Safe
> Haskell's module structure in vector. I'll post my thoughts later.
>From a technical point of view, I would have to write a tool which
autogenerates various modules in vector. This is som
Gábor Lehel wrote:
> On Wed, Jul 4, 2012 at 5:33 PM, Roman Leshchinskiy
> wrote:
>> [...] It still uses
>> "unsafe" to distinguish between functions that do bounds checking and
>> those that don't. What would be the benefit of moving functions like
>> unsafeIndex into a separate module (and would
Thomas Schilling wrote:
> To be fair, regardless of SH, I'd consider it good API design to put
> unsafe things into a separate module.
I'll ask again: why is putting unsafe* functions into a separate module
preferable to just following the unsafe* naming convention? I'm honestly
interested in an a
On Wed, Jul 4, 2012 at 5:33 PM, Roman Leshchinskiy wrote:
> [...] It still uses
> "unsafe" to distinguish between functions that do bounds checking and
> those that don't. What would be the benefit of moving functions like
> unsafeIndex into a separate module (and would it be called
> Unsafe.unsaf
On 15 July 2012 14:53, Yitzchak Gale wrote:
> On Sun, Jul 15, 2012 at 7:03 AM, Mark Lentczner
> 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
>> version
On Sun, Jul 15, 2012 at 7:03 AM, Mark Lentczner
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 declarati
On Sat, Jul 14, 2012 at 11:03 PM, Mark Lentczner
wrote:
> At the risk of throwing more wood on the fire here - 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
At the risk of throwing more wood on the fire here - 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. What
On Fri, Jul 13, 2012 at 11:10 AM, Roman Leshchinskiy
wrote:
> Is "inferred Safe" the same as being marked "Safe-Infered" on Hackage? It
> does say that for Data.Vector.Unboxed, for instance, but that module
> certainly contains unsafe functions.
>
I think this is a haddock bug: ghc gets the inf
Simon,
I'm still trying to figure out if there is a sane way to support Safe
Haskell's module structure in vector. I'll post my thoughts later. Here
are a couple of quick questions and observations, though.
Simon Marlow wrote:
> Myth #1 seems to be that Safe Haskell excludes large amounts of Hask
On Fri, Jul 13, 2012 at 10:21 AM, Simon Marlow wrote:
> We're still better off than before: currently you have to trust *all* the
> code, whereas with Safe Haskell you only have to trust the Trustworthy code.
>
> Furthermore, nobody is saying that you as a library maintainer or a user
> have to a
Posting this bit to the platform list only.
I vote to include vector in the platform now,
even if nothing at all is done yet to improve integration
with Safe Haskell. This is a very important package
and I commend the package authors and maintainers
on their fantastic work.
However, I would reque
On 13/07/2012 05:35, Gregory Collins wrote:
Hi Simon,
On Thu, Jul 12, 2012 at 10:43 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
Safe Haskell isn't about catching bugs. It's about making it
possible to program with stronger guarantees than we currently have.
...
Norm
Hi Simon,
On Thu, Jul 12, 2012 at 10:43 PM, Simon Marlow wrote:
> Safe Haskell isn't about catching bugs. It's about making it possible to
> program with stronger guarantees than we currently have.
...
Normally when you use an unsafe feature, the purpose is to use it to
> implement a safe
Hi Johan,
Thanks for replying. I think there are one or two slight misconceptions
about Safe Haskell - that's understandable, I think the documentation
could be improved, and the paper that explains it properly isn't
available yet (we only just finished the camera-ready copy, so it'll be
ava
On Wed, Jul 11, 2012 at 7:02 PM, Mark Lentczner wrote:
> Can we bring this back to the issue of adding vector, as it is today, to
> the Platform.
>
> For the record, I say "yes, add it".
>
Funny, I was about to send the same message and then found this.
So. I'd like to see vector as it stands no
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.
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 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 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 arguments below looks at SH
from the perspective of the average
On 05/07/2012 14:20, Roman Leshchinskiy wrote:
From the maintainance point of view, this would become easier if I had
*.Unsafe modules rather than the *.Safe ones. But this is a signficant
restructuring and the only reason to do it would be to support
SafeHaskell. Moreover, I believe (though I
Simon Marlow wrote:
> On 04/07/2012 16:33, Roman Leshchinskiy wrote:
>> Simon Marlow wrote:
>>> We should be moving towards safe APIs by default, and separating out
>>> unsafe APIs into separate modules.
>>
>> I completely agree with separating out unsafe APIs but I don't
>> understand
>> why modul
Simon Marlow wrote:
> On 18/06/2012 23:06, Roman Leshchinskiy wrote:
>> On 18/06/2012, at 19:39, Johan Tibell wrote:
>>
>>> On Mon, Jun 18, 2012 at 9:54 AM, Bas van Dijk
>>> wrote:
I like the idea of the vector-safe package. Are you also proposing to
add this package to the HP? (I would
On 04/07/2012 16:33, Roman Leshchinskiy wrote:
Simon Marlow wrote:
We should be moving towards safe APIs by default, and separating out
unsafe APIs into separate modules.
I completely agree with separating out unsafe APIs but I don't understand
why modules are the right granularity for this, e
On 18/06/2012 23:06, Roman Leshchinskiy wrote:
On 18/06/2012, at 19:39, Johan Tibell wrote:
On Mon, Jun 18, 2012 at 9:54 AM, Bas van Dijk wrote:
I like the idea of the vector-safe package. Are you also proposing to
add this package to the HP? (I would also be +1 on that)
I think it makes se
On Fri, Jun 15, 2012 at 5:45 PM, Johan Tibell wrote:
>
> I am, with Roman's support, making a formal proposal to have the
> vector package included in the Haskell Platform:
>
Very much in favour of this. Thanks for running the proposal!
___
Haskell-plat
On Tue, 19 Jun 2012, Roman Leshchinskiy wrote:
On 18/06/2012, at 23:16, Henning Thielemann wrote:
On Mon, 18 Jun 2012, Roman Leshchinskiy wrote:
There are type families, rank-n types, unboxed types and other goodies deep in
the guts of vector so the Storable part is very much GHC-specific.
| ForeignPtrs can be unpacked, just not manually (which is a GHC bug, IMO,
| I should report it):
Yes, do!
___
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
On Mon, Jun 18, 2012 at 4:09 PM, Roman Leshchinskiy
wrote:
> ForeignPtrs can be unpacked, just not manually (which is a GHC bug, IMO, I
> should report it):
>
> data Vector a = Vector {-# UNPACK #-} !Int
> {-# UNPACK #-} !(ForeignPtr a)
>
> ByteString just has some room for
On 19/06/2012, at 00:03, Johan Tibell wrote:
> On Mon, Jun 18, 2012 at 3:53 PM, Bas van Dijk wrote:
>> Slicing is done by directly updating the pointer in the ForeignPtr:
>>
>> {-# INLINE basicUnsafeSlice #-}
>> basicUnsafeSlice i n (Vector _ fp) =
>> Vector n (updPtr (`advancePtr` i) fp)
>>
On 18/06/2012, at 23:20, Henning Thielemann wrote:
>
> On Mon, 18 Jun 2012, Roman Leshchinskiy wrote:
>
>> VECTOR_BOUNDS_CHECKS is defined in vector.cabal as follows:
>>
>> if flag(BoundsChecks)
>> cpp-options: -DVECTOR_BOUNDS_CHECKS
>>
>> Doesn't Cabal provide access to the flags that a pac
On 18/06/2012, at 23:16, Henning Thielemann wrote:
> On Mon, 18 Jun 2012, Roman Leshchinskiy wrote:
>
>> There are type families, rank-n types, unboxed types and other goodies deep
>> in the guts of vector so the Storable part is very much GHC-specific. To be
>> honest, I don't think being port
On Mon, Jun 18, 2012 at 3:53 PM, Bas van Dijk wrote:
> Slicing is done by directly updating the pointer in the ForeignPtr:
>
> {-# INLINE basicUnsafeSlice #-}
> basicUnsafeSlice i n (Vector _ fp) =
> Vector n (updPtr (`advancePtr` i) fp)
>
> {-# INLINE updPtr #-}
> updPtr :: (Ptr a -> Ptr a) -
On Jun 19, 2012 12:16 AM, "Henning Thielemann" <
lemm...@henning-thielemann.de> wrote:
>
>
> On Mon, 18 Jun 2012, Roman Leshchinskiy wrote:
>
>> There are type families, rank-n types, unboxed types and other goodies
deep in the guts of vector so the Storable part is very much GHC-specific.
To be ho
On Mon, 18 Jun 2012, Roman Leshchinskiy wrote:
VECTOR_BOUNDS_CHECKS is defined in vector.cabal as follows:
if flag(BoundsChecks)
cpp-options: -DVECTOR_BOUNDS_CHECKS
Doesn't Cabal provide access to the flags that a package has been
compiled with?
Do you mean this way:
http://hackage.
On Mon, 18 Jun 2012, Roman Leshchinskiy wrote:
There are type families, rank-n types, unboxed types and other goodies
deep in the guts of vector so the Storable part is very much
GHC-specific. To be honest, I don't think being portable is feasible for
high-performance code at the moment, the
On 18/06/2012, at 19:39, Johan Tibell wrote:
> On Mon, Jun 18, 2012 at 9:54 AM, Bas van Dijk wrote:
>> I like the idea of the vector-safe package. Are you also proposing to
>> add this package to the HP? (I would also be +1 on that)
>
> I think it makes sense as a separate package, but I don't t
On 17/06/2012, at 12:14, Henning Thielemann wrote:
> On Fri, 15 Jun 2012, Johan Tibell wrote:
>
>> I am, with Roman's support, making a formal proposal to have the
>> vector package included in the Haskell Platform:
>>
>> http://trac.haskell.org/haskell-platform/wiki/Proposals/vector
>>
>> Se
On Mon, Jun 18, 2012 at 9:54 AM, Bas van Dijk wrote:
> I like the idea of the vector-safe package. Are you also proposing to
> add this package to the HP? (I would also be +1 on that)
I think it makes sense as a separate package, but I don't think it
makes sense to add to the HP. SafeHaskell isn'
On Sun, Jun 17, 2012 at 4:14 AM, Henning Thielemann
wrote:
> I thought about migrating storablevector to vector, but it seems that the
> vector package needs some GHC-only extensions like type families. I do not
> plan to make the storablevector package obsolete, but I think it would be
> useful i
On 15 June 2012 23:45, Johan Tibell wrote:
> Hi,
>
> I am, with Roman's support, making a formal proposal to have the
> vector package included in the Haskell Platform:
>
> http://trac.haskell.org/haskell-platform/wiki/Proposals/vector
>
> See the wiki page for details, and a list of open issue
On Fri, 15 Jun 2012, Johan Tibell wrote:
I am, with Roman's support, making a formal proposal to have the
vector package included in the Haskell Platform:
http://trac.haskell.org/haskell-platform/wiki/Proposals/vector
See the wiki page for details, and a list of open issues for discussion.
62 matches
Mail list logo
