From andrew.thaddeus at gmail.com Wed Dec 6 14:28:37 2017
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Wed, 6 Dec 2017 09:28:37 0500
Subject: Add foldMapM to Data.Foldable
MessageID:
Several coworkers and myself have independently reinvented this function
several times:
foldMapM :: (Foldable g, Monoid b, Monad m) => (a > m b) > g a > m b
foldMapM f xs = foldlM (\b a > mappend b <$> (f a)) mempty xs
I would like to propose that this be added to Data.Foldable. We have the
triplet foldr,foldl,foldMap in the Foldable typeclass itself, and
Data.Foldable provides foldrM and foldlM. It would be nice to provide
foldMapM for symmetry and because it seems to be useful in a variety of
applications.

Andrew Thaddeus Martin
 next part 
An HTML attachment was scrubbed...
URL:
From andreas.abel at ifi.lmu.de Wed Dec 6 23:04:02 2017
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Thu, 7 Dec 2017 00:04:02 +0100
Subject: Add foldMapM to Data.Foldable
InReplyTo:
References:
MessageID:
+1.
If I remember correctly, then Henning Thielemann has suggested this as
the proper generalization of mapM_.
On 06.12.2017 15:28, Andrew Martin wrote:
> Several coworkers and myself have independently reinvented this function
> several times:
>
> foldMapM :: (Foldable g, Monoid b, Monad m) => (a > m b) > g a > m b
> foldMapM f xs = foldlM (\b a > mappend b <$> (f a)) mempty xs
>
> I would like to propose that this be added to Data.Foldable. We have the
> triplet foldr,foldl,foldMap in the Foldable typeclass itself, and
> Data.Foldable provides foldrM and foldlM. It would be nice to provide
> foldMapM for symmetry and because it seems to be useful in a variety of
> applications.
>
> 
> Andrew Thaddeus Martin
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>

Andreas Abel <>< Du bist der geliebte Mensch.
Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden
andreas.abel at gu.se
http://www.cse.chalmers.se/~abela/
From david.feuer at gmail.com Wed Dec 6 23:11:07 2017
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 6 Dec 2017 18:11:07 0500
Subject: Add foldMapM to Data.Foldable
InReplyTo:
References:
MessageID:
It seems this lazilyaccumulating version should be Applicative, and a
strict version Monad. Do we also need a righttoleft version of each?
On Dec 6, 2017 9:29 AM, "Andrew Martin" wrote:
Several coworkers and myself have independently reinvented this function
several times:
foldMapM :: (Foldable g, Monoid b, Monad m) => (a > m b) > g a > m b
foldMapM f xs = foldlM (\b a > mappend b <$> (f a)) mempty xs
I would like to propose that this be added to Data.Foldable. We have the
triplet foldr,foldl,foldMap in the Foldable typeclass itself, and
Data.Foldable provides foldrM and foldlM. It would be nice to provide
foldMapM for symmetry and because it seems to be useful in a variety of
applications.

Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
Libraries at haskell.org
http://mail.haskell.org/cgibin/mailman/listinfo/libraries
 next part 
