From lsp at informatik.uni-kiel.de  Thu Sep  1 08:53:09 2016
From: lsp at informatik.uni-kiel.de (lennart spitzner)
Date: Thu, 1 Sep 2016 10:53:09 +0200
Subject: Proposal: Add <&> to Data.Functor
In-Reply-To: <CAMgWh9t1oQRs73=QxzC6Mve1xx=WMgJNFOoC+rgN1Wfcw=Ps_A@mail.gmail.com>
References: <CAMgWh9v_v4c35QoO1VueQHvvWv7_nx9vrGnhRaYbwvf+BgOgMA@mail.gmail.com>
 <CAMgWh9uDK-aZGdKMK7ak-Om0zh-6YEs4wmd9TtL6k2RPa-oPLg@mail.gmail.com>
 <CAMgWh9vRViWXu-naOhdaakJUnP+uWxHba3Z9E7G72CD-A3Y=Fg@mail.gmail.com>
 <CAMgWh9vYbO_52SpwbyC7-9DA69P7GTyHUB7cREs8Mh_Lw-Ps3g@mail.gmail.com>
 <CAMgWh9t1oQRs73=QxzC6Mve1xx=WMgJNFOoC+rgN1Wfcw=Ps_A@mail.gmail.com>
Message-ID: <11c7a6bf-2493-74f8-6630-4a28c81b6523@informatik.uni-kiel.de>

> infixl 1
I assume? (lens and some other libs agree on this fixity already.)

(also, +1)

On 21/08/16 19:23, David Feuer wrote:
> The <&> operator is rather popular:
> 
> (<&>) :: Functor f => f a -> (a -> b) -> f b
> (<&>) = flip fmap
> 
> Now that we have (&) in Data.Function, I think we should have (<&>) in
> Data.Functor.
> 
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> 


From ekmett at gmail.com  Thu Sep  1 10:53:05 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 1 Sep 2016 06:53:05 -0400
Subject: Proposal: Add <&> to Data.Functor
In-Reply-To: <11c7a6bf-2493-74f8-6630-4a28c81b6523@informatik.uni-kiel.de>
References: <CAMgWh9v_v4c35QoO1VueQHvvWv7_nx9vrGnhRaYbwvf+BgOgMA@mail.gmail.com>
 <CAMgWh9uDK-aZGdKMK7ak-Om0zh-6YEs4wmd9TtL6k2RPa-oPLg@mail.gmail.com>
 <CAMgWh9vRViWXu-naOhdaakJUnP+uWxHba3Z9E7G72CD-A3Y=Fg@mail.gmail.com>
 <CAMgWh9vYbO_52SpwbyC7-9DA69P7GTyHUB7cREs8Mh_Lw-Ps3g@mail.gmail.com>
 <CAMgWh9t1oQRs73=QxzC6Mve1xx=WMgJNFOoC+rgN1Wfcw=Ps_A@mail.gmail.com>
 <11c7a6bf-2493-74f8-6630-4a28c81b6523@informatik.uni-kiel.de>
Message-ID: <CAJumaK8q6DOYxOZKK7NxCpedaBQYu=4H4By_AXt2G3QqSVXDSg@mail.gmail.com>

I'd presume we'd keep the current fixity. It plays much nicer when mixed
with >>= and the like, and it doesn't mix with the <$> <*> crowd despite
appearances anyways even if you give it the "obvious" fixity.

-Edward

On Thu, Sep 1, 2016 at 4:53 AM, lennart spitzner <lsp at informatik.uni-kiel.de
> wrote:

> > infixl 1
> I assume? (lens and some other libs agree on this fixity already.)
>
> (also, +1)
>
> On 21/08/16 19:23, David Feuer wrote:
> > The <&> operator is rather popular:
> >
> > (<&>) :: Functor f => f a -> (a -> b) -> f b
> > (<&>) = flip fmap
> >
> > Now that we have (&) in Data.Function, I think we should have (<&>) in
> > Data.Functor.
> >
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160901/e4a5d535/attachment.html>

From david.feuer at gmail.com  Thu Sep  1 17:32:50 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 1 Sep 2016 13:32:50 -0400
Subject: Discussion: name for reversing fromList in Data.Sequence
In-Reply-To: <CAMgWh9uBUbuh51Sz7KETrCmi2XgO-U7mp7OrZS4FW1B0xqCjKA@mail.gmail.com>
References: <CAMgWh9sBZhwVxc4Bzgwfv05V_SuwMTMh=Acc1a709jqLYOQTYA@mail.gmail.com>
 <CAMgWh9tFLovCv8TDxM2fAz7xKPHCBkYw61+rLsHtdUvDhUE0Qw@mail.gmail.com>
 <CAMgWh9vZWB==4VGAONSf+TG=r_tOcRS8h_=rXHp7BM3WwROv4A@mail.gmail.com>
 <CAMgWh9uBUbuh51Sz7KETrCmi2XgO-U7mp7OrZS4FW1B0xqCjKA@mail.gmail.com>
Message-ID: <CAMgWh9ubztCU4BYK_Fa1gBjBw-JkD92rXXeiNQawkH=5y1TKKA@mail.gmail.com>

I'd like to add a function

fromListReversing :: [a] -> Seq a

to Data.Sequence, with

fromListReversing
  = reverse . fromList
  = fromList . reverse

I don't know just what to call this function, however.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160901/17022d46/attachment.html>

From johnw at newartisans.com  Thu Sep  1 19:51:06 2016
From: johnw at newartisans.com (John Wiegley)
Date: Thu, 01 Sep 2016 12:51:06 -0700
Subject: Discussion: name for reversing fromList in Data.Sequence
In-Reply-To: <CAMgWh9ubztCU4BYK_Fa1gBjBw-JkD92rXXeiNQawkH=5y1TKKA@mail.gmail.com>
 (David Feuer's message of "Thu, 1 Sep 2016 13:32:50 -0400")
References: <CAMgWh9sBZhwVxc4Bzgwfv05V_SuwMTMh=Acc1a709jqLYOQTYA@mail.gmail.com>
 <CAMgWh9tFLovCv8TDxM2fAz7xKPHCBkYw61+rLsHtdUvDhUE0Qw@mail.gmail.com>
 <CAMgWh9vZWB==4VGAONSf+TG=r_tOcRS8h_=rXHp7BM3WwROv4A@mail.gmail.com>
 <CAMgWh9uBUbuh51Sz7KETrCmi2XgO-U7mp7OrZS4FW1B0xqCjKA@mail.gmail.com>
 <CAMgWh9ubztCU4BYK_Fa1gBjBw-JkD92rXXeiNQawkH=5y1TKKA@mail.gmail.com>
Message-ID: <m2vayfe6vp.fsf@newartisans.com>

>>>>> "DF" == David Feuer <david.feuer at gmail.com> writes:

FD> I'd like to add a function
DF> fromListReversing :: [a] -> Seq a

Hi David,

Perhaps rather than proliferating the libraries with fused compositions that
are faster than their composites via (.), we could defer things like this to
REWRITE rules.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

From david.feuer at gmail.com  Thu Sep  1 19:57:19 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 1 Sep 2016 15:57:19 -0400
Subject: Discussion: name for reversing fromList in Data.Sequence
In-Reply-To: <CAMgWh9veR4WaHGDdWmBEbneinTRjb6+jBrJy-v0b2BJaWrjvBA@mail.gmail.com>
References: <CAMgWh9sBZhwVxc4Bzgwfv05V_SuwMTMh=Acc1a709jqLYOQTYA@mail.gmail.com>
 <CAMgWh9tFLovCv8TDxM2fAz7xKPHCBkYw61+rLsHtdUvDhUE0Qw@mail.gmail.com>
 <CAMgWh9vZWB==4VGAONSf+TG=r_tOcRS8h_=rXHp7BM3WwROv4A@mail.gmail.com>
 <CAMgWh9uBUbuh51Sz7KETrCmi2XgO-U7mp7OrZS4FW1B0xqCjKA@mail.gmail.com>
 <CAMgWh9ubztCU4BYK_Fa1gBjBw-JkD92rXXeiNQawkH=5y1TKKA@mail.gmail.com>
 <m2vayfe6vp.fsf@newartisans.com>
 <CAMgWh9uMLMWMMsZUda5DY9q3kQ7iAxkKd4U9WUy6r+N08e9pdQ@mail.gmail.com>
 <CAMgWh9veR4WaHGDdWmBEbneinTRjb6+jBrJy-v0b2BJaWrjvBA@mail.gmail.com>
Message-ID: <CAMgWh9scQAEKFKxr37Kv7JQaGmbw2QbCzEEWjc9ORatfMBtjTQ@mail.gmail.com>

My concern is for what happens when such rules don't fire. If someone
converts a large list to a sequence only to reverse it, then the
badly-ordered sequence will end up being evacuated by the garbage collector
unnecessarily, pushing up the next major collection.

In contrast, I've used rewrite rules to fuse map with reverse; the worst
case there is some extra churn in the nursery.

That said, if others don't consider it important enough, or have enough
faith that rules will fire in this case (which may very well be), I can go
the rules route.

On Sep 1, 2016 3:51 PM, "John Wiegley" <johnw at newartisans.com> wrote:

>>>>> "DF" == David Feuer <david.feuer at gmail.com> writes:

FD> I'd like to add a function
DF> fromListReversing :: [a] -> Seq a

Hi David,

Perhaps rather than proliferating the libraries with fused compositions that
are faster than their composites via (.), we could defer things like this to
REWRITE rules.

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160901/b739cf81/attachment.html>

From david.feuer at gmail.com  Thu Sep  1 19:59:42 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 1 Sep 2016 15:59:42 -0400
Subject: Discussion: name for reversing fromList in Data.Sequence
In-Reply-To: <CAMgWh9scQAEKFKxr37Kv7JQaGmbw2QbCzEEWjc9ORatfMBtjTQ@mail.gmail.com>
References: <CAMgWh9sBZhwVxc4Bzgwfv05V_SuwMTMh=Acc1a709jqLYOQTYA@mail.gmail.com>
 <CAMgWh9tFLovCv8TDxM2fAz7xKPHCBkYw61+rLsHtdUvDhUE0Qw@mail.gmail.com>
 <CAMgWh9vZWB==4VGAONSf+TG=r_tOcRS8h_=rXHp7BM3WwROv4A@mail.gmail.com>
 <CAMgWh9uBUbuh51Sz7KETrCmi2XgO-U7mp7OrZS4FW1B0xqCjKA@mail.gmail.com>
 <CAMgWh9ubztCU4BYK_Fa1gBjBw-JkD92rXXeiNQawkH=5y1TKKA@mail.gmail.com>
 <m2vayfe6vp.fsf@newartisans.com>
 <CAMgWh9uMLMWMMsZUda5DY9q3kQ7iAxkKd4U9WUy6r+N08e9pdQ@mail.gmail.com>
 <CAMgWh9veR4WaHGDdWmBEbneinTRjb6+jBrJy-v0b2BJaWrjvBA@mail.gmail.com>
 <CAMgWh9scQAEKFKxr37Kv7JQaGmbw2QbCzEEWjc9ORatfMBtjTQ@mail.gmail.com>
Message-ID: <CAMgWh9tFambAauoXtwq5Lnfy=LNMxSU3Bj86BVehwLkho-E=3g@mail.gmail.com>

FYI, this isn't one I feel super-strongly about, and I'm not particularly
keen on *writing* the function, so if people don't want it I'll back off
pronto.

On Sep 1, 2016 3:57 PM, "David Feuer" <david.feuer at gmail.com> wrote:

> My concern is for what happens when such rules don't fire. If someone
> converts a large list to a sequence only to reverse it, then the
> badly-ordered sequence will end up being evacuated by the garbage collector
> unnecessarily, pushing up the next major collection.
>
> In contrast, I've used rewrite rules to fuse map with reverse; the worst
> case there is some extra churn in the nursery.
>
> That said, if others don't consider it important enough, or have enough
> faith that rules will fire in this case (which may very well be), I can go
> the rules route.
>
> On Sep 1, 2016 3:51 PM, "John Wiegley" <johnw at newartisans.com> wrote:
>
> >>>>> "DF" == David Feuer <david.feuer at gmail.com> writes:
>
> FD> I'd like to add a function
> DF> fromListReversing :: [a] -> Seq a
>
> Hi David,
>
> Perhaps rather than proliferating the libraries with fused compositions
> that
> are faster than their composites via (.), we could defer things like this
> to
> REWRITE rules.
>
> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160901/d388d426/attachment.html>

From david.feuer at gmail.com  Fri Sep  2 18:59:52 2016
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 2 Sep 2016 14:59:52 -0400
Subject: Modules for new map merge functions may be renamed
In-Reply-To: <CAMgWh9sn3v3jw7_XxUc7CFDfHR99okMt0WL2csa71nnYDC1=Gw@mail.gmail.com>
References: <CAMgWh9sn3v3jw7_XxUc7CFDfHR99okMt0WL2csa71nnYDC1=Gw@mail.gmail.com>
Message-ID: <CAMgWh9vdpb3bnWN4m9HXkPfeJ0R=DzwUwu1C=rtLUfnexL3gFg@mail.gmail.com>

We hope to make one more, fairly small, major release for containers for
inclusion in GHC 8.2. I am considering renaming the new modules
Data.Map.Merge.Lazy and Data.Map.Merge.Strict instead of
Data.Map.Strict.Merge and Data.Map.Lazy.Merge. That seems more consistent
with the module scheme for the rest of the package, and leaves open the
option of adding extra merge-related modules in the future. I'm sorry about
the potential wobble, but I think taking care of this now will lead to much
less trouble than waiting till later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160902/bf31b143/attachment.html>

From wren at community.haskell.org  Mon Sep  5 18:56:26 2016
From: wren at community.haskell.org (wren romano)
Date: Mon, 5 Sep 2016 11:56:26 -0700
Subject: Discussion: name for reversing fromList in Data.Sequence
In-Reply-To: <m2vayfe6vp.fsf@newartisans.com>
References: <CAMgWh9sBZhwVxc4Bzgwfv05V_SuwMTMh=Acc1a709jqLYOQTYA@mail.gmail.com>
 <CAMgWh9tFLovCv8TDxM2fAz7xKPHCBkYw61+rLsHtdUvDhUE0Qw@mail.gmail.com>
 <CAMgWh9vZWB==4VGAONSf+TG=r_tOcRS8h_=rXHp7BM3WwROv4A@mail.gmail.com>
 <CAMgWh9uBUbuh51Sz7KETrCmi2XgO-U7mp7OrZS4FW1B0xqCjKA@mail.gmail.com>
 <CAMgWh9ubztCU4BYK_Fa1gBjBw-JkD92rXXeiNQawkH=5y1TKKA@mail.gmail.com>
 <m2vayfe6vp.fsf@newartisans.com>
Message-ID: <CABUjdS51XtUMhTOYUfENz5JGdiLxAXg6ViK8YyBosTt3DduhwQ@mail.gmail.com>

On Thu, Sep 1, 2016 at 12:51 PM, John Wiegley <johnw at newartisans.com> wrote:
>>>>>> "DF" == David Feuer <david.feuer at gmail.com> writes:
> DF> I'd like to add a function
> DF> fromListReversing :: [a] -> Seq a
>
> Hi David,
>
> Perhaps rather than proliferating the libraries with fused compositions that
> are faster than their composites via (.), we could defer things like this to
> REWRITE rules.

Supposing we do have the rewrite rules, what exactly are we going to
rewrite them *to*? the fused function still needs a name... And, as
David mentions, there's the fragility problem: so even if users by and
large rely on the rewrite rules, it's still nice to be able to
directly invoke the fused version if desired. Usually for this sort of
thing I like to define the fused function, perhaps only exported from
an Foo.Internal module, and then use rules to rewrite things into the
fused form.

-- 
Live well,
~wren

From matthewtpickering at gmail.com  Sun Sep 11 10:25:48 2016
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Sun, 11 Sep 2016 11:25:48 +0100
Subject: Generalise type of deleteBy
Message-ID: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>

The type of `deleteBy` in `Data.List` could easily be generalised in a
useful way.

```
deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a]
```

to

```
deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b]
```

There is this closed ticket but no reasons for not generalising.

https://ghc.haskell.org/trac/ghc/ticket/3399

Discussion Period: 1 week.

Matt

From michael at snoyman.com  Sun Sep 11 10:28:57 2016
From: michael at snoyman.com (Michael Snoyman)
Date: Sun, 11 Sep 2016 13:28:57 +0300
Subject: Generalise type of deleteBy
In-Reply-To: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
Message-ID: <CAKA2JgLoVFqaS49W7sAv6TO3y=t=SPyS6hkLFiqBFw7gTp=3Rg@mail.gmail.com>

On Sun, Sep 11, 2016 at 1:25 PM, Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> The type of `deleteBy` in `Data.List` could easily be generalised in a
> useful way.
>
> ```
> deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a]
> ```
>
> to
>
> ```
> deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b]
> ```
>
> There is this closed ticket but no reasons for not generalising.
>
> https://ghc.haskell.org/trac/ghc/ticket/3399
>
> Discussion Period: 1 week.
>
> Matt
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

+1, seems straightforward. My only concern: does anyone have real life
examples of code where this generalization would lead to type inference
problems? I can't think of anything offhand.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160911/60105947/attachment.html>

From ekmett at gmail.com  Sun Sep 11 12:33:33 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 11 Sep 2016 08:33:33 -0400
Subject: Generalise type of deleteBy
In-Reply-To: <CAKA2JgLoVFqaS49W7sAv6TO3y=t=SPyS6hkLFiqBFw7gTp=3Rg@mail.gmail.com>
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
 <CAKA2JgLoVFqaS49W7sAv6TO3y=t=SPyS6hkLFiqBFw7gTp=3Rg@mail.gmail.com>
Message-ID: <CAJumaK_wmBNYVE6X+H8ui6c_RMVR=fjoeXvUyg6YKFLA0ZsRLA@mail.gmail.com>

I have no objection.

+1

-Edward

On Sun, Sep 11, 2016 at 6:28 AM, Michael Snoyman <michael at snoyman.com>
wrote:

>
> On Sun, Sep 11, 2016 at 1:25 PM, Matthew Pickering <
> matthewtpickering at gmail.com> wrote:
>
>> The type of `deleteBy` in `Data.List` could easily be generalised in a
>> useful way.
>>
>> ```
>> deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a]
>> ```
>>
>> to
>>
>> ```
>> deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b]
>> ```
>>
>> There is this closed ticket but no reasons for not generalising.
>>
>> https://ghc.haskell.org/trac/ghc/ticket/3399
>>
>> Discussion Period: 1 week.
>>
>> Matt
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
> +1, seems straightforward. My only concern: does anyone have real life
> examples of code where this generalization would lead to type inference
> problems? I can't think of anything offhand.
>
> Michael
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160911/d6c5e931/attachment.html>

From matthewtpickering at gmail.com  Sun Sep 11 12:59:59 2016
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Sun, 11 Sep 2016 13:59:59 +0100
Subject: Generalise type of deleteBy
In-Reply-To: <CAJumaK_wmBNYVE6X+H8ui6c_RMVR=fjoeXvUyg6YKFLA0ZsRLA@mail.gmail.com>
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
 <CAKA2JgLoVFqaS49W7sAv6TO3y=t=SPyS6hkLFiqBFw7gTp=3Rg@mail.gmail.com>
 <CAJumaK_wmBNYVE6X+H8ui6c_RMVR=fjoeXvUyg6YKFLA0ZsRLA@mail.gmail.com>
Message-ID: <CALuQ0m8z_7ufwh=evwYdeGz_fRWe1L54KUEVuMieM7m7D_Sbmw@mail.gmail.com>

I put a patch up on phab with the suggested changes. It also seemed
sensible to generalise deleteFirstsBy.

https://phabricator.haskell.org/D2526

Matt



On Sun, Sep 11, 2016 at 1:33 PM, Edward Kmett <ekmett at gmail.com> wrote:
> I have no objection.
>
> +1
>
> -Edward
>
> On Sun, Sep 11, 2016 at 6:28 AM, Michael Snoyman <michael at snoyman.com>
> wrote:
>>
>>
>> On Sun, Sep 11, 2016 at 1:25 PM, Matthew Pickering
>> <matthewtpickering at gmail.com> wrote:
>>>
>>> The type of `deleteBy` in `Data.List` could easily be generalised in a
>>> useful way.
>>>
>>> ```
>>> deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a]
>>> ```
>>>
>>> to
>>>
>>> ```
>>> deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b]
>>> ```
>>>
>>> There is this closed ticket but no reasons for not generalising.
>>>
>>> https://ghc.haskell.org/trac/ghc/ticket/3399
>>>
>>> Discussion Period: 1 week.
>>>
>>> Matt
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>> +1, seems straightforward. My only concern: does anyone have real life
>> examples of code where this generalization would lead to type inference
>> problems? I can't think of anything offhand.
>>
>> Michael
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>

From lemming at henning-thielemann.de  Sun Sep 11 16:19:23 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 11 Sep 2016 18:19:23 +0200 (CEST)
Subject: Generalise type of deleteBy
In-Reply-To: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1609111815420.15457@sputnik>


On Sun, 11 Sep 2016, Matthew Pickering wrote:

> The type of `deleteBy` in `Data.List` could easily be generalised in a
> useful way.
>
> ```
> deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a]
> ```

I do not see why deleteBy should have an argument for the deleted element, 
anyway, since it is not even the element to delete (only an equivalent 
one). Wouldn't a function with type

newDeleteBy :: (a -> Bool) -> [a] -> [a]

be much more straight-forward?

From emertens at gmail.com  Sun Sep 11 17:00:40 2016
From: emertens at gmail.com (Eric Mertens)
Date: Sun, 11 Sep 2016 17:00:40 +0000
Subject: Generalise type of deleteBy
In-Reply-To: <alpine.DEB.2.02.1609111815420.15457@sputnik>
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
 <alpine.DEB.2.02.1609111815420.15457@sputnik>
Message-ID: <CALya0903vy=DEQiMMu1gEAr=DGsR4DiUD3BuxbLmkvGavf_eYQ@mail.gmail.com>

Going with Henning's newDeleteBy would provide a better interface to
deleting with an arbitrary predicate, and it would avoid the (unlikely?)
chance of code breaking in the event that the more general type breaks some
type inference.

On Sun, Sep 11, 2016, 9:19 AM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Sun, 11 Sep 2016, Matthew Pickering wrote:
>
> > The type of `deleteBy` in `Data.List` could easily be generalised in a
> > useful way.
> >
> > ```
> > deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a]
> > ```
>
> I do not see why deleteBy should have an argument for the deleted element,
> anyway, since it is not even the element to delete (only an equivalent
> one). Wouldn't a function with type
>
> newDeleteBy :: (a -> Bool) -> [a] -> [a]
>
> be much more straight-forward?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160911/018e0b0c/attachment.html>

From ekmett at gmail.com  Sun Sep 11 19:15:27 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 11 Sep 2016 15:15:27 -0400
Subject: Generalise type of deleteBy
In-Reply-To: <CALya0903vy=DEQiMMu1gEAr=DGsR4DiUD3BuxbLmkvGavf_eYQ@mail.gmail.com>
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
 <alpine.DEB.2.02.1609111815420.15457@sputnik>
 <CALya0903vy=DEQiMMu1gEAr=DGsR4DiUD3BuxbLmkvGavf_eYQ@mail.gmail.com>
Message-ID: <CAJumaK-7Hd+h8zufOBCg5MFzgxVsWDXFuzGL1JV=9=yBcQDRSg@mail.gmail.com>

I have to admit I've always found the need to pass an argument to deleteBy
sort of silly. The few times I've used it, my function has just ignored the
first argument. I don't think we need to worry too much about inference in
this case, the user would almost assuredly pick it back up on the backswing
from whatever (a -> a -> Bool) predicate they are using fixing the type
anyways.

I don't find the two proposals mutually exclusive.

-Edward

On Sun, Sep 11, 2016 at 1:00 PM, Eric Mertens <emertens at gmail.com> wrote:

> Going with Henning's newDeleteBy would provide a better interface to
> deleting with an arbitrary predicate, and it would avoid the (unlikely?)
> chance of code breaking in the event that the more general type breaks some
> type inference.
>
> On Sun, Sep 11, 2016, 9:19 AM Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
>>
>> On Sun, 11 Sep 2016, Matthew Pickering wrote:
>>
>> > The type of `deleteBy` in `Data.List` could easily be generalised in a
>> > useful way.
>> >
>> > ```
>> > deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a]
>> > ```
>>
>> I do not see why deleteBy should have an argument for the deleted element,
>> anyway, since it is not even the element to delete (only an equivalent
>> one). Wouldn't a function with type
>>
>> newDeleteBy :: (a -> Bool) -> [a] -> [a]
>>
>> be much more straight-forward?
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160911/79f34d8c/attachment.html>

From mail at joachim-breitner.de  Mon Sep 12 00:11:43 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 11 Sep 2016 20:11:43 -0400
Subject: Generalise type of deleteBy
In-Reply-To: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
Message-ID: <1473639103.6084.3.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 11.09.2016, 11:25 +0100 schrieb Matthew Pickering:
> deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b]

-1 from me. This makes this different from the usual fooBy pattern, and
the fact this this is possible points to some code smell, namely the
lack of a

     (a -> Bool) -> [a] -> [a]

function.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160911/5afe7ffc/attachment-0001.sig>

From malcolm.wallace at me.com  Mon Sep 12 08:53:12 2016
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Mon, 12 Sep 2016 09:53:12 +0100
Subject: Generalise type of deleteBy
In-Reply-To: <alpine.DEB.2.02.1609111815420.15457@sputnik>
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
 <alpine.DEB.2.02.1609111815420.15457@sputnik>
Message-ID: <31384911-47EC-434D-8F77-F1407FADB14D@me.com>


On 11 Sep 2016, at 17:19, Henning Thielemann wrote:

> 
> I do not see why deleteBy should have an argument for the deleted element, anyway, since it is not even the element to delete (only an equivalent one). Wouldn't a function with type
> 
> newDeleteBy :: (a -> Bool) -> [a] -> [a]
> 
> be much more straight-forward?

It already exists, and is called "filter", modulo the sense of the boolean.

Regards,
    Malcolm


From matthewtpickering at gmail.com  Mon Sep 12 09:20:23 2016
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 12 Sep 2016 10:20:23 +0100
Subject: Generalise type of deleteBy
In-Reply-To: <31384911-47EC-434D-8F77-F1407FADB14D@me.com>
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
 <alpine.DEB.2.02.1609111815420.15457@sputnik>
 <31384911-47EC-434D-8F77-F1407FADB14D@me.com>
Message-ID: <CALuQ0m_YmKrVJ3P9dQcFzA1ApqhROHqU5GYwHR_mY-piuXMmsw@mail.gmail.com>

Malcolm, the semantics of deleteBy are slightly different as it only
deletes the first occurrence. In the end however I did use `filter` as
I didn't
care particularly about just deleting the first matching value, as
there was at most one matching value in the whole list.

Joachim, it seems to me that `deleteBy` is the odd one out as the
types of `sortBy` and `maximumBy` are the most general types.

Anyway, this function is not used very often. I searched on hackage
and there were less than 50 uses. There is a simple patch which I have
provided and people are welcome to merge if they like but I don't
think we should spend a lot of time arguing about this or worrying
about potential breakage.

Matt



On Mon, Sep 12, 2016 at 9:53 AM, Malcolm Wallace <malcolm.wallace at me.com> wrote:
>
> On 11 Sep 2016, at 17:19, Henning Thielemann wrote:
>
>>
>> I do not see why deleteBy should have an argument for the deleted element, anyway, since it is not even the element to delete (only an equivalent one). Wouldn't a function with type
>>
>> newDeleteBy :: (a -> Bool) -> [a] -> [a]
>>
>> be much more straight-forward?
>
> It already exists, and is called "filter", modulo the sense of the boolean.
>
> Regards,
>     Malcolm
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From johnw at newartisans.com  Mon Sep 12 17:27:45 2016
From: johnw at newartisans.com (John Wiegley)
Date: Mon, 12 Sep 2016 10:27:45 -0700
Subject: Generalise type of deleteBy
In-Reply-To: <CAJumaK_wmBNYVE6X+H8ui6c_RMVR=fjoeXvUyg6YKFLA0ZsRLA@mail.gmail.com>
 (Edward Kmett's message of "Sun, 11 Sep 2016 08:33:33 -0400")
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
 <CAKA2JgLoVFqaS49W7sAv6TO3y=t=SPyS6hkLFiqBFw7gTp=3Rg@mail.gmail.com>
 <CAJumaK_wmBNYVE6X+H8ui6c_RMVR=fjoeXvUyg6YKFLA0ZsRLA@mail.gmail.com>
Message-ID: <m2lgyx2fla.fsf@newartisans.com>

>>>>> "EK" == Edward Kmett <ekmett at gmail.com> writes:

EK> I have no objection.
EK> +1

Also +1.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

From david.feuer at gmail.com  Mon Sep 12 17:42:42 2016
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 12 Sep 2016 13:42:42 -0400
Subject: Generalise type of deleteBy
In-Reply-To: <1473639103.6084.3.camel@joachim-breitner.de>
References: <CALuQ0m9MjnOYF+KUw43YMA3B=TEFnJ+gUXbQBE9-BVBFTjKBew@mail.gmail.com>
 <1473639103.6084.3.camel@joachim-breitner.de>
Message-ID: <CAMgWh9una-=tE6FRFycDFqPbVTm17RGeSZqdMsueUeNV6r_SkA@mail.gmail.com>

-1 from me as well, for the same reasons.

On Sep 11, 2016 8:11 PM, "Joachim Breitner" <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Sonntag, den 11.09.2016, 11:25 +0100 schrieb Matthew Pickering:
> > deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b]
>
> -1 from me. This makes this different from the usual fooBy pattern, and
> the fact this this is possible points to some code smell, namely the
> lack of a
>
>      (a -> Bool) -> [a] -> [a]
>
> function.
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160912/19084b1f/attachment.html>

From david.feuer at gmail.com  Mon Sep 12 17:53:32 2016
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 12 Sep 2016 13:53:32 -0400
Subject: Numeric read seems too strict
In-Reply-To: <CAMgWh9udv7S+t96xBx_1HkxEVdJM34J6oTK=y2Bo+s8-w2bm_w@mail.gmail.com>
References: <CAMgWh9s7kpgu-h=oSJfq_LqNOnKsURoJXwsHsBEo2wwFf7yTTA@mail.gmail.com>
 <CAMgWh9s5J0E3AbeMWWkkiVfw8G+ejy_bcoGuy+J_P+yRNEi8VQ@mail.gmail.com>
 <CAMgWh9tAYBecSA73xQaEegjUD++cf51ybCfYYMQrAjXzW3vyMw@mail.gmail.com>
 <CAMgWh9siamyawyNXB=0DiWMEk3m0QA=R5F4yTN-ZONYDT=KBqQ@mail.gmail.com>
 <CAMgWh9sJdTyMF6n203wz=Bptnz_VAYQ4r63CcKocfH6mHK6qig@mail.gmail.com>
 <CAMgWh9sQ_p6oT3hRH9NjhZE8eJiFJpEw0M+9j1=t+azV67UfOQ@mail.gmail.com>
 <CAMgWh9udv7S+t96xBx_1HkxEVdJM34J6oTK=y2Bo+s8-w2bm_w@mail.gmail.com>
Message-ID: <CAMgWh9sOYiVXzzAut3sJYnzHE8=MePOOk1DMg39x_JduRKFsAg@mail.gmail.com>

I noticed the other day that

readMaybe (fix ('a':)) :: Maybe Double

is an infinite loop. The problem is that the lexer doesn't know that it's
expected to lex a number. It just keeps scanning and scanning to get to the
end of the endless token. Shall we fix this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160912/a3221764/attachment.html>

From david.feuer at gmail.com  Mon Sep 12 18:03:39 2016
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 12 Sep 2016 14:03:39 -0400
Subject: Numeric read seems too strict
In-Reply-To: <CAMgWh9vOdt2V+wS6xCW_NFjd9zzkDQa7z4o6+8tAzKHJWQa5mg@mail.gmail.com>
References: <CAMgWh9s7kpgu-h=oSJfq_LqNOnKsURoJXwsHsBEo2wwFf7yTTA@mail.gmail.com>
 <CAMgWh9s5J0E3AbeMWWkkiVfw8G+ejy_bcoGuy+J_P+yRNEi8VQ@mail.gmail.com>
 <CAMgWh9tAYBecSA73xQaEegjUD++cf51ybCfYYMQrAjXzW3vyMw@mail.gmail.com>
 <CAMgWh9siamyawyNXB=0DiWMEk3m0QA=R5F4yTN-ZONYDT=KBqQ@mail.gmail.com>
 <CAMgWh9sJdTyMF6n203wz=Bptnz_VAYQ4r63CcKocfH6mHK6qig@mail.gmail.com>
 <CAMgWh9sQ_p6oT3hRH9NjhZE8eJiFJpEw0M+9j1=t+azV67UfOQ@mail.gmail.com>
 <CAMgWh9udv7S+t96xBx_1HkxEVdJM34J6oTK=y2Bo+s8-w2bm_w@mail.gmail.com>
 <CAMgWh9sOYiVXzzAut3sJYnzHE8=MePOOk1DMg39x_JduRKFsAg@mail.gmail.com>
 <CAMgWh9tChWxAW0Wm3xNMDZocwBr=kd+hms7KCCSdVqR3Ams8TQ@mail.gmail.com>
 <CAMgWh9vOdt2V+wS6xCW_NFjd9zzkDQa7z4o6+8tAzKHJWQa5mg@mail.gmail.com>
Message-ID: <CAMgWh9tu9SGHNnKAJZWcacevo=cebANH2Zonk1P=GzBGpWgDcg@mail.gmail.com>

By the way, I believe we should be able to read numbers more efficiently by
parsing them directly instead of lexing first. We have to deal with
parentheses, white space, and signs uniformly for all number types. Then
specialized foldl'-style code *should* be able to parse integral and
fractional numbers faster than any lex-first scheme.

On Sep 12, 2016 1:53 PM, "David Feuer" <david.feuer at gmail.com> wrote:

I noticed the other day that

readMaybe (fix ('a':)) :: Maybe Double

is an infinite loop. The problem is that the lexer doesn't know that it's
expected to lex a number. It just keeps scanning and scanning to get to the
end of the endless token. Shall we fix this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160912/b13c1058/attachment.html>

From carter.schonwald at gmail.com  Wed Sep 14 18:14:20 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 14 Sep 2016 14:14:20 -0400
Subject: Numeric read seems too strict
In-Reply-To: <CAMgWh9tu9SGHNnKAJZWcacevo=cebANH2Zonk1P=GzBGpWgDcg@mail.gmail.com>
References: <CAMgWh9s7kpgu-h=oSJfq_LqNOnKsURoJXwsHsBEo2wwFf7yTTA@mail.gmail.com>
 <CAMgWh9s5J0E3AbeMWWkkiVfw8G+ejy_bcoGuy+J_P+yRNEi8VQ@mail.gmail.com>
 <CAMgWh9tAYBecSA73xQaEegjUD++cf51ybCfYYMQrAjXzW3vyMw@mail.gmail.com>
 <CAMgWh9siamyawyNXB=0DiWMEk3m0QA=R5F4yTN-ZONYDT=KBqQ@mail.gmail.com>
 <CAMgWh9sJdTyMF6n203wz=Bptnz_VAYQ4r63CcKocfH6mHK6qig@mail.gmail.com>
 <CAMgWh9sQ_p6oT3hRH9NjhZE8eJiFJpEw0M+9j1=t+azV67UfOQ@mail.gmail.com>
 <CAMgWh9udv7S+t96xBx_1HkxEVdJM34J6oTK=y2Bo+s8-w2bm_w@mail.gmail.com>
 <CAMgWh9sOYiVXzzAut3sJYnzHE8=MePOOk1DMg39x_JduRKFsAg@mail.gmail.com>
 <CAMgWh9tChWxAW0Wm3xNMDZocwBr=kd+hms7KCCSdVqR3Ams8TQ@mail.gmail.com>
 <CAMgWh9vOdt2V+wS6xCW_NFjd9zzkDQa7z4o6+8tAzKHJWQa5mg@mail.gmail.com>
 <CAMgWh9tu9SGHNnKAJZWcacevo=cebANH2Zonk1P=GzBGpWgDcg@mail.gmail.com>
Message-ID: <CAHYVw0xfO9GJGyc1e5-q-kdHpM6dLxfNocyn7=gXV8FP2EKCzw@mail.gmail.com>

Read and show are supposed to be simple and perhaps at least have well
behaved asymptotic performance , but ultimately are for simple debugging
and or pasting back into source.  Granted it winds up also being used to
serialize small config that are human manipulable or easy to paste back
into source

On Sep 12, 2016 2:03 PM, "David Feuer" <david.feuer at gmail.com> wrote:

> By the way, I believe we should be able to read numbers more efficiently
> by parsing them directly instead of lexing first. We have to deal with
> parentheses, white space, and signs uniformly for all number types. Then
> specialized foldl'-style code *should* be able to parse integral and
> fractional numbers faster than any lex-first scheme.
>
> On Sep 12, 2016 1:53 PM, "David Feuer" <david.feuer at gmail.com> wrote:
>
> I noticed the other day that
>
> readMaybe (fix ('a':)) :: Maybe Double
>
> is an infinite loop. The problem is that the lexer doesn't know that it's
> expected to lex a number. It just keeps scanning and scanning to get to the
> end of the endless token. Shall we fix this?
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160914/e4c366e1/attachment.html>

From david.feuer at gmail.com  Wed Sep 14 18:18:21 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 14 Sep 2016 14:18:21 -0400
Subject: Numeric read seems too strict
In-Reply-To: <CAHYVw0xfO9GJGyc1e5-q-kdHpM6dLxfNocyn7=gXV8FP2EKCzw@mail.gmail.com>
References: <CAMgWh9s7kpgu-h=oSJfq_LqNOnKsURoJXwsHsBEo2wwFf7yTTA@mail.gmail.com>
 <CAMgWh9s5J0E3AbeMWWkkiVfw8G+ejy_bcoGuy+J_P+yRNEi8VQ@mail.gmail.com>
 <CAMgWh9tAYBecSA73xQaEegjUD++cf51ybCfYYMQrAjXzW3vyMw@mail.gmail.com>
 <CAMgWh9siamyawyNXB=0DiWMEk3m0QA=R5F4yTN-ZONYDT=KBqQ@mail.gmail.com>
 <CAMgWh9sJdTyMF6n203wz=Bptnz_VAYQ4r63CcKocfH6mHK6qig@mail.gmail.com>
 <CAMgWh9sQ_p6oT3hRH9NjhZE8eJiFJpEw0M+9j1=t+azV67UfOQ@mail.gmail.com>
 <CAMgWh9udv7S+t96xBx_1HkxEVdJM34J6oTK=y2Bo+s8-w2bm_w@mail.gmail.com>
 <CAMgWh9sOYiVXzzAut3sJYnzHE8=MePOOk1DMg39x_JduRKFsAg@mail.gmail.com>
 <CAMgWh9tChWxAW0Wm3xNMDZocwBr=kd+hms7KCCSdVqR3Ams8TQ@mail.gmail.com>
 <CAMgWh9vOdt2V+wS6xCW_NFjd9zzkDQa7z4o6+8tAzKHJWQa5mg@mail.gmail.com>
 <CAMgWh9tu9SGHNnKAJZWcacevo=cebANH2Zonk1P=GzBGpWgDcg@mail.gmail.com>
 <CAHYVw0xfO9GJGyc1e5-q-kdHpM6dLxfNocyn7=gXV8FP2EKCzw@mail.gmail.com>
Message-ID: <CAMgWh9tCOmovedXRKeLBXhWfguFcgOqtoHQiHgQ-y9NuUuHw1Q@mail.gmail.com>

This may be true, but I don't see how it's relevant.

On Sep 14, 2016 2:14 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
wrote:

> Read and show are supposed to be simple and perhaps at least have well
> behaved asymptotic performance , but ultimately are for simple debugging
> and or pasting back into source.  Granted it winds up also being used to
> serialize small config that are human manipulable or easy to paste back
> into source
>
> On Sep 12, 2016 2:03 PM, "David Feuer" <david.feuer at gmail.com> wrote:
>
>> By the way, I believe we should be able to read numbers more efficiently
>> by parsing them directly instead of lexing first. We have to deal with
>> parentheses, white space, and signs uniformly for all number types. Then
>> specialized foldl'-style code *should* be able to parse integral and
>> fractional numbers faster than any lex-first scheme.
>>
>> On Sep 12, 2016 1:53 PM, "David Feuer" <david.feuer at gmail.com> wrote:
>>
>> I noticed the other day that
>>
>> readMaybe (fix ('a':)) :: Maybe Double
>>
>> is an infinite loop. The problem is that the lexer doesn't know that it's
>> expected to lex a number. It just keeps scanning and scanning to get to the
>> end of the endless token. Shall we fix this?
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160914/fc404bb5/attachment.html>

From grantwwu at gmail.com  Mon Sep 26 21:41:17 2016
From: grantwwu at gmail.com (Grant Wu)
Date: Mon, 26 Sep 2016 17:41:17 -0400
Subject: Bug in Eq/Ord typeclass documentation?
Message-ID: <CACyqxevHxm_KE_DimMcsKVWJ+Gc9GUcBFW7r3WE02six=4EcTQ@mail.gmail.com>

Neither Eq nor Ord have the types/summary of the methods that are part
of the minimal complete definition listed.  See
http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#t:Eq.

Hopefully this is the right place to email.  If not, apologies in advance.

Thanks,

Grant Wu
grantwwu at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160926/c21133b4/attachment.html>

From ezyang at mit.edu  Mon Sep 26 21:48:35 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Mon, 26 Sep 2016 14:48:35 -0700
Subject: Bug in Eq/Ord typeclass documentation?
In-Reply-To: <CACyqxevHxm_KE_DimMcsKVWJ+Gc9GUcBFW7r3WE02six=4EcTQ@mail.gmail.com>
References: <CACyqxevHxm_KE_DimMcsKVWJ+Gc9GUcBFW7r3WE02six=4EcTQ@mail.gmail.com>
Message-ID: <1474926482-sup-2941@sabre>

Hello Grant,

The bug is known and there is a patch! http://ghc.haskell.org/trac/ghc/ticket/12519

Edward

Excerpts from Grant Wu's message of 2016-09-26 17:41:17 -0400:
> Neither Eq nor Ord have the types/summary of the methods that are part
> of the minimal complete definition listed.  See
> http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#t:Eq.
> 
> Hopefully this is the right place to email.  If not, apologies in advance.
> 
> Thanks,
> 
> Grant Wu
> grantwwu at gmail.com

From david.feuer at gmail.com  Fri Sep 30 23:25:21 2016
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 30 Sep 2016 19:25:21 -0400
Subject: Proposal: add Monoid1 and Semigroup1 classes
In-Reply-To: <CAMgWh9vidFW8PFtkoT6upMvjSOdLk8UBjs29qknoUfh9FAHeHg@mail.gmail.com>
References: <CAMgWh9s+o6w1G1-S6oSJJN+LZOwNJC3jMMGONFnJtzf=Z93QaA@mail.gmail.com>
 <CAMgWh9uZBidKxRk8ood6tmMw0QYE2fQAxjSFAHDM6AEqE2UAyg@mail.gmail.com>
 <CAMgWh9vLM-U=QcLwFzfL0jBHS_UPTyK1mpgCBQDofvJoijcEhA@mail.gmail.com>
 <CAMgWh9v0TO=WJ3=YZshaByh+7auF2s7JyFSw9M3qDf0WMLmRfA@mail.gmail.com>
 <CAMgWh9sSA3Gx2MmayP2FaVaC-MMjjxE_kUs2tLn+-eRX3yfSZg@mail.gmail.com>
 <CAMgWh9sLnzigXtu8gr4W5H=ZB89U24k1HZ==1bTsg9DOngddJA@mail.gmail.com>
 <CAMgWh9u+7TwQnq0yWaen_o7Nfy80btpxPGMOGRpXrvBw1bX+cg@mail.gmail.com>
 <CAMgWh9tpxpHR+0krGB14=xH5ms1faOnUx7k3L86X2uUOOoZPnw@mail.gmail.com>
 <CAMgWh9vGBYSVVJtLOhfm+uBUYMGut4P-U6LXWKwNbyWc4NHgvg@mail.gmail.com>
 <CAMgWh9v+JQSbYOCKyYODFOuCzZ4A1Qe_j4HHqyctYORRd=1dyw@mail.gmail.com>
 <CAMgWh9vpNLya8Rrn7a1tA7y=4hu-i19EFt6YQP0XDANbWMB8kA@mail.gmail.com>
 <CAMgWh9vidFW8PFtkoT6upMvjSOdLk8UBjs29qknoUfh9FAHeHg@mail.gmail.com>
Message-ID: <CAMgWh9sf106f+KwZGYw3qAFs=1AfkK96vvFfV8rMUuGB=c3Vig@mail.gmail.com>

I've been playing around with the idea of writing Haskell 2010 type classes
for finite sequences and non-empty sequences, somewhat similar to Michael
Snoyman's Sequence class in mono-traversable. These are naturally based on
Monoid1 and Semigroup1, which I think belong in base.

class Semigroup1 f where
  (<<>>) :: f a -> f a -> f a
class Semigroup1 f => Monoid1 f where
  mempty1 :: f a

Then I can write

class (Monoid1 t, Traversable t) => Sequence t where
  singleton :: a -> t a
  -- and other less-critical methods

class (Semigroup1 t, Traversable1 t) => NESequence where
  singleton1 :: a -> t a
  -- etc.

I can, of course, just write my own, but I don't think I'm the only one
using such.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160930/1b41f485/attachment.html>