An HTML attachment was scrubbed...
URL:
From andrew.thaddeus at gmail.com Thu Dec 7 00:27:43 2017
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Wed, 6 Dec 2017 19:27:43 0500
Subject: Add foldMapM to Data.Foldable
InReplyTo:
References:
MessageID:
I had not considered that. I tried it out on a gist (
https://gist.github.com/andrewthad/25d1d443ec54412ae96cea3f40411e45), and
you're definitely right. I don't understand right monadic folds well enough
to write those out, but it would probably be worthwhile to both variants of
it as well. Here's the code from the gist:
{# LANGUAGE ScopedTypeVariables #}
module Folds where
import Control.Applicative
 Lazy in the monoidal accumulator.
foldlMapM :: forall g b a m. (Foldable g, Monoid b, Applicative m) => (a >
m b) > g a > m b
foldlMapM f = foldr f' (pure mempty)
where
f' :: a > m b > m b
f' x y = liftA2 mappend (f x) y
 Strict in the monoidal accumulator. For monads strict
 in the left argument of bind, this will run in constant
 space.
foldlMapM' :: forall g b a m. (Foldable g, Monoid b, Monad m) => (a > m b)
> g a > m b
foldlMapM' f xs = foldr f' pure xs mempty
where
f' :: a > (b > m b) > b > m b
f' x k bl = do
br < f x
let !b = mappend bl br
k b
On Wed, Dec 6, 2017 at 6:11 PM, David Feuer wrote:
> It seems this lazilyaccumulating version should be Applicative, and a
> strict version Monad. Do we also need a righttoleft version of each?
>
> On Dec 6, 2017 9:29 AM, "Andrew Martin" wrote:
>
> Several coworkers and myself have independently reinvented this function
> several times:
>
> foldMapM :: (Foldable g, Monoid b, Monad m) => (a > m b) > g a > m b
> foldMapM f xs = foldlM (\b a > mappend b <$> (f a)) mempty xs
>
> I would like to propose that this be added to Data.Foldable. We have the
> triplet foldr,foldl,foldMap in the Foldable typeclass itself, and
> Data.Foldable provides foldrM and foldlM. It would be nice to provide
> foldMapM for symmetry and because it seems to be useful in a variety of
> applications.
>
> 
> Andrew Thaddeus Martin
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>
>
>

Andrew Thaddeus Martin
 next part 
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Thu Dec 7 01:20:32 2017
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 6 Dec 2017 20:20:32 0500
Subject: Add foldMapM to Data.Foldable
InReplyTo:
References:
MessageID:
Actually, the most "natural" Applicative version is probably this:
newtype Ap f a = Ap {getAp :: f a}
instance (Applicative f, Monoid a) => Monoid (Ap f a) where
mempty = Ap $ pure mempty
mappend (Ap x) (Ap y) = Ap $ liftA2 mappend x y
foldMapA :: (Foldable t, Monoid m, Applicative f) => (a > f m) > t a > f m
foldMapA f = getAp . foldMap (Ap . f)
Of course, we can use some Data.Coerce magic to avoid silly eta
expansion, as usual.
The "right" way to perform the actions in the opposite order is probably just
foldMapA f . Reverse
and you can accumulate the other way using getDual . foldMapA (Dual . f)
So I think the whole Applicative side of this proposal might be seen as further
motivation for my longago stalled proposal to add Ap to Data.Monoid.
On Wed, Dec 6, 2017 at 7:27 PM, Andrew Martin wrote:
> I had not considered that. I tried it out on a gist
> (https://gist.github.com/andrewthad/25d1d443ec54412ae96cea3f40411e45), and
> you're definitely right. I don't understand right monadic folds well enough
> to write those out, but it would probably be worthwhile to both variants of
> it as well. Here's the code from the gist:
>
> {# LANGUAGE ScopedTypeVariables #}
>
> module Folds where
>
> import Control.Applicative
>
>  Lazy in the monoidal accumulator.
> foldlMapM :: forall g b a m. (Foldable g, Monoid b, Applicative m) => (a >
> m b) > g a > m b
> foldlMapM f = foldr f' (pure mempty)
> where
> f' :: a > m b > m b
> f' x y = liftA2 mappend (f x) y
>
>  Strict in the monoidal accumulator. For monads strict
>  in the left argument of bind, this will run in constant
>  space.
> foldlMapM' :: forall g b a m. (Foldable g, Monoid b, Monad m) => (a > m b)
> > g a > m b
> foldlMapM' f xs = foldr f' pure xs mempty
> where
> f' :: a > (b > m b) > b > m b
> f' x k bl = do
> br < f x
> let !b = mappend bl br
> k b
>
>
> On Wed, Dec 6, 2017 at 6:11 PM, David Feuer wrote:
>>
>> It seems this lazilyaccumulating version should be Applicative, and a
>> strict version Monad. Do we also need a righttoleft version of each?
>>
>> On Dec 6, 2017 9:29 AM, "Andrew Martin" wrote:
>>
>> Several coworkers and myself have independently reinvented this function
>> several times:
>>
>> foldMapM :: (Foldable g, Monoid b, Monad m) => (a > m b) > g a > m
>> b
>> foldMapM f xs = foldlM (\b a > mappend b <$> (f a)) mempty xs
>>
>> I would like to propose that this be added to Data.Foldable. We have the
>> triplet foldr,foldl,foldMap in the Foldable typeclass itself, and
>> Data.Foldable provides foldrM and foldlM. It would be nice to provide
>> foldMapM for symmetry and because it seems to be useful in a variety of
>> applications.
>>
>> 
>> Andrew Thaddeus Martin
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>>
>>
>
>
>
> 
> Andrew Thaddeus Martin
From david.feuer at gmail.com Thu Dec 7 04:15:44 2017
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 6 Dec 2017 23:15:44 0500
Subject: Add foldMapM to Data.Foldable
InReplyTo:
References:
MessageID:
Actually, the key modifiers are probably Dual and Backwards, with Reverse
combining them. Or something like that.
On Dec 6, 2017 8:20 PM, "David Feuer" wrote:
> Actually, the most "natural" Applicative version is probably this:
>
> newtype Ap f a = Ap {getAp :: f a}
> instance (Applicative f, Monoid a) => Monoid (Ap f a) where
> mempty = Ap $ pure mempty
> mappend (Ap x) (Ap y) = Ap $ liftA2 mappend x y
>
> foldMapA :: (Foldable t, Monoid m, Applicative f) => (a > f m) > t a >
> f m
> foldMapA f = getAp . foldMap (Ap . f)
>
> Of course, we can use some Data.Coerce magic to avoid silly eta
> expansion, as usual.
>
> The "right" way to perform the actions in the opposite order is probably
> just
>
> foldMapA f . Reverse
>
> and you can accumulate the other way using getDual . foldMapA (Dual . f)
>
> So I think the whole Applicative side of this proposal might be seen as
> further
> motivation for my longago stalled proposal to add Ap to Data.Monoid.
>
> On Wed, Dec 6, 2017 at 7:27 PM, Andrew Martin
> wrote:
> > I had not considered that. I tried it out on a gist
> > (https://gist.github.com/andrewthad/25d1d443ec54412ae96cea3f40411e45),
> and
> > you're definitely right. I don't understand right monadic folds well
> enough
> > to write those out, but it would probably be worthwhile to both variants
> of
> > it as well. Here's the code from the gist:
> >
> > {# LANGUAGE ScopedTypeVariables #}
> >
> > module Folds where
> >
> > import Control.Applicative
> >
> >  Lazy in the monoidal accumulator.
> > foldlMapM :: forall g b a m. (Foldable g, Monoid b, Applicative m) => (a
> >
> > m b) > g a > m b
> > foldlMapM f = foldr f' (pure mempty)
> > where
> > f' :: a > m b > m b
> > f' x y = liftA2 mappend (f x) y
> >
> >  Strict in the monoidal accumulator. For monads strict
> >  in the left argument of bind, this will run in constant
> >  space.
> > foldlMapM' :: forall g b a m. (Foldable g, Monoid b, Monad m) => (a > m
> b)
> > > g a > m b
> > foldlMapM' f xs = foldr f' pure xs mempty
> > where
> > f' :: a > (b > m b) > b > m b
> > f' x k bl = do
> > br < f x
> > let !b = mappend bl br
> > k b
> >
> >
> > On Wed, Dec 6, 2017 at 6:11 PM, David Feuer
> wrote:
> >>
> >> It seems this lazilyaccumulating version should be Applicative, and a
> >> strict version Monad. Do we also need a righttoleft version of each?
> >>
> >> On Dec 6, 2017 9:29 AM, "Andrew Martin"
> wrote:
> >>
> >> Several coworkers and myself have independently reinvented this function
> >> several times:
> >>
> >> foldMapM :: (Foldable g, Monoid b, Monad m) => (a > m b) > g a >
> m
> >> b
> >> foldMapM f xs = foldlM (\b a > mappend b <$> (f a)) mempty xs
> >>
> >> I would like to propose that this be added to Data.Foldable. We have the
> >> triplet foldr,foldl,foldMap in the Foldable typeclass itself, and
> >> Data.Foldable provides foldrM and foldlM. It would be nice to provide
> >> foldMapM for symmetry and because it seems to be useful in a variety of
> >> applications.
> >>
> >> 
> >> Andrew Thaddeus Martin
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
> >>
> >>
> >
> >
> >
> > 
> > Andrew Thaddeus Martin
>
 next part 
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Thu Dec 7 21:04:18 2017
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 7 Dec 2017 16:04:18 0500
Subject: Add foldMapM to Data.Foldable
InReplyTo:
References:
MessageID:
Indeed,
f g = g (\x > putStr x >> pure x) ["hi", "I'm", "Bob"]
f foldMapA = f $ \g > getAp . foldMap (Ap . g)
prints "hiI'mBob" and returns "hiI'mBob"
f (\g > forwards . foldMayO (Backwards . g))
= f (\g > forwards . getAp . foldMap (Ap . Backwards . g))
prints "BobI'mhi" and returns "hiI'mBob"
f (\g > fmap getDual . foldMapA (fmap Dual . g))
= f (\g > fmap getDual . foldMap (Ap . fmap Dual . g))
prints "hiI'mBob" and returns "BobI'mHi"
f (\g > foldMapA g . Reverse)
= f (\g > getAp . getDual . foldMap (Dual . Ap . g)
prints "BobI'mHi" and returns "BobI'mHi"
None of this affects the strict (monadic) versions, which should be defined in
terms of foldr and foldl. It's not entirely clear to me which way those monadic
versions should accumulate.
On Wed, Dec 6, 2017 at 11:15 PM, David Feuer wrote:
> Actually, the key modifiers are probably Dual and Backwards, with Reverse
> combining them. Or something like that.
>
> On Dec 6, 2017 8:20 PM, "David Feuer" wrote:
>>
>> Actually, the most "natural" Applicative version is probably this:
>>
>> newtype Ap f a = Ap {getAp :: f a}
>> instance (Applicative f, Monoid a) => Monoid (Ap f a) where
>> mempty = Ap $ pure mempty
>> mappend (Ap x) (Ap y) = Ap $ liftA2 mappend x y
>>
>> foldMapA :: (Foldable t, Monoid m, Applicative f) => (a > f m) > t a >
>> f m
>> foldMapA f = getAp . foldMap (Ap . f)
>>
>> Of course, we can use some Data.Coerce magic to avoid silly eta
>> expansion, as usual.
>>
>> The "right" way to perform the actions in the opposite order is probably
>> just
>>
>> foldMapA f . Reverse
>>
>> and you can accumulate the other way using getDual . foldMapA (Dual . f)
>>
>> So I think the whole Applicative side of this proposal might be seen as
>> further
>> motivation for my longago stalled proposal to add Ap to Data.Monoid.
>>
>> On Wed, Dec 6, 2017 at 7:27 PM, Andrew Martin
>> wrote:
>> > I had not considered that. I tried it out on a gist
>> > (https://gist.github.com/andrewthad/25d1d443ec54412ae96cea3f40411e45),
>> > and
>> > you're definitely right. I don't understand right monadic folds well
>> > enough
>> > to write those out, but it would probably be worthwhile to both variants
>> > of
>> > it as well. Here's the code from the gist:
>> >
>> > {# LANGUAGE ScopedTypeVariables #}
>> >
>> > module Folds where
>> >
>> > import Control.Applicative
>> >
>> >  Lazy in the monoidal accumulator.
>> > foldlMapM :: forall g b a m. (Foldable g, Monoid b, Applicative m) => (a
>> > >
>> > m b) > g a > m b
>> > foldlMapM f = foldr f' (pure mempty)
>> > where
>> > f' :: a > m b > m b
>> > f' x y = liftA2 mappend (f x) y
>> >
>> >  Strict in the monoidal accumulator. For monads strict
>> >  in the left argument of bind, this will run in constant
>> >  space.
>> > foldlMapM' :: forall g b a m. (Foldable g, Monoid b, Monad m) => (a > m
>> > b)
>> > > g a > m b
>> > foldlMapM' f xs = foldr f' pure xs mempty
>> > where
>> > f' :: a > (b > m b) > b > m b
>> > f' x k bl = do
>> > br < f x
>> > let !b = mappend bl br
>> > k b
>> >
>> >
>> > On Wed, Dec 6, 2017 at 6:11 PM, David Feuer
>> > wrote:
>> >>
>> >> It seems this lazilyaccumulating version should be Applicative, and a
>> >> strict version Monad. Do we also need a righttoleft version of each?
>> >>
>> >> On Dec 6, 2017 9:29 AM, "Andrew Martin"
>> >> wrote:
>> >>
>> >> Several coworkers and myself have independently reinvented this
>> >> function
>> >> several times:
>> >>
>> >> foldMapM :: (Foldable g, Monoid b, Monad m) => (a > m b) > g a >
>> >> m
>> >> b
>> >> foldMapM f xs = foldlM (\b a > mappend b <$> (f a)) mempty xs
>> >>
>> >> I would like to propose that this be added to Data.Foldable. We have
>> >> the
>> >> triplet foldr,foldl,foldMap in the Foldable typeclass itself, and
>> >> Data.Foldable provides foldrM and foldlM. It would be nice to provide
>> >> foldMapM for symmetry and because it seems to be useful in a variety of
>> >> applications.
>> >>
>> >> 
>> >> Andrew Thaddeus Martin
>> >>
>> >> _______________________________________________
>> >> Libraries mailing list
>> >> Libraries at haskell.org
>> >> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>> >>
>> >>
>> >
>> >
>> >
>> > 
>> > Andrew Thaddeus Martin
From m at tweag.io Sat Dec 9 15:10:16 2017
From: m at tweag.io (Boespflug, Mathieu)
Date: Sat, 9 Dec 2017 16:10:16 +0100
Subject: [Haskellcafe] Maintenance of streaming and streamingbytestring
InReplyTo:
References:
MessageID:
I'd like to contributed streamingbinary to the streaming GitHub org, if
you're up for it.
http://hackage.haskell.org/package/streamingbinary
Best,

Mathieu Boespflug
Founder at http://tweag.io.
On 17 September 2017 at 01:24, David Feuer wrote:
> Ah, right. Then yes, that sounds like a great approach.
>
> On Sep 15, 2017 1:23 PM, "Carter Schonwald"
> wrote:
>
>> GitHub has a transfer repo ownership toggle you can do to move the main
>> repo and it's assets
>>
>> On Fri, Sep 15, 2017 at 1:05 PM David Feuer
>> wrote:
>>
>>> Having an organization (with multiple owners and members) makes for much
>>> smoother transitions when maintainers change. That goes triple for
>>> unexpected changes. There's (still!) no really good way to migrate an issue
>>> tracker or PRs from one repository to another. Unfortunately, for that same
>>> reason, I believe that actually moving your project to the organization
>>> will be quite unpleasant if there are more than a few open tickets. And if
>>> there are more than a few closed tickets, then preserving history in a
>>> useful history seems hard too. Maybe someone else knows a reason this isn't
>>> actually terrible.
>>>
>>> David
>>>
>>> On Sep 14, 2017 1:10 AM, "Ivan Lazar Miljenovic" <
>>> ivan.miljenovic at gmail.com> wrote:
>>>
>>> Since you've seem to set this up as an organisation, would you be
>>> interested in my moving over the various streaming libraries I have
>>> there as well?
>>>
>>> On 14 September 2017 at 03:31, Andrew Martin
>>> wrote:
>>> > The streaming and streamingbytestring libraries are now being
>>> maintained
>>> > here: https://github.com/haskellstreaming
>>> >
>>> > On Tue, Sep 12, 2017 at 4:50 PM, Andrew Martin <
>>> andrew.thaddeus at gmail.com>
>>> > wrote:
>>> >>
>>> >> Thanks adding me as a maintainer. I'm new to this process, so I
>>> appreciate
>>> >> the tip about admin at hackage.haskell.org as well.
>>> >>
>>> >> Andrew Martin
>>> >>
>>> >> On Tue, Sep 12, 2017 at 3:57 PM, Erik Hesselink
>>> >> wrote:
>>> >>>
>>> >>> Hi Andrew,
>>> >>>
>>> >>> We usually allow about 3 weeks for the maintainer to respond. Since
>>> that
>>> >>> time has now passed I've added you as a maintainer for streaming and
>>> >>> streamingbytestring. Let me know if there's anything else you need.
>>> >>>
>>> >>> For others looking to take over a package in the future, please CC
>>> >>> admin at hackage.haskell.org, there's a higher chance I'll see it
>>> there than
>>> >>> just on the email lists.
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> Erik (hackage admin)
>>> >>>
>>> >>> On 12 September 2017 at 20:18, Andrew Martin <
>>> andrew.thaddeus at gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> Are there any further steps that I can take?
>>> >>>>
>>> >>>> On Thu, Sep 7, 2017 at 11:07 AM, Andrew Martin
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> David Feuer brought this up two weeks ago [0]. The maintainer of
>>> >>>>> streaming and streamingbytestring has been unreachable, and
>>> provided his
>>> >>>>> continued absence, I would like to become a maintainer of these two
>>> >>>>> libraries. I have put up PRs fixing issues [1] and I've offered on
>>> the issue
>>> >>>>> tracker to become a comaintainer [2]. I use this library a lot at
>>> work, so I
>>> >>>>> have an interest in keeping it in good shape.
>>> >>>>>
>>> >>>>> [0]
>>> >>>>> https://mail.haskell.org/pipermail/libraries/2017August/
>>> 028141.html
>>> >>>>> [1] https://github.com/michaelt/streamingbytestring/pull/11
>>> >>>>> [2] https://github.com/michaelt/streamingbytestring/issues/19
>>> >>>>>
>>> >>>>> 
>>> >>>>> Andrew Thaddeus Martin
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> 
>>> >>>> Andrew Thaddeus Martin
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Libraries mailing list
>>> >>>> Libraries at haskell.org
>>> >>>> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>>> >>>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> 
>>> >> Andrew Thaddeus Martin
>>> >
>>> >
>>> >
>>> >
>>> > 
>>> > Andrew Thaddeus Martin
>>> >
>>> > _______________________________________________
>>> > HaskellCafe mailing list
>>> > To (un)subscribe, modify options or view archives go to:
>>> > http://mail.haskell.org/cgibin/mailman/listinfo/haskellcafe
>>> > Only members subscribed via the mailman list are allowed to post.
>>>
>>>
>>>
>>> 
>>> Ivan Lazar Miljenovic
>>> Ivan.Miljenovic at gmail.com
>>> http://IvanMiljenovic.wordpress.com
>>> _______________________________________________
>>> HaskellCafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgibin/mailman/listinfo/haskellcafe
>>> Only members subscribed via the mailman list are allowed to post.
>>>
>>>
>>> _______________________________________________
>>> HaskellCafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgibin/mailman/listinfo/haskellcafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>
>
 next part 
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Mon Dec 11 13:04:50 2017
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 11 Dec 2017 08:04:50 0500
Subject: [Haskellcafe] Maintenance of streaming and streamingbytestring
InReplyTo:
References:
MessageID:
I've added you as a member of haskellstreaming. Feel free to transfer the repo.
On Sat, Dec 9, 2017 at 10:10 AM, Boespflug, Mathieu wrote:
> I'd like to contributed streamingbinary to the streaming GitHub org, if
> you're up for it.
>
> http://hackage.haskell.org/package/streamingbinary
>
> Best,
>
> 
> Mathieu Boespflug
> Founder at http://tweag.io.
>
> On 17 September 2017 at 01:24, David Feuer wrote:
>>
>> Ah, right. Then yes, that sounds like a great approach.
>>
>> On Sep 15, 2017 1:23 PM, "Carter Schonwald"
>> wrote:
>>>
>>> GitHub has a transfer repo ownership toggle you can do to move the main
>>> repo and it's assets
>>>
>>> On Fri, Sep 15, 2017 at 1:05 PM David Feuer
>>> wrote:
>>>>
>>>> Having an organization (with multiple owners and members) makes for much
>>>> smoother transitions when maintainers change. That goes triple for
>>>> unexpected changes. There's (still!) no really good way to migrate an issue
>>>> tracker or PRs from one repository to another. Unfortunately, for that same
>>>> reason, I believe that actually moving your project to the organization will
>>>> be quite unpleasant if there are more than a few open tickets. And if there
>>>> are more than a few closed tickets, then preserving history in a useful
>>>> history seems hard too. Maybe someone else knows a reason this isn't
>>>> actually terrible.
>>>>
>>>> David
>>>>
>>>> On Sep 14, 2017 1:10 AM, "Ivan Lazar Miljenovic"
>>>> wrote:
>>>>
>>>> Since you've seem to set this up as an organisation, would you be
>>>> interested in my moving over the various streaming libraries I have
>>>> there as well?
>>>>
>>>> On 14 September 2017 at 03:31, Andrew Martin
>>>> wrote:
>>>> > The streaming and streamingbytestring libraries are now being
>>>> > maintained
>>>> > here: https://github.com/haskellstreaming
>>>> >
>>>> > On Tue, Sep 12, 2017 at 4:50 PM, Andrew Martin
>>>> >
>>>> > wrote:
>>>> >>
>>>> >> Thanks adding me as a maintainer. I'm new to this process, so I
>>>> >> appreciate
>>>> >> the tip about admin at hackage.haskell.org as well.
>>>> >>
>>>> >> Andrew Martin
>>>> >>
>>>> >> On Tue, Sep 12, 2017 at 3:57 PM, Erik Hesselink
>>>> >> wrote:
>>>> >>>
>>>> >>> Hi Andrew,
>>>> >>>
>>>> >>> We usually allow about 3 weeks for the maintainer to respond. Since
>>>> >>> that
>>>> >>> time has now passed I've added you as a maintainer for streaming and
>>>> >>> streamingbytestring. Let me know if there's anything else you need.
>>>> >>>
>>>> >>> For others looking to take over a package in the future, please CC
>>>> >>> admin at hackage.haskell.org, there's a higher chance I'll see it there
>>>> >>> than
>>>> >>> just on the email lists.
>>>> >>>
>>>> >>> Regards,
>>>> >>>
>>>> >>> Erik (hackage admin)
>>>> >>>
>>>> >>> On 12 September 2017 at 20:18, Andrew Martin
>>>> >>>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> Are there any further steps that I can take?
>>>> >>>>
>>>> >>>> On Thu, Sep 7, 2017 at 11:07 AM, Andrew Martin
>>>> >>>> wrote:
>>>> >>>>>
>>>> >>>>> David Feuer brought this up two weeks ago [0]. The maintainer of
>>>> >>>>> streaming and streamingbytestring has been unreachable, and
>>>> >>>>> provided his
>>>> >>>>> continued absence, I would like to become a maintainer of these
>>>> >>>>> two
>>>> >>>>> libraries. I have put up PRs fixing issues [1] and I've offered on
>>>> >>>>> the issue
>>>> >>>>> tracker to become a comaintainer [2]. I use this library a lot at
>>>> >>>>> work, so I
>>>> >>>>> have an interest in keeping it in good shape.
>>>> >>>>>
>>>> >>>>> [0]
>>>> >>>>>
>>>> >>>>> https://mail.haskell.org/pipermail/libraries/2017August/028141.html
>>>> >>>>> [1] https://github.com/michaelt/streamingbytestring/pull/11
>>>> >>>>> [2] https://github.com/michaelt/streamingbytestring/issues/19
>>>> >>>>>
>>>> >>>>> 
>>>> >>>>> Andrew Thaddeus Martin
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> 
>>>> >>>> Andrew Thaddeus Martin
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> Libraries mailing list
>>>> >>>> Libraries at haskell.org
>>>> >>>> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>>>> >>>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> 
>>>> >> Andrew Thaddeus Martin
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > 
>>>> > Andrew Thaddeus Martin
>>>> >
>>>> > _______________________________________________
>>>> > HaskellCafe mailing list
>>>> > To (un)subscribe, modify options or view archives go to:
>>>> > http://mail.haskell.org/cgibin/mailman/listinfo/haskellcafe
>>>> > Only members subscribed via the mailman list are allowed to post.
>>>>
>>>>
>>>>
>>>> 
>>>> Ivan Lazar Miljenovic
>>>> Ivan.Miljenovic at gmail.com
>>>> http://IvanMiljenovic.wordpress.com
>>>> _______________________________________________
>>>> HaskellCafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgibin/mailman/listinfo/haskellcafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>>>
>>>>
>>>> _______________________________________________
>>>> HaskellCafe mailing list
>>>> To (un)subscribe, modify options or view archives go to:
>>>> http://mail.haskell.org/cgibin/mailman/listinfo/haskellcafe
>>>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>>
>
From strake888 at gmail.com Thu Dec 14 03:48:10 2017
From: strake888 at gmail.com (M FarkasDyck)
Date: Wed, 13 Dec 2017 19:48:10 0800
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
MessageID: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
I propose to add the following methods to `Bits` and `FiniteBits` classes:
class Bits a where
...
bitSizeMaybe' :: Proxy a > Maybe Int
class FiniteBits b where
...
finiteBitSize' :: Proxy b > Int
Rationale: working with an arbitrary `Bits a => a`, one may not have a value of type `a` as argument to `bitSizeMaybe` or `finiteBitSize`, and writing `undefined` makes me feel dirty.
From strake888 at gmail.com Thu Dec 14 04:11:03 2017
From: strake888 at gmail.com (M FarkasDyck)
Date: Wed, 13 Dec 2017 20:11:03 0800
Subject: Proposal: `Enum` class overhaul
MessageID:
I propose to add some new methods of `Enum`:
class Enum a where
...
predMay, succMay :: a > Maybe a
toEnum' :: Integer > Maybe a
fromEnum' a > Integer
Rationale for `fromEnum'` and `toEnum'`:
The docs for `Enum` now say the minimal complete definition is `toEnum` and `fromEnum`, but this is not enough to have sane default instances of the other methods, for example:
data ABC = A  B  C deriving Show
instance Enum ABC where
toEnum 0 = A
toEnum 1 = B
toEnum 2 = C
fromEnum A = 0
fromEnum B = 1
fromEnum C = 2
main = print [A ..]  [A,B,C,*** Exception: Nonexhaustive patterns in function toEnum
In this case one could merely derive `Enum`, but not in some other cases, e.g. numeric types or GADTs. It is not possible to do better defining `toEnum` and `fromEnum` alone.
If we defaultdefine `toEnum'` and `fromEnum'` and their evil (i.e. partial) syblings in terms of each other, the user need merely define the total methods.
Using `Integer` rather than `Int` allows these methods to not fail for types larger than an `Int`, which are not uncommon on 32bit systems.
Rationale for `predMay` and `succMay`:
I include these partly for completeness, but `predMay` can not now be defined in general, and `succMay` only cumbersomely in terms of `enumFrom`.
Note: All rationales imply "unless one uses `unsafePerformIO`". I'd rather not, myself.
From david.feuer at gmail.com Thu Dec 14 04:19:47 2017
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 13 Dec 2017 23:19:47 0500
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
MessageID:
+1, but we should also do this for sizeOf and alignment in Foreign.Storable.
On Dec 13, 2017 10:53 PM, "M FarkasDyck" wrote:
> I propose to add the following methods to `Bits` and `FiniteBits` classes:
>
> class Bits a where
> ...
>
> bitSizeMaybe' :: Proxy a > Maybe Int
>
> class FiniteBits b where
> ...
>
> finiteBitSize' :: Proxy b > Int
>
> Rationale: working with an arbitrary `Bits a => a`, one may not have a
> value of type `a` as argument to `bitSizeMaybe` or `finiteBitSize`, and
> writing `undefined` makes me feel dirty.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>
 next part 
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Thu Dec 14 04:22:04 2017
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 13 Dec 2017 23:22:04 0500
Subject: Proposal: `Enum` class overhaul
InReplyTo:
References:
MessageID:
I'm moderately opposed, on the basis that the Enum class is too
fundamentally broken/meaningless to be worth fiddling with. It attempts to
serve multiple barelyrelated purposes at once, and serves none of them
terribly well.
On Dec 13, 2017 11:17 PM, "M FarkasDyck" wrote:
> I propose to add some new methods of `Enum`:
>
> class Enum a where
> ...
>
> predMay, succMay :: a > Maybe a
> toEnum' :: Integer > Maybe a
> fromEnum' a > Integer
>
> Rationale for `fromEnum'` and `toEnum'`:
>
> The docs for `Enum` now say the minimal complete definition is `toEnum`
> and `fromEnum`, but this is not enough to have sane default instances of
> the other methods, for example:
>
> data ABC = A  B  C deriving Show
> instance Enum ABC where
> toEnum 0 = A
> toEnum 1 = B
> toEnum 2 = C
> fromEnum A = 0
> fromEnum B = 1
> fromEnum C = 2
>
> main = print [A ..]  [A,B,C,*** Exception: Nonexhaustive patterns in
> function toEnum
>
> In this case one could merely derive `Enum`, but not in some other cases,
> e.g. numeric types or GADTs. It is not possible to do better defining
> `toEnum` and `fromEnum` alone.
>
> If we defaultdefine `toEnum'` and `fromEnum'` and their evil (i.e.
> partial) syblings in terms of each other, the user need merely define the
> total methods.
>
> Using `Integer` rather than `Int` allows these methods to not fail for
> types larger than an `Int`, which are not uncommon on 32bit systems.
>
> Rationale for `predMay` and `succMay`:
>
> I include these partly for completeness, but `predMay` can not now be
> defined in general, and `succMay` only cumbersomely in terms of `enumFrom`.
>
> Note: All rationales imply "unless one uses `unsafePerformIO`". I'd rather
> not, myself.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>
 next part 
An HTML attachment was scrubbed...
URL:
From strake888 at gmail.com Thu Dec 14 04:41:47 2017
From: strake888 at gmail.com (M FarkasDyck)
Date: Wed, 13 Dec 2017 20:41:47 0800
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo:
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
MessageID: <364f4c4f1912b8c0ce0a2c81c1050b9b@gmail.com>
On 20171213 08:19 PM, David Feuer wrote:
> +1, but we should also do this for sizeOf and alignment in Foreign.Storable.
Yes, good idea
From strake888 at gmail.com Thu Dec 14 04:46:21 2017
From: strake888 at gmail.com (M FarkasDyck)
Date: Wed, 13 Dec 2017 20:46:21 0800
Subject: Proposal: `Enum` class overhaul
InReplyTo:
References:
MessageID: <33363a0ebc177d0a9722592312f96a96@gmail.com>
On 20171213 08:22 PM, David Feuer wrote:
> I'm moderately opposed, on the basis that the Enum class is too fundamentally broken/meaningless to be worth fiddling with. It attempts to serve multiple barelyrelated purposes at once, and serves none of them terribly well.
I agree it's bad, but `..` syntax is defined in terms of it, and trying to introduce breaking modifications into base is like trying to introduce my head into a brick wall.
From zemyla at gmail.com Thu Dec 14 05:37:47 2017
From: zemyla at gmail.com (Zemyla)
Date: Wed, 13 Dec 2017 23:37:47 0600
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo: <364f4c4f1912b8c0ce0a2c81c1050b9b@gmail.com>
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
<364f4c4f1912b8c0ce0a2c81c1050b9b@gmail.com>
MessageID:
I honestly think we should make it a Const Int a, instead of a
function, so that it's a number in the typeclass dictionary and not a
function.
On Wed, Dec 13, 2017 at 10:41 PM, M FarkasDyck wrote:
> On 20171213 08:19 PM, David Feuer wrote:
>>
>> +1, but we should also do this for sizeOf and alignment in
>> Foreign.Storable.
>
>
> Yes, good idea
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
From tikhon at jelv.is Thu Dec 14 05:41:22 2017
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Wed, 13 Dec 2017 21:41:22 0800
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo:
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
<364f4c4f1912b8c0ce0a2c81c1050b9b@gmail.com>
MessageID:
The Const type does not see much direct use in other common Haskell
packages. (I only ever encounter it through lens.) So while that might be
an elegant design, I think it will make the API more confusing for
newcomers.
On Dec 13, 2017 9:38 PM, "Zemyla" wrote:
> I honestly think we should make it a Const Int a, instead of a
> function, so that it's a number in the typeclass dictionary and not a
> function.
>
> On Wed, Dec 13, 2017 at 10:41 PM, M FarkasDyck
> wrote:
> > On 20171213 08:19 PM, David Feuer wrote:
> >>
> >> +1, but we should also do this for sizeOf and alignment in
> >> Foreign.Storable.
> >
> >
> > Yes, good idea
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgibin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>
 next part 
An HTML attachment was scrubbed...
URL:
From strake888 at gmail.com Thu Dec 14 07:09:00 2017
From: strake888 at gmail.com (M FarkasDyck)
Date: Wed, 13 Dec 2017 23:09:00 0800
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo:
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
<364f4c4f1912b8c0ce0a2c81c1050b9b@gmail.com>
MessageID:
On 20171213 09:37 PM, Zemyla wrote:
> I honestly think we should make it a Const Int a, instead of a
> function, so that it's a number in the typeclass dictionary and not a
> function.
I like that idea!
On 20171213 09:41 PM, Tikhon Jelvis wrote:
> The Const type does not see much direct use in other common Haskell packages. (I only ever encounter it through lens.) So while that might be an elegant design, I think it will make the API more confusing for newcomers.
I doubt whether it's much more confusing than `Proxy`, and would be more efficient in cases where the typeclass dictionary can't be inline. Anyhow, if we began using it in base it would thus gain exposure; it's selffulfilling either way.
From lemming at henningthielemann.de Thu Dec 14 08:36:57 2017
From: lemming at henningthielemann.de (Henning Thielemann)
Date: Thu, 14 Dec 2017 09:36:57 +0100 (CET)
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo:
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
MessageID:
On Wed, 13 Dec 2017, David Feuer wrote:
> +1, but we should also do this for sizeOf and alignment in Foreign.Storable.
That was my intended reply ...
From lemming at henningthielemann.de Thu Dec 14 08:38:46 2017
From: lemming at henningthielemann.de (Henning Thielemann)
Date: Thu, 14 Dec 2017 09:38:46 +0100 (CET)
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo:
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
<364f4c4f1912b8c0ce0a2c81c1050b9b@gmail.com>
MessageID:
On Wed, 13 Dec 2017, Zemyla wrote:
> I honestly think we should make it a Const Int a, instead of a function,
> so that it's a number in the typeclass dictionary and not a function.
Even better.
From lemming at henningthielemann.de Thu Dec 14 08:43:57 2017
From: lemming at henningthielemann.de (Henning Thielemann)
Date: Thu, 14 Dec 2017 09:43:57 +0100 (CET)
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
MessageID:
On Wed, 13 Dec 2017, M FarkasDyck wrote:
> I propose to add the following methods to `Bits` and `FiniteBits` classes:
>
> class Bits a where
> ...
>
> bitSizeMaybe' :: Proxy a > Maybe Int
>
> class FiniteBits b where
> ...
>
> finiteBitSize' :: Proxy b > Int
Alternative suggestion for names (I frequently overlook the primes):
bitSizeMaybeConst :: Const (Maybe Int) a
finiteBitSizeConst :: Const Int a
sizeOfConst :: Const Int a
alignmentConst :: Const Int a
Then we must add mutual default implementations in order to preserve
existing instances.
From simonpj at microsoft.com Thu Dec 14 10:12:03 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 14 Dec 2017 10:12:03 +0000
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
MessageID:
Now that we have visible type application, we could stop using these Proxy arguments, thus
class Bits a where
...
bitSizeMaybe' :: Maybe Int
And you invoke it by saying
bitSizeMaybe @ T
rather than
bitSizeMaybe (Proxy :: Proxy T)
Looks like a straight win to me.
Simon
 Original Message
 From: Libraries [mailto:librariesbounces at haskell.org] On Behalf Of M
 FarkasDyck
 Sent: 14 December 2017 03:48
 To: libraries at haskell.org
 Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
 `finiteBitSize`

 I propose to add the following methods to `Bits` and `FiniteBits`
 classes:

 class Bits a where
 ...

 bitSizeMaybe' :: Proxy a > Maybe Int

 class FiniteBits b where
 ...

 finiteBitSize' :: Proxy b > Int

 Rationale: working with an arbitrary `Bits a => a`, one may not have a
 value of type `a` as argument to `bitSizeMaybe` or `finiteBitSize`,
 and writing `undefined` makes me feel dirty.
 _______________________________________________
 Libraries mailing list
 Libraries at haskell.org
 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
 askell.org%2Fcgi
 bin%2Fmailman%2Flistinfo%2Flibraries&data=04%7C01%7Csimonpj%40microsof
 t.com%7Cd88222263d04465efcf608d542a6473f%7C72f988bf86f141af91ab2d7cd01
 1db47%7C1%7C0%7C636488204282827644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
 wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C
 1&sdata=GUcUpHRarbB8uky4m%2Fve1l3ZbtPnDIndzPM9FG5Jj44%3D&reserved=0
From andrew.thaddeus at gmail.com Thu Dec 14 12:16:08 2017
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Thu, 14 Dec 2017 07:16:08 0500
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo:
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
<364f4c4f1912b8c0ce0a2c81c1050b9b@gmail.com>
MessageID:
Alternatively, we could have it be `Proxy# a > Int`, which should have
identical performance characteristics to `Const Int a` but with the added
benefit that it's a little easier to understand how it's supposed to be
used.
On Thu, Dec 14, 2017 at 12:37 AM, Zemyla wrote:
> I honestly think we should make it a Const Int a, instead of a
> function, so that it's a number in the typeclass dictionary and not a
> function.
>
> On Wed, Dec 13, 2017 at 10:41 PM, M FarkasDyck
> wrote:
> > On 20171213 08:19 PM, David Feuer wrote:
> >>
> >> +1, but we should also do this for sizeOf and alignment in
> >> Foreign.Storable.
> >
> >
> > Yes, good idea
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgibin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>

Andrew Thaddeus Martin
 next part 
An HTML attachment was scrubbed...
URL:
From ryan.gl.scott at gmail.com Thu Dec 14 13:15:02 2017
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Thu, 14 Dec 2017 08:15:02 0500
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
MessageID:
I don't have a particular opinion on this proposal, but I did want to
chime in to note that there are several other functions in base
besides biteSizeMaybe, finiteBitSize, sizeOf, and alignment that take
a dummy argument. The last time I checked, all of these functions also
fit the bill [1]:
* Data.Bits.isSigned :: Bits a => a > Bool
* Data.Data.dataTypeOf :: Data a => a > DataType
* GHC.Generics.datatypeName :: Datatype d => t d f a > String
* GHC.Generics.moduleName :: Datatype d => t d f a > String
* GHC.Generics.isNewtype :: Datatype d => t d f a > Bool
* GHC.Generics.packageName :: Datatype d => t d f a > String
* GHC.Generics.conName :: Constructor c => t c f a > String
* GHC.Generics.conFixity :: Constructor c => t c f a > Fixity
* GHC.Generics.conIsRecord :: Constructor c => t c f a > Bool
* GHC.Generics.selName :: Selector s => t s f a > String
* GHC.Generics.selSourceUnpackedness :: Selector s => t s f a >
SourceUnpackedness
* GHC.Generics.selSourceStrictness :: Selector s => t s f a > SourceStrictness
* GHC.Generics.selDecidedStrictness :: Selector s => t s f a >
DecidedStrictness
* Prelude.floatRadix :: RealFloat => a > Integer
* Prelude.floatDigits :: RealFloat => a > (Int, Int)
* Text.Printf :: PrintfArg a => a > ModifierParser
Ryan S.

[1] This list was taken from
http://hackage.haskell.org/package/proxied0.3/docs/DataProxied.html
From lemming at henningthielemann.de Thu Dec 14 13:46:52 2017
From: lemming at henningthielemann.de (Henning Thielemann)
Date: Thu, 14 Dec 2017 14:46:52 +0100 (CET)
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo:
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
MessageID:
On Thu, 14 Dec 2017, Simon Peyton Jones via Libraries wrote:
> Now that we have visible type application, we could stop using these Proxy arguments, thus
>
> class Bits a where
> ...
> bitSizeMaybe' :: Maybe Int
>
> And you invoke it by saying
> bitSizeMaybe @ T
> rather than
> bitSizeMaybe (Proxy :: Proxy T)
>
> Looks like a straight win to me.
I was not aware of this type extension, but I still prefer Haskell 98 /
2010.
From strake888 at gmail.com Thu Dec 14 20:11:19 2017
From: strake888 at gmail.com (M FarkasDyck)
Date: Thu, 14 Dec 2017 12:11:19 0800
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo:
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
MessageID: <623ce7204bdac04609cdf8c1144e1425@gmail.com>
On 20171214 05:46 AM, Henning Thielemann wrote:
> I still prefer Haskell 98 / 2010.
I agree. I would hesitate to introduce ambiguous types here.
From ekmett at gmail.com Fri Dec 15 14:08:22 2017
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 15 Dec 2017 09:08:22 0500
Subject: Proposal: add `Proxy`fied versions of `bitSizeMaybe` and
`finiteBitSize`
InReplyTo: <623ce7204bdac04609cdf8c1144e1425@gmail.com>
References: <12c91ea82dde90e7276ab71046d8dab5@gmail.com>
<623ce7204bdac04609cdf8c1144e1425@gmail.com>
MessageID:
This was my kneejerk reaction as well, but interestingly, you only
actually need to turn on AllowAmbiguousTypes to compile the class. You can
actually _use_ the methods without the extension. This matters to me
because AllowAmbiguousTypes allows far too many errors through in user code.
This renders it a somewhat less bad option than I previously assumed and
leaves me somewhat ambivalent about whether we use the extension or not.
On Thu, Dec 14, 2017 at 3:11 PM, M FarkasDyck wrote:
> On 20171214 05:46 AM, Henning Thielemann wrote:
>
>> I still prefer Haskell 98 / 2010.
>>
>
> I agree. I would hesitate to introduce ambiguous types here.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>
 next part 
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Sat Dec 16 03:22:18 2017
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 15 Dec 2017 22:22:18 0500
Subject: Discussion: Storable instances for tuples
InReplyTo:
References:
MessageID:
It seems surprising that there are no Storable instances for tuple types. I
would expect any tuple of Storable types to be Storable. To provide a
sensible FFI experience, the order of the fields should be preserved. Since
Storable generally aligns values, I believe elements should be aligned
within tuples as well, in the default fashion used for C structs. We could
offer a Packed newtype to override this behavior.
Why store tuples like this, and not the way Data.Vector.Unboxed does? A
moment's reflection will show that it simply can't. A Ptr is a single
pointer and must remain one; there's no room in it to deal with multiple
arrays or extra offset info.
 next part 
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Sat Dec 16 05:33:36 2017
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 16 Dec 2017 00:33:36 0500
Subject: Storable laws
InReplyTo:
References:
MessageID:
The documentation for pokeByteOff indicates that the following equality
holds:
pokeElemOff addr idx x =
poke (addr `plusPtr` (idx * sizeOf x)) x
Notably, this ignores alignment. It thus seems to imply that sizeOf must
always be a multiple of alignment; otherwise, nonzero indices could access
nonaligned addresses.
Was this intentional? If so, I believe sizeOf and alignment should document
the law. If not, then I believe the {poke,peek}ElemOff laws need to change
to something like
pokeElemOff addr idx x =
poke (addr `plusPtr` (idx * lcm (sizeOf x) (alignment x))) x
 next part 
An HTML attachment was scrubbed...
URL:
From mgsloan at gmail.com Sat Dec 16 05:59:37 2017
From: mgsloan at gmail.com (Michael Sloan)
Date: Fri, 15 Dec 2017 21:59:37 0800
Subject: Storable laws
InReplyTo:
References:
MessageID:
I realize that these libraries are used on many architectures.
However, on modern x86 machines, that are less than ~7 years old, it
doesn't seem to matter all that much.
https://lemire.me/blog/2012/05/31/dataalignmentforspeedmythorreality/
In the comments, looks like somewhat older processors take a 40%
performance hit, which isn't good, but it isn't awful.
IIRC, of the processors that are actually used, there are two where
access alignment really matters  ARM and PowerPC. If you're running
linux I believe it will handle the exception and do the unaligned
access. However, of course it's really slow to do this.
I'm not sure if it makes sense to change the law. Someone might be
relying on the behavior of instances that do not fulfill this law.
Perhaps in those cases it makes sense to just remove the instance.
Michael
On Fri, Dec 15, 2017 at 9:33 PM, David Feuer wrote:
> The documentation for pokeByteOff indicates that the following equality
> holds:
>
> pokeElemOff addr idx x =
> poke (addr `plusPtr` (idx * sizeOf x)) x
>
> Notably, this ignores alignment. It thus seems to imply that sizeOf must
> always be a multiple of alignment; otherwise, nonzero indices could access
> nonaligned addresses.
>
> Was this intentional? If so, I believe sizeOf and alignment should document
> the law. If not, then I believe the {poke,peek}ElemOff laws need to change
> to something like
>
> pokeElemOff addr idx x =
> poke (addr `plusPtr` (idx * lcm (sizeOf x) (alignment x))) x
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/libraries
>
From lemming at henningthielemann.de Sat Dec 16 07:49:51 2017
From: lemming at henningthielemann.de (Henning Thielemann)
Date: Sat, 16 Dec 2017 08:49:51 +0100 (CET)
Subject: Discussion: Storable instances for tuples
InReplyTo:
References:
MessageID:
On Fri, 15 Dec 2017, David Feuer wrote:
> It seems surprising that there are no Storable instances for tuple types. I would expect any tuple of Storable
> types to be Storable. To provide a sensible FFI experience, the order of the fields should be preserved. Since
> Storable generally aligns values, I believe elements should be aligned within tuples as well, in the default
> fashion used for C structs. We could offer a Packed newtype to override this behavior.
I had the same suggestion when we discussed instance Storable (). Sven
Panne answered:
http://mail.haskell.org/pipermail/libraries/2015June/025903.html
From lemming at henningthielemann.de Sat Dec 16 07:53:52 2017
From: lemming at henningthielemann.de (Henning Thielemann)
Date: Sat, 16 Dec 2017 08:53:52 +0100 (CET)
Subject: Storable laws
InReplyTo:
References:
MessageID:
On Fri, 15 Dec 2017, Michael Sloan wrote:
> I'm not sure if it makes sense to change the law. Someone might be
> relying on the behavior of instances that do not fulfill this law.
> Perhaps in those cases it makes sense to just remove the instance.
Storable is intended for data exchange with code written in other
languages. Thus we must use the same alignment rules as the system ABI.
From svenpanne at gmail.com Sat Dec 16 13:33:05 2017
From: svenpanne at gmail.com (Sven Panne)
Date: Sat, 16 Dec 2017 14:33:05 +0100
Subject: Storable laws
InReplyTo:
References:
MessageID:
20171216 6:33 GMT+01:00 David Feuer :
> The documentation for pokeByteOff indicates that the following equality
> holds:
>
> pokeElemOff addr idx x =
> poke (addr `plusPtr` (idx * sizeOf x)) x
>
> [...] Was this intentional?
>
Yep, that was intentional, think of pokeElemOff as indexing into an array.
Note that the FFI intentionally does not specify how to (un)marshal
structs, only basic types and arrays of them. Doing anything else would be
a) languagespecific and b) platformABIspecific. Storable is just meant
as a basic building block to do such more involved things.
> If so, I believe sizeOf and alignment should document the law. [...]
>
Perhaps, but what exactly do you feel is missing there?
 next part 
An HTML attachment was scrubbed...
URL:
From svenpanne at gmail.com Sat Dec 16 14:06:53 2017
From: svenpanne at gmail.com (Sven Panne)
Date: Sat, 16 Dec 2017 15:06:53 +0100
Subject: Storable laws
InReplyTo:
References: