From lemming at henning-thielemann.de  Sun May  1 14:38:07 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 1 May 2016 16:38:07 +0200 (CEST)
Subject: deepseq: instance NFData (a -> b)
Message-ID: <alpine.DEB.2.02.1605011622120.8792@sputnik>


According to Haddock comments, between deepseq-1.2 and deepseq-1.3 an 
instance for NFData on functions was introduced without previous 
discussion. I find this instance pretty problematic since it has no 
superclasses. The correct instance would be certainly something like

instance (Enumerate a, NFData b) => NFData (a -> b)

where Enumerate would be a new class that allows to enumerate all values 
of a type. This would be hardly useful because it is pretty inefficient. 
I'd prefer that the instance is removed, again, or even better, be 
replaced by a non-implementable instance. Alternatively we should replace 
it by a correct implementation with corresponding superclasses. If we do 
the second, then we could still omit the Enumerate instance for types 
where enumeration of all values of the type is too expensive.

I assume that the instance was added to simplify automatic derivation of 
NFData instances. However, I think it would be better if people insert 
custom deepseq implementation for the expected functions then.

From m at tweag.io  Sun May  1 14:51:45 2016
From: m at tweag.io (Boespflug, Mathieu)
Date: Sun, 1 May 2016 16:51:45 +0200
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <alpine.DEB.2.02.1605011622120.8792@sputnik>
References: <alpine.DEB.2.02.1605011622120.8792@sputnik>
Message-ID: <CAJ0eudorCOKC1QvS7oAqhZBvYYYKiDO26E4t6=MEGmu+9vbcVQ@mail.gmail.com>

+1

This instance doesn't make much sense (to me at least) and is pretty
problematic for apps that use NFData constraints as evidence that
values are ground and fully evaluated (hence don't capture arbitrary
resources). In HaskellR we use NFData constraints to make sure only
fully evaluated ground data escapes the scope of a region. But
functions are not a first-order values. They can leak arbitrary
resources out of the scope of a region.
--
Mathieu Boespflug
Founder at http://tweag.io.


On 1 May 2016 at 16:38, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
>
> According to Haddock comments, between deepseq-1.2 and deepseq-1.3 an
> instance for NFData on functions was introduced without previous discussion.
> I find this instance pretty problematic since it has no superclasses. The
> correct instance would be certainly something like
>
> instance (Enumerate a, NFData b) => NFData (a -> b)
>
> where Enumerate would be a new class that allows to enumerate all values of
> a type. This would be hardly useful because it is pretty inefficient. I'd
> prefer that the instance is removed, again, or even better, be replaced by a
> non-implementable instance. Alternatively we should replace it by a correct
> implementation with corresponding superclasses. If we do the second, then we
> could still omit the Enumerate instance for types where enumeration of all
> values of the type is too expensive.
>
> I assume that the instance was added to simplify automatic derivation of
> NFData instances. However, I think it would be better if people insert
> custom deepseq implementation for the expected functions then.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From mike at barrucadu.co.uk  Sun May  1 14:58:43 2016
From: mike at barrucadu.co.uk (Michael Walker)
Date: Sun, 1 May 2016 15:58:43 +0100
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <alpine.DEB.2.02.1605011622120.8792@sputnik>
References: <alpine.DEB.2.02.1605011622120.8792@sputnik>
Message-ID: <20160501155843.38c8b089@azathoth>

It depends on what you mean when you say a function is in normal form.
Unfortunately the instance doesn't capture either of the definitions
that immediately come to my mind:

- All values it returns are in normal form? This requires an NFData b
  constraint.
- The body of the function is in normal form? This requires HNF, which
  we don't have in Haskell. I guess the current instance is going for
  this, but approximates HNF with WHNF.

I'm +1 to removing this, simply because there are at least three
(including yours) reasonable definitions. If someone wants an NFData
instance for a value which includes functions, they should know exactly
how they want to handle that.

On Sun, 1 May 2016 16:38:07 +0200 (CEST)
Henning Thielemann <lemming at henning-thielemann.de> wrote:

> According to Haddock comments, between deepseq-1.2 and deepseq-1.3 an 
> instance for NFData on functions was introduced without previous 
> discussion. I find this instance pretty problematic since it has no 
> superclasses. The correct instance would be certainly something like
> 
> instance (Enumerate a, NFData b) => NFData (a -> b)
> 
> where Enumerate would be a new class that allows to enumerate all
> values of a type. This would be hardly useful because it is pretty
> inefficient. I'd prefer that the instance is removed, again, or even
> better, be replaced by a non-implementable instance. Alternatively we
> should replace it by a correct implementation with corresponding
> superclasses. If we do the second, then we could still omit the
> Enumerate instance for types where enumeration of all values of the
> type is too expensive.
> 
> I assume that the instance was added to simplify automatic derivation
> of NFData instances. However, I think it would be better if people
> insert custom deepseq implementation for the expected functions then.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- 
Michael Walker (http://www.barrucadu.co.uk)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160501/1e100150/attachment.sig>

From hvriedel at gmail.com  Sun May  1 15:00:53 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sun, 01 May 2016 17:00:53 +0200
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <CAJ0eudorCOKC1QvS7oAqhZBvYYYKiDO26E4t6=MEGmu+9vbcVQ@mail.gmail.com>
 (Mathieu Boespflug's message of "Sun, 1 May 2016 16:51:45 +0200")
References: <alpine.DEB.2.02.1605011622120.8792@sputnik>
 <CAJ0eudorCOKC1QvS7oAqhZBvYYYKiDO26E4t6=MEGmu+9vbcVQ@mail.gmail.com>
Message-ID: <87bn4p961m.fsf@gnu.org>

On 2016-05-01 at 16:51:45 +0200, Boespflug, Mathieu wrote:

[...]

> This instance doesn't make much sense (to me at least) and is pretty
> problematic for apps that use NFData constraints as evidence that
> values are ground and fully evaluated (hence don't capture arbitrary
> resources). In HaskellR we use NFData constraints to make sure only
> fully evaluated ground data escapes the scope of a region. But
> functions are not a first-order values. They can leak arbitrary
> resources out of the scope of a region.

Are the recently added NFData instances for IORef/MVar problematic as
well?

-- hvr

From mail at nh2.me  Sun May  1 15:07:31 2016
From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=)
Date: Sun, 1 May 2016 17:07:31 +0200
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <alpine.DEB.2.02.1605011622120.8792@sputnik>
References: <alpine.DEB.2.02.1605011622120.8792@sputnik>
Message-ID: <57261BB3.2070305@nh2.me>

I wound find it interesting to learn what exactly will break when this
instance is removed / what feature motivated the addition of the einstance.

I'm taking a guess here, maybe it's Generics based deriving?

    data D = D { something :: Int, somethingElse :: Int -> String }
      deriving Generic

    deriving instance NFData D

Is it this?

From m at tweag.io  Sun May  1 15:10:48 2016
From: m at tweag.io (Boespflug, Mathieu)
Date: Sun, 1 May 2016 17:10:48 +0200
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <87bn4p961m.fsf@gnu.org>
References: <alpine.DEB.2.02.1605011622120.8792@sputnik>
 <CAJ0eudorCOKC1QvS7oAqhZBvYYYKiDO26E4t6=MEGmu+9vbcVQ@mail.gmail.com>
 <87bn4p961m.fsf@gnu.org>
Message-ID: <CAJ0eudqKPh99Px_dGPiMtAZ9Fk+ccfU5QENKfr7+mJMftH=CZw@mail.gmail.com>

On 1 May 2016 at 17:00, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> On 2016-05-01 at 16:51:45 +0200, Boespflug, Mathieu wrote:
>
> [...]
>
>> This instance doesn't make much sense (to me at least) and is pretty
>> problematic for apps that use NFData constraints as evidence that
>> values are ground and fully evaluated (hence don't capture arbitrary
>> resources). In HaskellR we use NFData constraints to make sure only
>> fully evaluated ground data escapes the scope of a region. But
>> functions are not a first-order values. They can leak arbitrary
>> resources out of the scope of a region.
>
> Are the recently added NFData instances for IORef/MVar problematic as
> well?

I guess so, yes!

These 3 instances, along with the STRef one, strike me as antithetical
to the purpose stated at the top of the DeepSeq module:

"A typical use is to prevent resource leaks in lazy IO programs,
[...]. Another common use is to ensure any exceptions hidden within
lazy fields of a data structure do not leak outside the scope of the
exception handler, or to force evaluation of a data structure in one
thread, before passing to another thread (preventing work moving to
the wrong threads)."

Or perhaps - we should at the very clarify and characterize precisely
what invariants NFData instances are or are not expected to enforce?

From david.feuer at gmail.com  Sun May  1 16:06:17 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 1 May 2016 12:06:17 -0400
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <87bn4p961m.fsf@gnu.org>
References: <alpine.DEB.2.02.1605011622120.8792@sputnik>
 <CAJ0eudorCOKC1QvS7oAqhZBvYYYKiDO26E4t6=MEGmu+9vbcVQ@mail.gmail.com>
 <87bn4p961m.fsf@gnu.org>
Message-ID: <CAMgWh9sh488DoQBEKJgvkEukY3dj40hZSyWVTR=fBxVWNqLCXA@mail.gmail.com>

I say no. An `IORef` is just a pointer, and forcing one to NF means
quite simply that you determine exactly where it points, which is
completely different from forcing whatever happens to be on the other
end. A function seems much more problematic.

On Sun, May 1, 2016 at 11:00 AM, Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
> On 2016-05-01 at 16:51:45 +0200, Boespflug, Mathieu wrote:
>
> [...]
>
>> This instance doesn't make much sense (to me at least) and is pretty
>> problematic for apps that use NFData constraints as evidence that
>> values are ground and fully evaluated (hence don't capture arbitrary
>> resources). In HaskellR we use NFData constraints to make sure only
>> fully evaluated ground data escapes the scope of a region. But
>> functions are not a first-order values. They can leak arbitrary
>> resources out of the scope of a region.
>
> Are the recently added NFData instances for IORef/MVar problematic as
> well?
>
> -- hvr
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From blamario at ciktel.net  Sun May  1 16:43:48 2016
From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Sun, 1 May 2016 12:43:48 -0400
Subject: Proposal: add chunksOf to Data.Sequence
In-Reply-To: <CAMgWh9vxV4hEGnFJAhhrxVmZDbC3YaoUNQE87AFDTcL=OMPasA@mail.gmail.com>
References: <CAMgWh9uNuZ4OEXpRwEJpbgeDMQYU9myqOLL_T0tzPYz2G_We_g@mail.gmail.com>
 <CAMgWh9vxV4hEGnFJAhhrxVmZDbC3YaoUNQE87AFDTcL=OMPasA@mail.gmail.com>
Message-ID: <0f1f580d-aaa6-7e14-0417-08c3621f7ad2@ciktel.net>

On 04/25/2016 11:53 PM, David Feuer wrote:
> Last year, I proposed adding chunksOf to Data.Sequence (mimicking the
> functionality of Data.List.Split.chunksOf, and taking advantage of
> internal structure to improve the efficiency beyond anything
> implementable using the current public API). The proposal was met with
> deafening silence. I seek advice and consent of anyone who cares.

I will provide a general comment about Data.Sequence. I don't care much 
for it.

     While I occasionally use the data type, its performance 
characteristics mean that it's rarely what I need. In particular, its 
O(log n) complexity of mappend is a killer for many applications. The 
problem with Data.Sequence may be that it attempts to be a 
jack-of-all-sequences. I can't recall ever needing a fully symmetric 
queue. It's nice, I guess, to have a general-purpose data-structure at 
hand when prototyping, but a more specialized implementation should 
always win in production.

     Would you consider adding (and maintaining) a simpler data 
structure with O(1) mappend to containers, perhaps something like 
https://github.com/nikita-volkov/bytestring-tree-builder/blob/master/library/ByteString/TreeBuilder/Tree.hs 
? That is something I'd be reaching for more often that Data.Sequence as 
it stands.


From david.feuer at gmail.com  Sun May  1 16:45:51 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 1 May 2016 12:45:51 -0400
Subject: Proposal: add chunksOf to Data.Sequence
In-Reply-To: <0f1f580d-aaa6-7e14-0417-08c3621f7ad2@ciktel.net>
References: <CAMgWh9uNuZ4OEXpRwEJpbgeDMQYU9myqOLL_T0tzPYz2G_We_g@mail.gmail.com>
 <CAMgWh9vxV4hEGnFJAhhrxVmZDbC3YaoUNQE87AFDTcL=OMPasA@mail.gmail.com>
 <0f1f580d-aaa6-7e14-0417-08c3621f7ad2@ciktel.net>
Message-ID: <CAMgWh9vYQ4no95zBQcuXEDyeX0NnL4ESkbb+cYhoDdVXzQRBDw@mail.gmail.com>

I will entertain various such suggestions, certainly, but that is quite
orthogonal to this particular question!
On May 1, 2016 12:43 PM, "Mario Bla?evi?" <blamario at ciktel.net> wrote:

> On 04/25/2016 11:53 PM, David Feuer wrote:
>
>> Last year, I proposed adding chunksOf to Data.Sequence (mimicking the
>> functionality of Data.List.Split.chunksOf, and taking advantage of
>> internal structure to improve the efficiency beyond anything
>> implementable using the current public API). The proposal was met with
>> deafening silence. I seek advice and consent of anyone who cares.
>>
>
> I will provide a general comment about Data.Sequence. I don't care much
> for it.
>
>     While I occasionally use the data type, its performance
> characteristics mean that it's rarely what I need. In particular, its O(log
> n) complexity of mappend is a killer for many applications. The problem
> with Data.Sequence may be that it attempts to be a jack-of-all-sequences. I
> can't recall ever needing a fully symmetric queue. It's nice, I guess, to
> have a general-purpose data-structure at hand when prototyping, but a more
> specialized implementation should always win in production.
>
>     Would you consider adding (and maintaining) a simpler data structure
> with O(1) mappend to containers, perhaps something like
> https://github.com/nikita-volkov/bytestring-tree-builder/blob/master/library/ByteString/TreeBuilder/Tree.hs
> ? That is something I'd be reaching for more often that Data.Sequence as it
> stands.
>
> _______________________________________________
> 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/20160501/e9d64dce/attachment.html>

From dan.doel at gmail.com  Sun May  1 18:12:13 2016
From: dan.doel at gmail.com (Dan Doel)
Date: Sun, 1 May 2016 14:12:13 -0400
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <20160501155843.38c8b089@azathoth>
References: <alpine.DEB.2.02.1605011622120.8792@sputnik>
 <20160501155843.38c8b089@azathoth>
Message-ID: <CAHEA9tOo1QKXWRVXeBHEwCOwkVtCtNpsz8e3txQeiwiT4tpDTg@mail.gmail.com>

On Sun, May 1, 2016 at 10:58 AM, Michael Walker <mike at barrucadu.co.uk> wrote:
> It depends on what you mean when you say a function is in normal form.
> Unfortunately the instance doesn't capture either of the definitions
> that immediately come to my mind:
>
> - All values it returns are in normal form? This requires an NFData b
>   constraint.

Even when talking about term rewriting, reducing an application of two
normal forms does not necessarily yield a normal form directly.

> - The body of the function is in normal form? This requires HNF, which
>   we don't have in Haskell. I guess the current instance is going for
>   this, but approximates HNF with WHNF.

Requiring the body to be in normal form would actually be normal form.
Head normal form is actually a weaker condition, where the body must
not be a redex. But the distinction is rather academic, because
neither of these can easily be achieved in GHC.

Anyhow, I would suggest not getting hung up on what 'normal form'
means, because it is actually just a bad name for what is going on
once functions are involved. Really, that's why the class is named
`NFData` in my mind, because talking about what it does as being the
'normal form' only really makes sense when you're talking about pure,
sum-of-products algebraic data, and functions are not that.

The more important question is, what is desirable behavior, and why?
Why would enumerating all possible results of a function and deep
seqing them be the desired behavior of deep seqing a function? It
doesn't necessarily, for instance, have the sort of, 'pull everything
into memory to free another scarce resource,' effect mentioned,
because functions don't work that way.

I would guess that the main argument for this behavior is to say that
it is the only 'allowed' behavior, but, being useless, it should just
be removed. But it would be better to argue that the instance should
be removed directly.

-- Dan

From spam at scientician.net  Fri May  6 09:28:00 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 6 May 2016 11:28:00 +0200
Subject: Proposal: add chunksOf to Data.Sequence
In-Reply-To: <CAMgWh9uNuZ4OEXpRwEJpbgeDMQYU9myqOLL_T0tzPYz2G_We_g@mail.gmail.com>
References: <CAMgWh9uNuZ4OEXpRwEJpbgeDMQYU9myqOLL_T0tzPYz2G_We_g@mail.gmail.com>
Message-ID: <ngho30$cnn$1@ger.gmane.org>

On 03/15/2015 05:45 PM, David Feuer wrote:
> Data.List.Split.chunksOf n xs breaks up a list xs into chunks of n elements
> each. The internal "splitMap" function Data.Sequence uses to implement
> zipWith supports a simple and efficient implementation of chunksOf. All in
> favor, say "aye".

+1

(as some who needs this at this very moment. I guess I'll have to write
my own for now.)

... though it seems a bit odd that List doesn't have this? Would it make
sense to add it there too? It seems like this must be at least as
commonly used as e.g. 'permutations'.

> 
> Also, I'm still waiting for a response (any response) to my "cycleN"
> proposal.
> 

+0

... as in: Don't particularly care either way. No sure if that counts as
a response :).

Regards,



From ryan.gl.scott at gmail.com  Fri May  6 15:56:45 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Fri, 6 May 2016 11:56:45 -0400
Subject: deepseq: instance NFData (a -> b)
Message-ID: <CADdQpRC1zC8_yqMOakf-Oxg8eVNudd57SidCg49pvGitgaDigA@mail.gmail.com>

I'm tentatively +1 on the idea of removing the NFData (a -> b) instance.

Henning raises a good point that there are probably folks who rely on
that instance to make automatic deriving of NFData. (Disclaimer: the
phrase "folks" includes myself.) A similar scenario arises when
deriving Show instances, for which a compromise was made by putting
the Text.Show.Functions module in base, which does nothing but export
an orphan Show (a -> b) instance.

Perhaps, if we wanted to retain the ability to use the NFData (a -> b)
instance in limited scenarios (e.g., when you're writing an
application and there's no risk of leaking orphan instances to other
users), then we could also introduce a Control.DeepSeq.Functions
module that exports an orphan NFData (a -> b) instance, and put a
giant warning at the top stating that such an instance should be used
responsibly. What say ye?

Ryan S.

From lemming at henning-thielemann.de  Fri May  6 16:03:04 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 6 May 2016 18:03:04 +0200 (CEST)
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <CADdQpRC1zC8_yqMOakf-Oxg8eVNudd57SidCg49pvGitgaDigA@mail.gmail.com>
References: <CADdQpRC1zC8_yqMOakf-Oxg8eVNudd57SidCg49pvGitgaDigA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1605061759510.9103@sputnik>


On Fri, 6 May 2016, Ryan Scott wrote:

> Perhaps, if we wanted to retain the ability to use the NFData (a -> b)
> instance in limited scenarios (e.g., when you're writing an
> application and there's no risk of leaking orphan instances to other
> users), then we could also introduce a Control.DeepSeq.Functions
> module that exports an orphan NFData (a -> b) instance, and put a
> giant warning at the top stating that such an instance should be used
> responsibly. What say ye?

Since we got several problematic instances over time, we might also 
consider my proposal of warning about these instances on user demand:
    http://mail.haskell.org/pipermail/libraries/2016-March/026859.html
    https://ghc.haskell.org/trac/ghc/ticket/11796

From ekmett at gmail.com  Fri May  6 21:52:08 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 6 May 2016 17:52:08 -0400
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <CADdQpRC1zC8_yqMOakf-Oxg8eVNudd57SidCg49pvGitgaDigA@mail.gmail.com>
References: <CADdQpRC1zC8_yqMOakf-Oxg8eVNudd57SidCg49pvGitgaDigA@mail.gmail.com>
Message-ID: <54B0AF55-2D1D-41C3-92EA-DE13C9E81263@gmail.com>

I have to admit the idea of duplicating the orphan instance module we have for Text.Show.Functions makes me queasy. It is a pretty ugly compromise that makes everyone unhappy, not really a model for future behavior. I'd rather drop the instance entirely but could be convinced.

Sent from my iPad

> On May 6, 2016, at 11:56 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> 
> I'm tentatively +1 on the idea of removing the NFData (a -> b) instance.
> 
> Henning raises a good point that there are probably folks who rely on
> that instance to make automatic deriving of NFData. (Disclaimer: the
> phrase "folks" includes myself.) A similar scenario arises when
> deriving Show instances, for which a compromise was made by putting
> the Text.Show.Functions module in base, which does nothing but export
> an orphan Show (a -> b) instance.
> 
> Perhaps, if we wanted to retain the ability to use the NFData (a -> b)
> instance in limited scenarios (e.g., when you're writing an
> application and there's no risk of leaking orphan instances to other
> users), then we could also introduce a Control.DeepSeq.Functions
> module that exports an orphan NFData (a -> b) instance, and put a
> giant warning at the top stating that such an instance should be used
> responsibly. What say ye?
> 
> Ryan S.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From ryan.gl.scott at gmail.com  Fri May  6 21:58:02 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Fri, 6 May 2016 17:58:02 -0400
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <54B0AF55-2D1D-41C3-92EA-DE13C9E81263@gmail.com>
References: <CADdQpRC1zC8_yqMOakf-Oxg8eVNudd57SidCg49pvGitgaDigA@mail.gmail.com>
 <54B0AF55-2D1D-41C3-92EA-DE13C9E81263@gmail.com>
Message-ID: <CADdQpRCRW-u-uyFgPsnyNshnMbLJYLTKFPau+xoRdRkvptLCXA@mail.gmail.com>

I wouldn't be sad to see the instance go, although I do extract a minimal
amount of utility out of it. In any case, I doubt I'm going to convince
anyone, so let's just remove it :)

Ryan S.
On May 6, 2016 5:52 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

> I have to admit the idea of duplicating the orphan instance module we have
> for Text.Show.Functions makes me queasy. It is a pretty ugly compromise
> that makes everyone unhappy, not really a model for future behavior. I'd
> rather drop the instance entirely but could be convinced.
>
> Sent from my iPad
>
> > On May 6, 2016, at 11:56 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> >
> > I'm tentatively +1 on the idea of removing the NFData (a -> b) instance.
> >
> > Henning raises a good point that there are probably folks who rely on
> > that instance to make automatic deriving of NFData. (Disclaimer: the
> > phrase "folks" includes myself.) A similar scenario arises when
> > deriving Show instances, for which a compromise was made by putting
> > the Text.Show.Functions module in base, which does nothing but export
> > an orphan Show (a -> b) instance.
> >
> > Perhaps, if we wanted to retain the ability to use the NFData (a -> b)
> > instance in limited scenarios (e.g., when you're writing an
> > application and there's no risk of leaking orphan instances to other
> > users), then we could also introduce a Control.DeepSeq.Functions
> > module that exports an orphan NFData (a -> b) instance, and put a
> > giant warning at the top stating that such an instance should be used
> > responsibly. What say ye?
> >
> > Ryan S.
> > _______________________________________________
> > 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/20160506/97e1a25e/attachment.html>

From spam at scientician.net  Sat May  7 08:05:14 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Sat, 7 May 2016 10:05:14 +0200
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <54B0AF55-2D1D-41C3-92EA-DE13C9E81263@gmail.com>
References: <CADdQpRC1zC8_yqMOakf-Oxg8eVNudd57SidCg49pvGitgaDigA@mail.gmail.com>
 <54B0AF55-2D1D-41C3-92EA-DE13C9E81263@gmail.com>
Message-ID: <ngk7jq$ddk$1@ger.gmane.org>

On 05/06/2016 11:52 PM, Edward Kmett wrote:
> I have to admit the idea of duplicating the orphan instance module we
> have for Text.Show.Functions makes me queasy. It is a pretty ugly
compromise
> that makes everyone unhappy, not really a model for future behavior.
I'd rather
> drop the instance entirely but could be convinced.
> 

+1

KILL IT! KILL IT WITH FIRE!... ahem.

Regards,


From ekmett at gmail.com  Sat May  7 14:13:06 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 7 May 2016 10:13:06 -0400
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <ngk7jq$ddk$1@ger.gmane.org>
References: <CADdQpRC1zC8_yqMOakf-Oxg8eVNudd57SidCg49pvGitgaDigA@mail.gmail.com>
 <54B0AF55-2D1D-41C3-92EA-DE13C9E81263@gmail.com>
 <ngk7jq$ddk$1@ger.gmane.org>
Message-ID: <CAJumaK8wJZDZ0HpRZD1QioEC6MD1XJtLFxo-OBaVTviONOth_Q@mail.gmail.com>

Let's turn this around, is there anybody actually in favor of keeping
the instance?

On Sat, May 7, 2016 at 4:05 AM, Bardur Arantsson <spam at scientician.net> wrote:
> On 05/06/2016 11:52 PM, Edward Kmett wrote:
>> I have to admit the idea of duplicating the orphan instance module we
>> have for Text.Show.Functions makes me queasy. It is a pretty ugly
> compromise
>> that makes everyone unhappy, not really a model for future behavior.
> I'd rather
>> drop the instance entirely but could be convinced.
>>
>
> +1
>
> KILL IT! KILL IT WITH FIRE!... ahem.
>
> Regards,
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From david.feuer at gmail.com  Sat May  7 20:45:31 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 7 May 2016 16:45:31 -0400
Subject: Argument order for Data.Map.adjustF
In-Reply-To: <CAMgWh9tR2GVF0MfgnOHDW+YugAvb1iJb7MrfMQjc0dk-jZ0J1w@mail.gmail.com>
References: <CAMgWh9uwMyynxi1jDcF_NUuGvjzdCK+RQs+SoRMBo2YHjDR-LQ@mail.gmail.com>
 <CAMgWh9vjeKneS1uBvxTq5HiY0AW5SqDTCBrBXXQn=FHPB6cTqw@mail.gmail.com>
 <CAMgWh9s-c6Qv5Vg8=uH_GZUdzkpR9frARKv4aqqmifC2VaEYFw@mail.gmail.com>
 <CAMgWh9thB=W=MjJ2hZV9JBestT0foHCFDM79TUr94Nakgi76Og@mail.gmail.com>
 <CAMgWh9tgx5fznJugL02hRA=sJ7t95PPBOF6h59MzW2htd=RqHg@mail.gmail.com>
 <CAMgWh9tpyJX5qOmCCsgcUyi6_U=fYzasTSxG8j8FMA5HtnsRYA@mail.gmail.com>
 <CAMgWh9vpO4mYnV6ZDMpcdatNhv4YXOiN=5O8CH+6Q-7Qt73p4g@mail.gmail.com>
 <CAMgWh9vOZtj+jjCZ-J8b8vY9Sb+zPS0CxTfvMZomZUtMHVkQow@mail.gmail.com>
 <CAMgWh9v8k09wZNE_4aLPZ=4RCWbtcsLCfooW2aQ01GhLQg-jbw@mail.gmail.com>
 <CAMgWh9s7vznNi1zgjj5ygAm0dFWSz6ftVkRiA-8uSPbhUUBD+w@mail.gmail.com>
 <CAMgWh9vedG_vLc-BHu-46gW53aJWZ9WPTxyxk21D4Bdt1wr=+Q@mail.gmail.com>
 <CAMgWh9ssA3vxBitszDSZr3=4ppDzMXchNJh5q_Nn-DoRMr+K8Q@mail.gmail.com>
 <CAMgWh9tR2GVF0MfgnOHDW+YugAvb1iJb7MrfMQjc0dk-jZ0J1w@mail.gmail.com>
Message-ID: <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>

I managed to find an implementation of Control.Lens.At.at for Data.Map
that's fast enough to be useful. The function will be named alterF to match
the name of Data.Map.alter. The remaining question is what order the
arguments should go in. I had thought to follow those of alter for
consistency, giving

alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k a ->
f (Map k a)

Edward Kmett thinks the ergonomics of that order are terrible, and prefers
to follow lens at, giving

alterF :: (Functor f, Ord k) => k -> (Maybe a -> f (Maybe a)) -> Map k a ->
f (Map k a)

How do other people feel about this?

David Feuer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160507/ee1a3f2e/attachment.html>

From ivan.miljenovic at gmail.com  Sat May  7 22:24:29 2016
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sun, 8 May 2016 08:24:29 +1000
Subject: Argument order for Data.Map.adjustF
In-Reply-To: <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>
References: <CAMgWh9uwMyynxi1jDcF_NUuGvjzdCK+RQs+SoRMBo2YHjDR-LQ@mail.gmail.com>
 <CAMgWh9vjeKneS1uBvxTq5HiY0AW5SqDTCBrBXXQn=FHPB6cTqw@mail.gmail.com>
 <CAMgWh9s-c6Qv5Vg8=uH_GZUdzkpR9frARKv4aqqmifC2VaEYFw@mail.gmail.com>
 <CAMgWh9thB=W=MjJ2hZV9JBestT0foHCFDM79TUr94Nakgi76Og@mail.gmail.com>
 <CAMgWh9tgx5fznJugL02hRA=sJ7t95PPBOF6h59MzW2htd=RqHg@mail.gmail.com>
 <CAMgWh9tpyJX5qOmCCsgcUyi6_U=fYzasTSxG8j8FMA5HtnsRYA@mail.gmail.com>
 <CAMgWh9vpO4mYnV6ZDMpcdatNhv4YXOiN=5O8CH+6Q-7Qt73p4g@mail.gmail.com>
 <CAMgWh9vOZtj+jjCZ-J8b8vY9Sb+zPS0CxTfvMZomZUtMHVkQow@mail.gmail.com>
 <CAMgWh9v8k09wZNE_4aLPZ=4RCWbtcsLCfooW2aQ01GhLQg-jbw@mail.gmail.com>
 <CAMgWh9s7vznNi1zgjj5ygAm0dFWSz6ftVkRiA-8uSPbhUUBD+w@mail.gmail.com>
 <CAMgWh9vedG_vLc-BHu-46gW53aJWZ9WPTxyxk21D4Bdt1wr=+Q@mail.gmail.com>
 <CAMgWh9ssA3vxBitszDSZr3=4ppDzMXchNJh5q_Nn-DoRMr+K8Q@mail.gmail.com>
 <CAMgWh9tR2GVF0MfgnOHDW+YugAvb1iJb7MrfMQjc0dk-jZ0J1w@mail.gmail.com>
 <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>
Message-ID: <CA+u6gbxaAiiXyDvhU7ib_EVzXsch28VQz2+rO99Wev=b7exe+A@mail.gmail.com>

On 8 May 2016 at 06:45, David Feuer <david.feuer at gmail.com> wrote:
> I managed to find an implementation of Control.Lens.At.at for Data.Map
> that's fast enough to be useful. The function will be named alterF to match
> the name of Data.Map.alter. The remaining question is what order the
> arguments should go in. I had thought to follow those of alter for
> consistency, giving
>
> alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k a ->
> f (Map k a)
>
> Edward Kmett thinks the ergonomics of that order are terrible, and prefers
> to follow lens at, giving
>
> alterF :: (Functor f, Ord k) => k -> (Maybe a -> f (Maybe a)) -> Map k a ->
> f (Map k a)
>
> How do other people feel about this?

I have a slight preference for the first one as I'm more likely to be
applying the same function over multiple keys than having the same key
being altered with different functions.

>
> David Feuer
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From ekmett at gmail.com  Sat May  7 23:59:30 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 7 May 2016 19:59:30 -0400
Subject: Argument order for Data.Map.adjustF
In-Reply-To: <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>
References: <CAMgWh9uwMyynxi1jDcF_NUuGvjzdCK+RQs+SoRMBo2YHjDR-LQ@mail.gmail.com>
 <CAMgWh9vjeKneS1uBvxTq5HiY0AW5SqDTCBrBXXQn=FHPB6cTqw@mail.gmail.com>
 <CAMgWh9s-c6Qv5Vg8=uH_GZUdzkpR9frARKv4aqqmifC2VaEYFw@mail.gmail.com>
 <CAMgWh9thB=W=MjJ2hZV9JBestT0foHCFDM79TUr94Nakgi76Og@mail.gmail.com>
 <CAMgWh9tgx5fznJugL02hRA=sJ7t95PPBOF6h59MzW2htd=RqHg@mail.gmail.com>
 <CAMgWh9tpyJX5qOmCCsgcUyi6_U=fYzasTSxG8j8FMA5HtnsRYA@mail.gmail.com>
 <CAMgWh9vpO4mYnV6ZDMpcdatNhv4YXOiN=5O8CH+6Q-7Qt73p4g@mail.gmail.com>
 <CAMgWh9vOZtj+jjCZ-J8b8vY9Sb+zPS0CxTfvMZomZUtMHVkQow@mail.gmail.com>
 <CAMgWh9v8k09wZNE_4aLPZ=4RCWbtcsLCfooW2aQ01GhLQg-jbw@mail.gmail.com>
 <CAMgWh9s7vznNi1zgjj5ygAm0dFWSz6ftVkRiA-8uSPbhUUBD+w@mail.gmail.com>
 <CAMgWh9vedG_vLc-BHu-46gW53aJWZ9WPTxyxk21D4Bdt1wr=+Q@mail.gmail.com>
 <CAMgWh9ssA3vxBitszDSZr3=4ppDzMXchNJh5q_Nn-DoRMr+K8Q@mail.gmail.com>
 <CAMgWh9tR2GVF0MfgnOHDW+YugAvb1iJb7MrfMQjc0dk-jZ0J1w@mail.gmail.com>
 <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>
Message-ID: <CAJumaK8Tf4y4khNLr2heVCu1qAPyU=otQBdLPYOe0WR3TY96fg@mail.gmail.com>

I do agree that it would be more consistent to use the alter ordering,
but I don't see many users who will reach for it as "generalized
alter".

Ultimately, I anticipate the major consumers of such a function would
be people using some lens package, either through us changing the
default definitions in lens to automatically use it on appropriate
versions of containers, or through using a more minimalist lens
package that doesn't provide lenses for containers -- most other
people will neither find the new operation nor care.

The former would require a flip for lens consumers to turn it back
into a lens, making it much harder to recognize as such.

-Edward

On Sat, May 7, 2016 at 4:45 PM, David Feuer <david.feuer at gmail.com> wrote:
> I managed to find an implementation of Control.Lens.At.at for Data.Map
> that's fast enough to be useful. The function will be named alterF to match
> the name of Data.Map.alter. The remaining question is what order the
> arguments should go in. I had thought to follow those of alter for
> consistency, giving
>
> alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k a ->
> f (Map k a)
>
> Edward Kmett thinks the ergonomics of that order are terrible, and prefers
> to follow lens at, giving
>
> alterF :: (Functor f, Ord k) => k -> (Maybe a -> f (Maybe a)) -> Map k a ->
> f (Map k a)
>
> How do other people feel about this?
>
> David Feuer

From lemming at henning-thielemann.de  Sun May  8 18:58:54 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 8 May 2016 20:58:54 +0200 (CEST)
Subject: deepseq: instance NFData (a -> b)
In-Reply-To: <CAJumaK8wJZDZ0HpRZD1QioEC6MD1XJtLFxo-OBaVTviONOth_Q@mail.gmail.com>
References: <CADdQpRC1zC8_yqMOakf-Oxg8eVNudd57SidCg49pvGitgaDigA@mail.gmail.com>
 <54B0AF55-2D1D-41C3-92EA-DE13C9E81263@gmail.com> <ngk7jq$ddk$1@ger.gmane.org>
 <CAJumaK8wJZDZ0HpRZD1QioEC6MD1XJtLFxo-OBaVTviONOth_Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1605082055050.9658@sputnik>


On Sat, 7 May 2016, Edward Kmett wrote:

> Let's turn this around, is there anybody actually in favor of keeping
> the instance?

Looking in the git-logs I found git-commit 
3b5c957ce7bba7b63b4483a43c6762c3f5d8ee28 by Herbert Valerio Riedel saying:

"Merge `deepseq-generics` into `deepseq` ..."

and it points to the proposal:
    http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/23031


So, I guess Herbert must be in favor of the instance because he added it. 
:-)

And this commit confirms that the instance NFData (a->b) was a side 
product of Generics support.

From jake.mcarthur at gmail.com  Wed May 11 12:53:07 2016
From: jake.mcarthur at gmail.com (Jake McArthur)
Date: Wed, 11 May 2016 12:53:07 +0000
Subject: Argument order for Data.Map.adjustF
In-Reply-To: <CAJumaK8Tf4y4khNLr2heVCu1qAPyU=otQBdLPYOe0WR3TY96fg@mail.gmail.com>
References: <CAMgWh9uwMyynxi1jDcF_NUuGvjzdCK+RQs+SoRMBo2YHjDR-LQ@mail.gmail.com>
 <CAMgWh9vjeKneS1uBvxTq5HiY0AW5SqDTCBrBXXQn=FHPB6cTqw@mail.gmail.com>
 <CAMgWh9s-c6Qv5Vg8=uH_GZUdzkpR9frARKv4aqqmifC2VaEYFw@mail.gmail.com>
 <CAMgWh9thB=W=MjJ2hZV9JBestT0foHCFDM79TUr94Nakgi76Og@mail.gmail.com>
 <CAMgWh9tgx5fznJugL02hRA=sJ7t95PPBOF6h59MzW2htd=RqHg@mail.gmail.com>
 <CAMgWh9tpyJX5qOmCCsgcUyi6_U=fYzasTSxG8j8FMA5HtnsRYA@mail.gmail.com>
 <CAMgWh9vpO4mYnV6ZDMpcdatNhv4YXOiN=5O8CH+6Q-7Qt73p4g@mail.gmail.com>
 <CAMgWh9vOZtj+jjCZ-J8b8vY9Sb+zPS0CxTfvMZomZUtMHVkQow@mail.gmail.com>
 <CAMgWh9v8k09wZNE_4aLPZ=4RCWbtcsLCfooW2aQ01GhLQg-jbw@mail.gmail.com>
 <CAMgWh9s7vznNi1zgjj5ygAm0dFWSz6ftVkRiA-8uSPbhUUBD+w@mail.gmail.com>
 <CAMgWh9vedG_vLc-BHu-46gW53aJWZ9WPTxyxk21D4Bdt1wr=+Q@mail.gmail.com>
 <CAMgWh9ssA3vxBitszDSZr3=4ppDzMXchNJh5q_Nn-DoRMr+K8Q@mail.gmail.com>
 <CAMgWh9tR2GVF0MfgnOHDW+YugAvb1iJb7MrfMQjc0dk-jZ0J1w@mail.gmail.com>
 <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>
 <CAJumaK8Tf4y4khNLr2heVCu1qAPyU=otQBdLPYOe0WR3TY96fg@mail.gmail.com>
Message-ID: <CACN--9D+4A4gtGkQN=413fqeky3DOmn7J6t1-3UtLEALjL42YQ@mail.gmail.com>

This might be a good case for having two names for the same function. Both
use cases seem reasonable, and I don't really want containers to be too
opinionated about the style of code using it.

On Sat, May 7, 2016, 7:59 PM Edward Kmett <ekmett at gmail.com> wrote:

> I do agree that it would be more consistent to use the alter ordering,
> but I don't see many users who will reach for it as "generalized
> alter".
>
> Ultimately, I anticipate the major consumers of such a function would
> be people using some lens package, either through us changing the
> default definitions in lens to automatically use it on appropriate
> versions of containers, or through using a more minimalist lens
> package that doesn't provide lenses for containers -- most other
> people will neither find the new operation nor care.
>
> The former would require a flip for lens consumers to turn it back
> into a lens, making it much harder to recognize as such.
>
> -Edward
>
> On Sat, May 7, 2016 at 4:45 PM, David Feuer <david.feuer at gmail.com> wrote:
> > I managed to find an implementation of Control.Lens.At.at for Data.Map
> > that's fast enough to be useful. The function will be named alterF to
> match
> > the name of Data.Map.alter. The remaining question is what order the
> > arguments should go in. I had thought to follow those of alter for
> > consistency, giving
> >
> > alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k a
> ->
> > f (Map k a)
> >
> > Edward Kmett thinks the ergonomics of that order are terrible, and
> prefers
> > to follow lens at, giving
> >
> > alterF :: (Functor f, Ord k) => k -> (Maybe a -> f (Maybe a)) -> Map k a
> ->
> > f (Map k a)
> >
> > How do other people feel about this?
> >
> > David Feuer
> _______________________________________________
> 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/20160511/a9e3e708/attachment.html>

From tkn.akio at gmail.com  Thu May 12 05:11:23 2016
From: tkn.akio at gmail.com (Akio Takano)
Date: Thu, 12 May 2016 05:11:23 +0000
Subject: Argument order for Data.Map.adjustF
In-Reply-To: <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>
References: <CAMgWh9uwMyynxi1jDcF_NUuGvjzdCK+RQs+SoRMBo2YHjDR-LQ@mail.gmail.com>
 <CAMgWh9vjeKneS1uBvxTq5HiY0AW5SqDTCBrBXXQn=FHPB6cTqw@mail.gmail.com>
 <CAMgWh9s-c6Qv5Vg8=uH_GZUdzkpR9frARKv4aqqmifC2VaEYFw@mail.gmail.com>
 <CAMgWh9thB=W=MjJ2hZV9JBestT0foHCFDM79TUr94Nakgi76Og@mail.gmail.com>
 <CAMgWh9tgx5fznJugL02hRA=sJ7t95PPBOF6h59MzW2htd=RqHg@mail.gmail.com>
 <CAMgWh9tpyJX5qOmCCsgcUyi6_U=fYzasTSxG8j8FMA5HtnsRYA@mail.gmail.com>
 <CAMgWh9vpO4mYnV6ZDMpcdatNhv4YXOiN=5O8CH+6Q-7Qt73p4g@mail.gmail.com>
 <CAMgWh9vOZtj+jjCZ-J8b8vY9Sb+zPS0CxTfvMZomZUtMHVkQow@mail.gmail.com>
 <CAMgWh9v8k09wZNE_4aLPZ=4RCWbtcsLCfooW2aQ01GhLQg-jbw@mail.gmail.com>
 <CAMgWh9s7vznNi1zgjj5ygAm0dFWSz6ftVkRiA-8uSPbhUUBD+w@mail.gmail.com>
 <CAMgWh9vedG_vLc-BHu-46gW53aJWZ9WPTxyxk21D4Bdt1wr=+Q@mail.gmail.com>
 <CAMgWh9ssA3vxBitszDSZr3=4ppDzMXchNJh5q_Nn-DoRMr+K8Q@mail.gmail.com>
 <CAMgWh9tR2GVF0MfgnOHDW+YugAvb1iJb7MrfMQjc0dk-jZ0J1w@mail.gmail.com>
 <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>
Message-ID: <CAOGQyFtAXf-eGJBO3B8zHrV4xfoHC3wbGv4o1A10iwVc+dB4MQ@mail.gmail.com>

On 7 May 2016 at 20:45, David Feuer <david.feuer at gmail.com> wrote:
> I managed to find an implementation of Control.Lens.At.at for Data.Map
> that's fast enough to be useful. The function will be named alterF to match
> the name of Data.Map.alter. The remaining question is what order the
> arguments should go in. I had thought to follow those of alter for
> consistency, giving
>
> alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k a ->
> f (Map k a)

I would vote for this order. The other order would be very surprising
for anyone who is familiar with other functions of this family.

Also I think this function is something a significant number of people
will use directly, not as a lens. alter is the most general way to
update the value for a key, and the need for its monadic variant will
come up from time to time. At least I wanted this function a few times
in the past.

Regards,
Takano Akio

From david.feuer at gmail.com  Tue May 17 21:03:31 2016
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 17 May 2016 17:03:31 -0400
Subject: Proposal: Add a catamorphism on Trees
Message-ID: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>

Daniel Wagner would like to add the following straightforward function
to Data.Tree. I think this is a grand idea.

foldTree :: (a -> [b] -> b) -> Tree a -> b
foldTree f = go
  where
    go (Node x ts) = f x (map go ts)

From mail at joachim-breitner.de  Tue May 17 21:18:51 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 17 May 2016 23:18:51 +0200
Subject: Proposal: Add a catamorphism on Trees
In-Reply-To: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
References: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
Message-ID: <1463519931.22620.0.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 17.05.2016, 17:03 -0400 schrieb David Feuer:
> Daniel Wagner would like to add the following straightforward
> function
> to Data.Tree. I think this is a grand idea.
> 
> foldTree :: (a -> [b] -> b) -> Tree a -> b
> foldTree f = go
> ? where
> ????go (Node x ts) = f x (map go ts)

LGTM

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: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160517/767d41a0/attachment.sig>

From mike at barrucadu.co.uk  Tue May 17 21:19:01 2016
From: mike at barrucadu.co.uk (Michael Walker)
Date: Tue, 17 May 2016 22:19:01 +0100
Subject: Proposal: Add a catamorphism on Trees
In-Reply-To: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
References: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
Message-ID: <20160517221901.4b403100@azathoth>

On Tue, 17 May 2016 17:03:31 -0400
David Feuer <david.feuer at gmail.com> wrote:

> Daniel Wagner would like to add the following straightforward function
> to Data.Tree. I think this is a grand idea.
> 
> foldTree :: (a -> [b] -> b) -> Tree a -> b
> foldTree f = go
>   where
>     go (Node x ts) = f x (map go ts)

+1

Nice, simple, and useful.

-- 
Michael Walker (http://www.barrucadu.co.uk)

From ekmett at gmail.com  Tue May 17 22:35:31 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 17 May 2016 18:35:31 -0400
Subject: Proposal: Add a catamorphism on Trees
In-Reply-To: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
References: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
Message-ID: <CAJumaK-doZuncxXPQDxHEWdFJ8B5ZVKOriK_nEKbDPbXGaJnqg@mail.gmail.com>

No objection here.

+1

On Tue, May 17, 2016 at 5:03 PM, David Feuer <david.feuer at gmail.com> wrote:

> Daniel Wagner would like to add the following straightforward function
> to Data.Tree. I think this is a grand idea.
>
> foldTree :: (a -> [b] -> b) -> Tree a -> b
> foldTree f = go
>   where
>     go (Node x ts) = f x (map go ts)
> _______________________________________________
> 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/20160517/251e7db6/attachment.html>

From alpmestan at gmail.com  Wed May 18 12:52:03 2016
From: alpmestan at gmail.com (Alp Mestanogullari)
Date: Wed, 18 May 2016 14:52:03 +0200
Subject: Proposal: Add a catamorphism on Trees
In-Reply-To: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
References: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
Message-ID: <CADZnDvCppCFRNLhGrvB21pKPE+HizTDpcRw_-aDEumeFA0X3Mw@mail.gmail.com>

+1, have implemented it in a few occasions already.

On Tue, May 17, 2016 at 11:03 PM, David Feuer <david.feuer at gmail.com> wrote:

> Daniel Wagner would like to add the following straightforward function
> to Data.Tree. I think this is a grand idea.
>
> foldTree :: (a -> [b] -> b) -> Tree a -> b
> foldTree f = go
>   where
>     go (Node x ts) = f x (map go ts)
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



-- 
Alp Mestanogullari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160518/b0e12c94/attachment.html>

From jake.mcarthur at gmail.com  Wed May 18 12:55:26 2016
From: jake.mcarthur at gmail.com (Jake McArthur)
Date: Wed, 18 May 2016 12:55:26 +0000
Subject: Proposal: Add a catamorphism on Trees
In-Reply-To: <CADZnDvCppCFRNLhGrvB21pKPE+HizTDpcRw_-aDEumeFA0X3Mw@mail.gmail.com>
References: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
 <CADZnDvCppCFRNLhGrvB21pKPE+HizTDpcRw_-aDEumeFA0X3Mw@mail.gmail.com>
Message-ID: <CACN--9BnZMD7EFrPw9-E6mqcv=SXrQu_ADpBxWDYc1ma7nFm_Q@mail.gmail.com>

+1 from me as well. I think I'm unlikely to ever turn down a
straightforward catamorphism or anamorphism.

On Wed, May 18, 2016, 8:52 AM Alp Mestanogullari <alpmestan at gmail.com>
wrote:

> +1, have implemented it in a few occasions already.
>
> On Tue, May 17, 2016 at 11:03 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
>> Daniel Wagner would like to add the following straightforward function
>> to Data.Tree. I think this is a grand idea.
>>
>> foldTree :: (a -> [b] -> b) -> Tree a -> b
>> foldTree f = go
>>   where
>>     go (Node x ts) = f x (map go ts)
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
>
> --
> Alp Mestanogullari
> _______________________________________________
> 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/20160518/68566380/attachment.html>

From amindfv at gmail.com  Wed May 18 15:28:58 2016
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Wed, 18 May 2016 11:28:58 -0400
Subject: Proposal: Add a catamorphism on Trees
In-Reply-To: <CACN--9BnZMD7EFrPw9-E6mqcv=SXrQu_ADpBxWDYc1ma7nFm_Q@mail.gmail.com>
References: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
 <CADZnDvCppCFRNLhGrvB21pKPE+HizTDpcRw_-aDEumeFA0X3Mw@mail.gmail.com>
 <CACN--9BnZMD7EFrPw9-E6mqcv=SXrQu_ADpBxWDYc1ma7nFm_Q@mail.gmail.com>
Message-ID: <9069BE38-37BC-4512-AE1F-2B51862DD96C@gmail.com>

+1

Tom


> El 18 may 2016, a las 08:55, Jake McArthur <jake.mcarthur at gmail.com> escribi?:
> 
> +1 from me as well. I think I'm unlikely to ever turn down a straightforward catamorphism or anamorphism.
> 
> 
>> On Wed, May 18, 2016, 8:52 AM Alp Mestanogullari <alpmestan at gmail.com> wrote:
>> +1, have implemented it in a few occasions already.
>> 
>>> On Tue, May 17, 2016 at 11:03 PM, David Feuer <david.feuer at gmail.com> wrote:
>>> Daniel Wagner would like to add the following straightforward function
>>> to Data.Tree. I think this is a grand idea.
>>> 
>>> foldTree :: (a -> [b] -> b) -> Tree a -> b
>>> foldTree f = go
>>>   where
>>>     go (Node x ts) = f x (map go ts)
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> 
>> 
>> 
>> -- 
>> Alp Mestanogullari
>> _______________________________________________
>> 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/20160518/b52f81f8/attachment.html>

From tikhon at jelv.is  Wed May 18 15:32:49 2016
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Wed, 18 May 2016 08:32:49 -0700
Subject: Proposal: Add a catamorphism on Trees
In-Reply-To: <9069BE38-37BC-4512-AE1F-2B51862DD96C@gmail.com>
References: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
 <CADZnDvCppCFRNLhGrvB21pKPE+HizTDpcRw_-aDEumeFA0X3Mw@mail.gmail.com>
 <CACN--9BnZMD7EFrPw9-E6mqcv=SXrQu_ADpBxWDYc1ma7nFm_Q@mail.gmail.com>
 <9069BE38-37BC-4512-AE1F-2B51862DD96C@gmail.com>
Message-ID: <CAJN5CV+TZqE-gOoOogUEAk9u7ChQhe0=PhM7YqZg_KCs18cG6w@mail.gmail.com>

I was just thinking about refactoring some code to a tree fold?I had
assumed it was in the library already, and only realized it wasn't when I
saw this thread.

Definite +1.
On May 18, 2016 8:28 AM, <amindfv at gmail.com> wrote:

> +1
>
> Tom
>
>
> El 18 may 2016, a las 08:55, Jake McArthur <jake.mcarthur at gmail.com>
> escribi?:
>
> +1 from me as well. I think I'm unlikely to ever turn down a
> straightforward catamorphism or anamorphism.
>
> On Wed, May 18, 2016, 8:52 AM Alp Mestanogullari <alpmestan at gmail.com>
> wrote:
>
>> +1, have implemented it in a few occasions already.
>>
>> On Tue, May 17, 2016 at 11:03 PM, David Feuer <david.feuer at gmail.com>
>> wrote:
>>
>>> Daniel Wagner would like to add the following straightforward function
>>> to Data.Tree. I think this is a grand idea.
>>>
>>> foldTree :: (a -> [b] -> b) -> Tree a -> b
>>> foldTree f = go
>>>   where
>>>     go (Node x ts) = f x (map go ts)
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>
>>
>>
>> --
>> Alp Mestanogullari
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20160518/fd52e560/attachment.html>

From ekmett at gmail.com  Wed May 18 15:44:18 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 18 May 2016 11:44:18 -0400
Subject: Proposal: Add a catamorphism on Trees
In-Reply-To: <CAJN5CV+TZqE-gOoOogUEAk9u7ChQhe0=PhM7YqZg_KCs18cG6w@mail.gmail.com>
References: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
 <CADZnDvCppCFRNLhGrvB21pKPE+HizTDpcRw_-aDEumeFA0X3Mw@mail.gmail.com>
 <CACN--9BnZMD7EFrPw9-E6mqcv=SXrQu_ADpBxWDYc1ma7nFm_Q@mail.gmail.com>
 <9069BE38-37BC-4512-AE1F-2B51862DD96C@gmail.com>
 <CAJN5CV+TZqE-gOoOogUEAk9u7ChQhe0=PhM7YqZg_KCs18cG6w@mail.gmail.com>
Message-ID: <CAJumaK9j7zqPthUwqoOWShY9kitsVjVtQ8OuRvNNb09T3mTf-g@mail.gmail.com>

Interestingly, I just noticed I'm missing a similar combinator in `free`
for the Cofree comonad.

https://github.com/ekmett/free/issues/136

On Wed, May 18, 2016 at 11:32 AM, Tikhon Jelvis <tikhon at jelv.is> wrote:

> I was just thinking about refactoring some code to a tree fold?I had
> assumed it was in the library already, and only realized it wasn't when I
> saw this thread.
>
> Definite +1.
> On May 18, 2016 8:28 AM, <amindfv at gmail.com> wrote:
>
>> +1
>>
>> Tom
>>
>>
>> El 18 may 2016, a las 08:55, Jake McArthur <jake.mcarthur at gmail.com>
>> escribi?:
>>
>> +1 from me as well. I think I'm unlikely to ever turn down a
>> straightforward catamorphism or anamorphism.
>>
>> On Wed, May 18, 2016, 8:52 AM Alp Mestanogullari <alpmestan at gmail.com>
>> wrote:
>>
>>> +1, have implemented it in a few occasions already.
>>>
>>> On Tue, May 17, 2016 at 11:03 PM, David Feuer <david.feuer at gmail.com>
>>> wrote:
>>>
>>>> Daniel Wagner would like to add the following straightforward function
>>>> to Data.Tree. I think this is a grand idea.
>>>>
>>>> foldTree :: (a -> [b] -> b) -> Tree a -> b
>>>> foldTree f = go
>>>>   where
>>>>     go (Node x ts) = f x (map go ts)
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>>
>>>
>>>
>>> --
>>> Alp Mestanogullari
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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/20160518/017f261e/attachment-0001.html>

From johnw at newartisans.com  Wed May 18 17:19:42 2016
From: johnw at newartisans.com (John Wiegley)
Date: Wed, 18 May 2016 10:19:42 -0700
Subject: Proposal: Add a catamorphism on Trees
In-Reply-To: <CADZnDvCppCFRNLhGrvB21pKPE+HizTDpcRw_-aDEumeFA0X3Mw@mail.gmail.com>
 (Alp Mestanogullari's message of "Wed, 18 May 2016 14:52:03 +0200")
References: <CAMgWh9udMMqXmF2g-PfMbuboPmsZPi6OmVa0MZ0MtPGsjoSOSA@mail.gmail.com>
 <CADZnDvCppCFRNLhGrvB21pKPE+HizTDpcRw_-aDEumeFA0X3Mw@mail.gmail.com>
Message-ID: <m2h9dvi8r5.fsf@newartisans.com>

>>>>> Alp Mestanogullari <alpmestan at gmail.com> writes:

> +1, have implemented it in a few occasions already.

+1

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

From holmisen at gmail.com  Thu May 19 05:27:49 2016
From: holmisen at gmail.com (Johan Holmquist)
Date: Thu, 19 May 2016 07:27:49 +0200
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
Message-ID: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>

The discussion period for this proposal is near (31 of May).

So far I count 1 for and 2 against the proposal.

Joachim Breitner made a good enumeration of some advantages of adding these
to base. Here is an enumeration of pros:

* Availability in Data.List gives this pattern a common name.

* A common name for this makes code easier to read and decreases the risk
of getting the definition wrong.

* The argument won't have to be repeated, hence making it easier to chain
the functions.

* List-fusion potential.


Tobias Florek pointed out that `zip <*> tail` can be used to define this
inline without the need for repeating the argument and made a reference to
the Fairbairn threshold. This is elegant, but I am afraid that people might
consider this obscure code golfing if used.

Cheers
Johan Holmquist


---------- Forwarded message ----------
From: Henning Thielemann <lemming at henning-thielemann.de>
Date: 2016-04-13 13:28 GMT+02:00
Subject: Re: Proposal: Add functions to get consecutive elements to
Data.List
To: Johan Holmquist <holmisen at gmail.com>
Cc: Haskell Libraries <libraries at haskell.org>



On Wed, 13 Apr 2016, Johan Holmquist wrote:

It is not strictly more general because it cannot handle empty sequences.
>

Think of it as if it handles the non-[] case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160519/911e9734/attachment.html>

From david.feuer at gmail.com  Thu May 19 05:37:59 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 19 May 2016 01:37:59 -0400
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
Message-ID: <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>

You promised a collection of use cases. I seem to have missed it. Could you
send the link again?
On May 19, 2016 1:35 AM, "Johan Holmquist" <holmisen at gmail.com> wrote:

> The discussion period for this proposal is near (31 of May).
>
> So far I count 1 for and 2 against the proposal.
>
> Joachim Breitner made a good enumeration of some advantages of adding
> these to base. Here is an enumeration of pros:
>
> * Availability in Data.List gives this pattern a common name.
>
> * A common name for this makes code easier to read and decreases the risk
> of getting the definition wrong.
>
> * The argument won't have to be repeated, hence making it easier to chain
> the functions.
>
> * List-fusion potential.
>
>
> Tobias Florek pointed out that `zip <*> tail` can be used to define this
> inline without the need for repeating the argument and made a reference to
> the Fairbairn threshold. This is elegant, but I am afraid that people might
> consider this obscure code golfing if used.
>
> Cheers
> Johan Holmquist
>
>
> ---------- Forwarded message ----------
> From: Henning Thielemann <lemming at henning-thielemann.de>
> Date: 2016-04-13 13:28 GMT+02:00
> Subject: Re: Proposal: Add functions to get consecutive elements to
> Data.List
> To: Johan Holmquist <holmisen at gmail.com>
> Cc: Haskell Libraries <libraries at haskell.org>
>
>
>
> On Wed, 13 Apr 2016, Johan Holmquist wrote:
>
> It is not strictly more general because it cannot handle empty sequences.
>>
>
> Think of it as if it handles the non-[] case.
>
>
> _______________________________________________
> 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/20160519/e655dad7/attachment.html>

From lemming at henning-thielemann.de  Thu May 19 07:15:11 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 19 May 2016 09:15:11 +0200 (CEST)
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
 <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1605190842530.9027@sputnik>


On Thu, 19 May 2016, David Feuer wrote:

> You promised a collection of use cases. I seem to have missed it. Could you send the link again?


I found the following uses in my libraries:

* mapAdjacent subtract
     differences between consecutive elements, inverse of cumulative sum (scanl (+) 0)

* and . mapAdjacent (==)
     check whether all elements in a list are equal

* and . mapAdjacent (<=)
     check whether elements are sorted

* mapAdjacent (/=) . map signum
     find zero crossings

* head . dropWhile (uncurry (/=)) . mapAdjacent (,)
     drop until convergence

* mapAdjacent (\x y -> (snd x, fst y))
     turn list of intervals into list of gaps

* mapAdjacent (,)
     collect state transitions for a Hidden Markov model

* product . mapAdjacent binomial . scanr1 (+)
     compute multinomial coefficient

From lemming at henning-thielemann.de  Thu May 19 07:21:14 2016
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 19 May 2016 09:21:14 +0200 (CEST)
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <alpine.DEB.2.02.1605190842530.9027@sputnik>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
 <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
 <alpine.DEB.2.02.1605190842530.9027@sputnik>
Message-ID: <alpine.DEB.2.02.1605190919150.9027@sputnik>


On Thu, 19 May 2016, Henning Thielemann wrote:

> On Thu, 19 May 2016, David Feuer wrote:
>
>> You promised a collection of use cases. I seem to have missed it. Could you 
>> send the link again?
>
>
> I found the following uses in my libraries:
>
> * mapAdjacent subtract
>    differences between consecutive elements, inverse of cumulative sum 
> (scanl (+) 0)
>
> * and . mapAdjacent (==)
>    check whether all elements in a list are equal
>
> * and . mapAdjacent (<=)
>    check whether elements are sorted
>
> * mapAdjacent (/=) . map signum
>    find zero crossings
>
> * head . dropWhile (uncurry (/=)) . mapAdjacent (,)
>    drop until convergence
>
> * mapAdjacent (\x y -> (snd x, fst y))
>    turn list of intervals into list of gaps
>
> * mapAdjacent (,)
>    collect state transitions for a Hidden Markov model
>
> * product . mapAdjacent binomial . scanr1 (+)
>    compute multinomial coefficient


I found another application: Compute the longest duplicated string.
    https://programmingpraxis.com/2010/12/14/longest-duplicated-substring/

import Data.List
import Data.List.HT (mapAdjacent)
import qualified Data.List.Key as K

lds :: Ord a => [a] -> [a]
lds = K.maximum length . mapAdjacent lcp . sort . tails where
     lcp (x:xs) (y:ys) | x == y = x : lcp xs ys
     lcp _      _               = []

From holmisen at gmail.com  Thu May 19 11:32:42 2016
From: holmisen at gmail.com (Johan Holmquist)
Date: Thu, 19 May 2016 13:32:42 +0200
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
 <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
Message-ID: <CAB_cSPcYfrbvPS6EVo72twfVDuKV39JA-eARX3r=ZV1SRW7vbA@mail.gmail.com>

Also these two were mentioned earlier (using zipConsecutivesWith):

    -- fibonacci:
    fibs = 1 : 1 : zipConsecutivesWith (+) fibs

    -- get the edges of a closed path defined by points (ps):
    edges ps = zipConsecutivesWith makeEdge (ps ++ take 1 ps)

There are two things to decide:

1. Whether this should indeed be added to base (Data.List)
2. What names we should use in case of inclusion in base

The proposed functions are:

    zipConsecutives :: [a] -> [(a,a)]

and

    zipConsecutivesWith :: (a -> a -> b) -> [a] -> [b]

I would not object to some shorter names, such as zipConsecs,
zipConsecsWith etc...

2016-05-19 7:37 GMT+02:00 David Feuer <david.feuer at gmail.com>:

> You promised a collection of use cases. I seem to have missed it. Could
> you send the link again?
> On May 19, 2016 1:35 AM, "Johan Holmquist" <holmisen at gmail.com> wrote:
>
>> The discussion period for this proposal is near (31 of May).
>>
>> So far I count 1 for and 2 against the proposal.
>>
>> Joachim Breitner made a good enumeration of some advantages of adding
>> these to base. Here is an enumeration of pros:
>>
>> * Availability in Data.List gives this pattern a common name.
>>
>> * A common name for this makes code easier to read and decreases the risk
>> of getting the definition wrong.
>>
>> * The argument won't have to be repeated, hence making it easier to chain
>> the functions.
>>
>> * List-fusion potential.
>>
>>
>> Tobias Florek pointed out that `zip <*> tail` can be used to define this
>> inline without the need for repeating the argument and made a reference to
>> the Fairbairn threshold. This is elegant, but I am afraid that people might
>> consider this obscure code golfing if used.
>>
>> Cheers
>> Johan Holmquist
>>
>>
>> ---------- Forwarded message ----------
>> From: Henning Thielemann <lemming at henning-thielemann.de>
>> Date: 2016-04-13 13:28 GMT+02:00
>> Subject: Re: Proposal: Add functions to get consecutive elements to
>> Data.List
>> To: Johan Holmquist <holmisen at gmail.com>
>> Cc: Haskell Libraries <libraries at haskell.org>
>>
>>
>>
>> On Wed, 13 Apr 2016, Johan Holmquist wrote:
>>
>> It is not strictly more general because it cannot handle empty sequences.
>>>
>>
>> Think of it as if it handles the non-[] case.
>>
>>
>> _______________________________________________
>> 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/20160519/f3c1e845/attachment-0001.html>

From david.feuer at gmail.com  Thu May 19 14:00:23 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 19 May 2016 10:00:23 -0400
Subject: Proposal: add full complement of support for decreasing things in
 Data.Map
Message-ID: <CAMgWh9tpacfBBNYutqPHD-8a+GOQPKni5D9kYtBdd-LPtc=NVg@mail.gmail.com>

Data.Map offers functions to convert from ascending lists to maps, and also
offers a function to map an increasing function over the keys of a map.
Equivalents for descending lists and decreasing functions are missing. I
think we should add them. Any objections?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160519/301118c6/attachment.html>

From nickolay.kudasov at gmail.com  Thu May 19 14:40:17 2016
From: nickolay.kudasov at gmail.com (Nickolay Kudasov)
Date: Thu, 19 May 2016 14:40:17 +0000
Subject: Proposal: add full complement of support for decreasing things in
 Data.Map
In-Reply-To: <CAMgWh9tpacfBBNYutqPHD-8a+GOQPKni5D9kYtBdd-LPtc=NVg@mail.gmail.com>
References: <CAMgWh9tpacfBBNYutqPHD-8a+GOQPKni5D9kYtBdd-LPtc=NVg@mail.gmail.com>
Message-ID: <CAF1ivP-7mP8Yonho5PsFXhPN85nHO=ii31d0B-QKon0S-TE4dg@mail.gmail.com>

Hi David,

Can't this be done simply by using Data.Ord.Down wrapper for the keys?

Kind regards,
Nick

On Thu, 19 May 2016 at 17:00 David Feuer <david.feuer at gmail.com> wrote:

> Data.Map offers functions to convert from ascending lists to maps, and
> also offers a function to map an increasing function over the keys of a
> map. Equivalents for descending lists and decreasing functions are missing.
> I think we should add them. Any objections?
> _______________________________________________
> 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/20160519/224d3ef4/attachment.html>

From david.feuer at gmail.com  Thu May 19 14:44:51 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 19 May 2016 10:44:51 -0400
Subject: Proposal: add full complement of support for decreasing things in
 Data.Map
In-Reply-To: <CAF1ivP-7mP8Yonho5PsFXhPN85nHO=ii31d0B-QKon0S-TE4dg@mail.gmail.com>
References: <CAMgWh9tpacfBBNYutqPHD-8a+GOQPKni5D9kYtBdd-LPtc=NVg@mail.gmail.com>
 <CAF1ivP-7mP8Yonho5PsFXhPN85nHO=ii31d0B-QKon0S-TE4dg@mail.gmail.com>
Message-ID: <CAMgWh9vb7XYBZs=M2RaBksKevks=3Gcne=KCu1HWZ8AHDSFASg@mail.gmail.com>

Yes, but no. Once you do that, the whole map is Down. Aside from the
inconvenience factor, such a map can't be combined with one in the usual
order using union, intersection, etc. We could add conversion functions,
but they'd copy the whole structure and really only be special cases of the
hypothetical mapKeysDescending.
On May 19, 2016 10:40 AM, "Nickolay Kudasov" <nickolay.kudasov at gmail.com>
wrote:

> Hi David,
>
> Can't this be done simply by using Data.Ord.Down wrapper for the keys?
>
> Kind regards,
> Nick
>
> On Thu, 19 May 2016 at 17:00 David Feuer <david.feuer at gmail.com> wrote:
>
>> Data.Map offers functions to convert from ascending lists to maps, and
>> also offers a function to map an increasing function over the keys of a
>> map. Equivalents for descending lists and decreasing functions are missing.
>> I think we should add them. Any objections?
>> _______________________________________________
>> 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/20160519/3b69b24d/attachment.html>

From nickolay.kudasov at gmail.com  Thu May 19 14:48:22 2016
From: nickolay.kudasov at gmail.com (Nickolay Kudasov)
Date: Thu, 19 May 2016 14:48:22 +0000
Subject: Proposal: add full complement of support for decreasing things in
 Data.Map
In-Reply-To: <CAMgWh9vb7XYBZs=M2RaBksKevks=3Gcne=KCu1HWZ8AHDSFASg@mail.gmail.com>
References: <CAMgWh9tpacfBBNYutqPHD-8a+GOQPKni5D9kYtBdd-LPtc=NVg@mail.gmail.com>
 <CAF1ivP-7mP8Yonho5PsFXhPN85nHO=ii31d0B-QKon0S-TE4dg@mail.gmail.com>
 <CAMgWh9vb7XYBZs=M2RaBksKevks=3Gcne=KCu1HWZ8AHDSFASg@mail.gmail.com>
Message-ID: <CAF1ivP9U=ZEOZh9YkZth5oLz78zj2HdCtDmU6d4pi19Bq=WPnQ@mail.gmail.com>

I see, thank you for clarification!

Kind regards,
Nick

On Thu, 19 May 2016 at 17:44 David Feuer <david.feuer at gmail.com> wrote:

> Yes, but no. Once you do that, the whole map is Down. Aside from the
> inconvenience factor, such a map can't be combined with one in the usual
> order using union, intersection, etc. We could add conversion functions,
> but they'd copy the whole structure and really only be special cases of the
> hypothetical mapKeysDescending.
> On May 19, 2016 10:40 AM, "Nickolay Kudasov" <nickolay.kudasov at gmail.com>
> wrote:
>
>> Hi David,
>>
>> Can't this be done simply by using Data.Ord.Down wrapper for the keys?
>>
>> Kind regards,
>> Nick
>>
>> On Thu, 19 May 2016 at 17:00 David Feuer <david.feuer at gmail.com> wrote:
>>
>>> Data.Map offers functions to convert from ascending lists to maps, and
>>> also offers a function to map an increasing function over the keys of a
>>> map. Equivalents for descending lists and decreasing functions are missing.
>>> I think we should add them. Any objections?
>>> _______________________________________________
>>> 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/20160519/308be000/attachment.html>

From tanuki at gmail.com  Thu May 19 18:33:50 2016
From: tanuki at gmail.com (Theodore Lief Gannon)
Date: Thu, 19 May 2016 11:33:50 -0700
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CAB_cSPcYfrbvPS6EVo72twfVDuKV39JA-eARX3r=ZV1SRW7vbA@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
 <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
 <CAB_cSPcYfrbvPS6EVo72twfVDuKV39JA-eARX3r=ZV1SRW7vbA@mail.gmail.com>
Message-ID: <CAJoPsuDAq1aqiJ6th6pMNv+872RnYwb97zWCu5KWvMJzz8-5xA@mail.gmail.com>

Whoops, responded privately (and also made a mistake I wanted to correct,
so I guess that works out). To the list this time:

I don't like using the 'zip' terminology here; I feel like that should be
reserved for multiple distinct data sources.

Why not 'map2'?

On Thu, May 19, 2016 at 4:32 AM, Johan Holmquist <holmisen at gmail.com> wrote:

> Also these two were mentioned earlier (using zipConsecutivesWith):
>
>     -- fibonacci:
>     fibs = 1 : 1 : zipConsecutivesWith (+) fibs
>
>     -- get the edges of a closed path defined by points (ps):
>     edges ps = zipConsecutivesWith makeEdge (ps ++ take 1 ps)
>
> There are two things to decide:
>
> 1. Whether this should indeed be added to base (Data.List)
> 2. What names we should use in case of inclusion in base
>
> The proposed functions are:
>
>     zipConsecutives :: [a] -> [(a,a)]
>
> and
>
>     zipConsecutivesWith :: (a -> a -> b) -> [a] -> [b]
>
> I would not object to some shorter names, such as zipConsecs,
> zipConsecsWith etc...
>
> 2016-05-19 7:37 GMT+02:00 David Feuer <david.feuer at gmail.com>:
>
>> You promised a collection of use cases. I seem to have missed it. Could
>> you send the link again?
>> On May 19, 2016 1:35 AM, "Johan Holmquist" <holmisen at gmail.com> wrote:
>>
>>> The discussion period for this proposal is near (31 of May).
>>>
>>> So far I count 1 for and 2 against the proposal.
>>>
>>> Joachim Breitner made a good enumeration of some advantages of adding
>>> these to base. Here is an enumeration of pros:
>>>
>>> * Availability in Data.List gives this pattern a common name.
>>>
>>> * A common name for this makes code easier to read and decreases the
>>> risk of getting the definition wrong.
>>>
>>> * The argument won't have to be repeated, hence making it easier to
>>> chain the functions.
>>>
>>> * List-fusion potential.
>>>
>>>
>>> Tobias Florek pointed out that `zip <*> tail` can be used to define this
>>> inline without the need for repeating the argument and made a reference to
>>> the Fairbairn threshold. This is elegant, but I am afraid that people might
>>> consider this obscure code golfing if used.
>>>
>>> Cheers
>>> Johan Holmquist
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Henning Thielemann <lemming at henning-thielemann.de>
>>> Date: 2016-04-13 13:28 GMT+02:00
>>> Subject: Re: Proposal: Add functions to get consecutive elements to
>>> Data.List
>>> To: Johan Holmquist <holmisen at gmail.com>
>>> Cc: Haskell Libraries <libraries at haskell.org>
>>>
>>>
>>>
>>> On Wed, 13 Apr 2016, Johan Holmquist wrote:
>>>
>>> It is not strictly more general because it cannot handle empty sequences.
>>>>
>>>
>>> Think of it as if it handles the non-[] case.
>>>
>>>
>>> _______________________________________________
>>> 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/20160519/7ab13fa5/attachment-0001.html>

From david.feuer at gmail.com  Thu May 19 18:38:11 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 19 May 2016 14:38:11 -0400
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CAJoPsuDAq1aqiJ6th6pMNv+872RnYwb97zWCu5KWvMJzz8-5xA@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
 <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
 <CAB_cSPcYfrbvPS6EVo72twfVDuKV39JA-eARX3r=ZV1SRW7vbA@mail.gmail.com>
 <CAJoPsuDAq1aqiJ6th6pMNv+872RnYwb97zWCu5KWvMJzz8-5xA@mail.gmail.com>
Message-ID: <CAMgWh9uPLjJJuHCyLFhoKkzHf_w+kY9X=0zjRR6Av_hS9BdP3w@mail.gmail.com>

I think I like mapPairwise. And I really will try to get a proper list
fusion implementation for this if it goes in. The rewrite-back rules are
always a bit of a pain.
On May 19, 2016 2:34 PM, "Theodore Lief Gannon" <tanuki at gmail.com> wrote:

> Whoops, responded privately (and also made a mistake I wanted to correct,
> so I guess that works out). To the list this time:
>
> I don't like using the 'zip' terminology here; I feel like that should be
> reserved for multiple distinct data sources.
>
> Why not 'map2'?
>
> On Thu, May 19, 2016 at 4:32 AM, Johan Holmquist <holmisen at gmail.com>
> wrote:
>
>> Also these two were mentioned earlier (using zipConsecutivesWith):
>>
>>     -- fibonacci:
>>     fibs = 1 : 1 : zipConsecutivesWith (+) fibs
>>
>>     -- get the edges of a closed path defined by points (ps):
>>     edges ps = zipConsecutivesWith makeEdge (ps ++ take 1 ps)
>>
>> There are two things to decide:
>>
>> 1. Whether this should indeed be added to base (Data.List)
>> 2. What names we should use in case of inclusion in base
>>
>> The proposed functions are:
>>
>>     zipConsecutives :: [a] -> [(a,a)]
>>
>> and
>>
>>     zipConsecutivesWith :: (a -> a -> b) -> [a] -> [b]
>>
>> I would not object to some shorter names, such as zipConsecs,
>> zipConsecsWith etc...
>>
>> 2016-05-19 7:37 GMT+02:00 David Feuer <david.feuer at gmail.com>:
>>
>>> You promised a collection of use cases. I seem to have missed it. Could
>>> you send the link again?
>>> On May 19, 2016 1:35 AM, "Johan Holmquist" <holmisen at gmail.com> wrote:
>>>
>>>> The discussion period for this proposal is near (31 of May).
>>>>
>>>> So far I count 1 for and 2 against the proposal.
>>>>
>>>> Joachim Breitner made a good enumeration of some advantages of adding
>>>> these to base. Here is an enumeration of pros:
>>>>
>>>> * Availability in Data.List gives this pattern a common name.
>>>>
>>>> * A common name for this makes code easier to read and decreases the
>>>> risk of getting the definition wrong.
>>>>
>>>> * The argument won't have to be repeated, hence making it easier to
>>>> chain the functions.
>>>>
>>>> * List-fusion potential.
>>>>
>>>>
>>>> Tobias Florek pointed out that `zip <*> tail` can be used to define
>>>> this inline without the need for repeating the argument and made a
>>>> reference to the Fairbairn threshold. This is elegant, but I am afraid that
>>>> people might consider this obscure code golfing if used.
>>>>
>>>> Cheers
>>>> Johan Holmquist
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Henning Thielemann <lemming at henning-thielemann.de>
>>>> Date: 2016-04-13 13:28 GMT+02:00
>>>> Subject: Re: Proposal: Add functions to get consecutive elements to
>>>> Data.List
>>>> To: Johan Holmquist <holmisen at gmail.com>
>>>> Cc: Haskell Libraries <libraries at haskell.org>
>>>>
>>>>
>>>>
>>>> On Wed, 13 Apr 2016, Johan Holmquist wrote:
>>>>
>>>> It is not strictly more general because it cannot handle empty
>>>>> sequences.
>>>>>
>>>>
>>>> Think of it as if it handles the non-[] case.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/20160519/ab05f3c1/attachment.html>

From spam at scientician.net  Thu May 19 18:43:58 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Thu, 19 May 2016 20:43:58 +0200
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
Message-ID: <nhl1he$ljr$1@ger.gmane.org>

On 05/19/2016 07:27 AM, Johan Holmquist wrote:
> The discussion period for this proposal is near (31 of May).
> 

+1.



From ekmett at gmail.com  Thu May 19 18:48:27 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 19 May 2016 14:48:27 -0400
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CAMgWh9uPLjJJuHCyLFhoKkzHf_w+kY9X=0zjRR6Av_hS9BdP3w@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
 <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
 <CAB_cSPcYfrbvPS6EVo72twfVDuKV39JA-eARX3r=ZV1SRW7vbA@mail.gmail.com>
 <CAJoPsuDAq1aqiJ6th6pMNv+872RnYwb97zWCu5KWvMJzz8-5xA@mail.gmail.com>
 <CAMgWh9uPLjJJuHCyLFhoKkzHf_w+kY9X=0zjRR6Av_hS9BdP3w@mail.gmail.com>
Message-ID: <CAJumaK9e9oBEjbvLWON+6=wakO++6c-GFGOL9khcvWSgVRFH8w@mail.gmail.com>

I'm personally a weak -1 on adding a mapAdjacent combinator.

Ultimately

length "mapAdjacent" == length "ap zip tail"

and there are all the silly nearby functions that sound like they'd want
similar names that would use things like:

mapPairwise f (a:b:cs) = f a b:mapPairwise f cs

or

mapPairwise f (a:bcs@(b:cs)) = f a b:mapPairwise f bcs

leading to some confusion, and forcing you to read the docs to figure out
what the function does.

-Edward

On Thu, May 19, 2016 at 2:38 PM, David Feuer <david.feuer at gmail.com> wrote:

> I think I like mapPairwise. And I really will try to get a proper list
> fusion implementation for this if it goes in. The rewrite-back rules are
> always a bit of a pain.
> On May 19, 2016 2:34 PM, "Theodore Lief Gannon" <tanuki at gmail.com> wrote:
>
>> Whoops, responded privately (and also made a mistake I wanted to correct,
>> so I guess that works out). To the list this time:
>>
>> I don't like using the 'zip' terminology here; I feel like that should be
>> reserved for multiple distinct data sources.
>>
>> Why not 'map2'?
>>
>> On Thu, May 19, 2016 at 4:32 AM, Johan Holmquist <holmisen at gmail.com>
>> wrote:
>>
>>> Also these two were mentioned earlier (using zipConsecutivesWith):
>>>
>>>     -- fibonacci:
>>>     fibs = 1 : 1 : zipConsecutivesWith (+) fibs
>>>
>>>     -- get the edges of a closed path defined by points (ps):
>>>     edges ps = zipConsecutivesWith makeEdge (ps ++ take 1 ps)
>>>
>>> There are two things to decide:
>>>
>>> 1. Whether this should indeed be added to base (Data.List)
>>> 2. What names we should use in case of inclusion in base
>>>
>>> The proposed functions are:
>>>
>>>     zipConsecutives :: [a] -> [(a,a)]
>>>
>>> and
>>>
>>>     zipConsecutivesWith :: (a -> a -> b) -> [a] -> [b]
>>>
>>> I would not object to some shorter names, such as zipConsecs,
>>> zipConsecsWith etc...
>>>
>>> 2016-05-19 7:37 GMT+02:00 David Feuer <david.feuer at gmail.com>:
>>>
>>>> You promised a collection of use cases. I seem to have missed it. Could
>>>> you send the link again?
>>>> On May 19, 2016 1:35 AM, "Johan Holmquist" <holmisen at gmail.com> wrote:
>>>>
>>>>> The discussion period for this proposal is near (31 of May).
>>>>>
>>>>> So far I count 1 for and 2 against the proposal.
>>>>>
>>>>> Joachim Breitner made a good enumeration of some advantages of adding
>>>>> these to base. Here is an enumeration of pros:
>>>>>
>>>>> * Availability in Data.List gives this pattern a common name.
>>>>>
>>>>> * A common name for this makes code easier to read and decreases the
>>>>> risk of getting the definition wrong.
>>>>>
>>>>> * The argument won't have to be repeated, hence making it easier to
>>>>> chain the functions.
>>>>>
>>>>> * List-fusion potential.
>>>>>
>>>>>
>>>>> Tobias Florek pointed out that `zip <*> tail` can be used to define
>>>>> this inline without the need for repeating the argument and made a
>>>>> reference to the Fairbairn threshold. This is elegant, but I am afraid that
>>>>> people might consider this obscure code golfing if used.
>>>>>
>>>>> Cheers
>>>>> Johan Holmquist
>>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Henning Thielemann <lemming at henning-thielemann.de>
>>>>> Date: 2016-04-13 13:28 GMT+02:00
>>>>> Subject: Re: Proposal: Add functions to get consecutive elements to
>>>>> Data.List
>>>>> To: Johan Holmquist <holmisen at gmail.com>
>>>>> Cc: Haskell Libraries <libraries at haskell.org>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 13 Apr 2016, Johan Holmquist wrote:
>>>>>
>>>>> It is not strictly more general because it cannot handle empty
>>>>>> sequences.
>>>>>>
>>>>>
>>>>> Think of it as if it handles the non-[] case.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20160519/602e30d8/attachment-0001.html>

From spam at scientician.net  Thu May 19 18:44:56 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Thu, 19 May 2016 20:44:56 +0200
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CAMgWh9uPLjJJuHCyLFhoKkzHf_w+kY9X=0zjRR6Av_hS9BdP3w@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
 <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
 <CAB_cSPcYfrbvPS6EVo72twfVDuKV39JA-eARX3r=ZV1SRW7vbA@mail.gmail.com>
 <CAJoPsuDAq1aqiJ6th6pMNv+872RnYwb97zWCu5KWvMJzz8-5xA@mail.gmail.com>
 <CAMgWh9uPLjJJuHCyLFhoKkzHf_w+kY9X=0zjRR6Av_hS9BdP3w@mail.gmail.com>
Message-ID: <nhl1j8$ljr$2@ger.gmane.org>

On 05/19/2016 08:38 PM, David Feuer wrote:
> I think I like mapPairwise. And I really will try to get a proper list
> fusion implementation for this if it goes in. The rewrite-back rules are
> always a bit of a pain.
> 

Another name option might be to use "mapAdjacent" or similar. (Though
actually, perhaps "pairwise" is more descriptive.)

Regards,


From david.feuer at gmail.com  Fri May 20 00:30:32 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 19 May 2016 20:30:32 -0400
Subject: Argument order for Data.Map.adjustF
In-Reply-To: <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>
References: <CAMgWh9uwMyynxi1jDcF_NUuGvjzdCK+RQs+SoRMBo2YHjDR-LQ@mail.gmail.com>
 <CAMgWh9vjeKneS1uBvxTq5HiY0AW5SqDTCBrBXXQn=FHPB6cTqw@mail.gmail.com>
 <CAMgWh9s-c6Qv5Vg8=uH_GZUdzkpR9frARKv4aqqmifC2VaEYFw@mail.gmail.com>
 <CAMgWh9thB=W=MjJ2hZV9JBestT0foHCFDM79TUr94Nakgi76Og@mail.gmail.com>
 <CAMgWh9tgx5fznJugL02hRA=sJ7t95PPBOF6h59MzW2htd=RqHg@mail.gmail.com>
 <CAMgWh9tpyJX5qOmCCsgcUyi6_U=fYzasTSxG8j8FMA5HtnsRYA@mail.gmail.com>
 <CAMgWh9vpO4mYnV6ZDMpcdatNhv4YXOiN=5O8CH+6Q-7Qt73p4g@mail.gmail.com>
 <CAMgWh9vOZtj+jjCZ-J8b8vY9Sb+zPS0CxTfvMZomZUtMHVkQow@mail.gmail.com>
 <CAMgWh9v8k09wZNE_4aLPZ=4RCWbtcsLCfooW2aQ01GhLQg-jbw@mail.gmail.com>
 <CAMgWh9s7vznNi1zgjj5ygAm0dFWSz6ftVkRiA-8uSPbhUUBD+w@mail.gmail.com>
 <CAMgWh9vedG_vLc-BHu-46gW53aJWZ9WPTxyxk21D4Bdt1wr=+Q@mail.gmail.com>
 <CAMgWh9ssA3vxBitszDSZr3=4ppDzMXchNJh5q_Nn-DoRMr+K8Q@mail.gmail.com>
 <CAMgWh9tR2GVF0MfgnOHDW+YugAvb1iJb7MrfMQjc0dk-jZ0J1w@mail.gmail.com>
 <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>
Message-ID: <CAMgWh9vK9p3Bg5ydjPQoy-0iDRtZyn0oXmsFFoT9Rnr-=gr8XQ@mail.gmail.com>

Wren Romano and I have decided to maintain consistency in the argument
order, even though this is more annoying for people using lens. Thus

alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k
a -> f (Map k a)

and `Control.Lens.At.at` for maps can be implemented as

at = flip Data.Map.Lazy.alterF

Note that Data.Map.Strict will also offer a version of alterF that
forces any values it installs in the map.


On Sat, May 7, 2016 at 4:45 PM, David Feuer <david.feuer at gmail.com> wrote:
> I managed to find an implementation of Control.Lens.At.at for Data.Map
> that's fast enough to be useful. The function will be named alterF to match
> the name of Data.Map.alter. The remaining question is what order the
> arguments should go in. I had thought to follow those of alter for
> consistency, giving
>
> alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k a ->
> f (Map k a)
>
> Edward Kmett thinks the ergonomics of that order are terrible, and prefers
> to follow lens at, giving
>
> alterF :: (Functor f, Ord k) => k -> (Maybe a -> f (Maybe a)) -> Map k a ->
> f (Map k a)
>
> How do other people feel about this?
>
> David Feuer

From ekmett at gmail.com  Fri May 20 04:48:09 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 20 May 2016 00:48:09 -0400
Subject: Argument order for Data.Map.adjustF
In-Reply-To: <CAMgWh9vK9p3Bg5ydjPQoy-0iDRtZyn0oXmsFFoT9Rnr-=gr8XQ@mail.gmail.com>
References: <CAMgWh9uwMyynxi1jDcF_NUuGvjzdCK+RQs+SoRMBo2YHjDR-LQ@mail.gmail.com>
 <CAMgWh9vjeKneS1uBvxTq5HiY0AW5SqDTCBrBXXQn=FHPB6cTqw@mail.gmail.com>
 <CAMgWh9s-c6Qv5Vg8=uH_GZUdzkpR9frARKv4aqqmifC2VaEYFw@mail.gmail.com>
 <CAMgWh9thB=W=MjJ2hZV9JBestT0foHCFDM79TUr94Nakgi76Og@mail.gmail.com>
 <CAMgWh9tgx5fznJugL02hRA=sJ7t95PPBOF6h59MzW2htd=RqHg@mail.gmail.com>
 <CAMgWh9tpyJX5qOmCCsgcUyi6_U=fYzasTSxG8j8FMA5HtnsRYA@mail.gmail.com>
 <CAMgWh9vpO4mYnV6ZDMpcdatNhv4YXOiN=5O8CH+6Q-7Qt73p4g@mail.gmail.com>
 <CAMgWh9vOZtj+jjCZ-J8b8vY9Sb+zPS0CxTfvMZomZUtMHVkQow@mail.gmail.com>
 <CAMgWh9v8k09wZNE_4aLPZ=4RCWbtcsLCfooW2aQ01GhLQg-jbw@mail.gmail.com>
 <CAMgWh9s7vznNi1zgjj5ygAm0dFWSz6ftVkRiA-8uSPbhUUBD+w@mail.gmail.com>
 <CAMgWh9vedG_vLc-BHu-46gW53aJWZ9WPTxyxk21D4Bdt1wr=+Q@mail.gmail.com>
 <CAMgWh9ssA3vxBitszDSZr3=4ppDzMXchNJh5q_Nn-DoRMr+K8Q@mail.gmail.com>
 <CAMgWh9tR2GVF0MfgnOHDW+YugAvb1iJb7MrfMQjc0dk-jZ0J1w@mail.gmail.com>
 <CAMgWh9vWf-dBnfxAbJXCGiWRuFcpvaOfKE4iaG_m8K3aSeJrnA@mail.gmail.com>
 <CAMgWh9vK9p3Bg5ydjPQoy-0iDRtZyn0oXmsFFoT9Rnr-=gr8XQ@mail.gmail.com>
Message-ID: <CAJumaK-Misxz0_V43e+RwLaYCm366gdfVEsVD=YK9dXC9xhXAA@mail.gmail.com>

Fair enough.

-Edward

On Thu, May 19, 2016 at 8:30 PM, David Feuer <david.feuer at gmail.com> wrote:

> Wren Romano and I have decided to maintain consistency in the argument
> order, even though this is more annoying for people using lens. Thus
>
> alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k
> a -> f (Map k a)
>
> and `Control.Lens.At.at` for maps can be implemented as
>
> at = flip Data.Map.Lazy.alterF
>
> Note that Data.Map.Strict will also offer a version of alterF that
> forces any values it installs in the map.
>
>
> On Sat, May 7, 2016 at 4:45 PM, David Feuer <david.feuer at gmail.com> wrote:
> > I managed to find an implementation of Control.Lens.At.at for Data.Map
> > that's fast enough to be useful. The function will be named alterF to
> match
> > the name of Data.Map.alter. The remaining question is what order the
> > arguments should go in. I had thought to follow those of alter for
> > consistency, giving
> >
> > alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k a
> ->
> > f (Map k a)
> >
> > Edward Kmett thinks the ergonomics of that order are terrible, and
> prefers
> > to follow lens at, giving
> >
> > alterF :: (Functor f, Ord k) => k -> (Maybe a -> f (Maybe a)) -> Map k a
> ->
> > f (Map k a)
> >
> > How do other people feel about this?
> >
> > David Feuer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160520/27aca5a0/attachment.html>

From winterkoninkje at gmail.com  Fri May 20 05:00:49 2016
From: winterkoninkje at gmail.com (wren romano)
Date: Fri, 20 May 2016 01:00:49 -0400
Subject: Proposal: add full complement of support for decreasing things in
 Data.Map
In-Reply-To: <CAMgWh9tpacfBBNYutqPHD-8a+GOQPKni5D9kYtBdd-LPtc=NVg@mail.gmail.com>
References: <CAMgWh9tpacfBBNYutqPHD-8a+GOQPKni5D9kYtBdd-LPtc=NVg@mail.gmail.com>
Message-ID: <CABUjdS6Myaat_TddYDta==SBUaZ+9O7SRMy=EZknc0NHybc_MA@mail.gmail.com>

On Thu, May 19, 2016 at 10:00 AM, David Feuer <david.feuer at gmail.com> wrote:
> Data.Map offers functions to convert from ascending lists to maps, and also
> offers a function to map an increasing function over the keys of a map.
> Equivalents for descending lists and decreasing functions are missing. I
> think we should add them. Any objections?

+1.

They're a lot more performant to do directly rather than (a) reversing
the ascending lists, or (b) constructing the mirror image (Map (Down
k) a) so that "ascending" is in the right order.

-- 
Live well,
~wren

From winterkoninkje at gmail.com  Fri May 20 05:27:09 2016
From: winterkoninkje at gmail.com (wren romano)
Date: Fri, 20 May 2016 01:27:09 -0400
Subject: Proposal reminder: Add functions to get consecutive elements to
 Data.List
In-Reply-To: <CAJoPsuDAq1aqiJ6th6pMNv+872RnYwb97zWCu5KWvMJzz8-5xA@mail.gmail.com>
References: <CAB_cSPcHNGEhOYH-ueEBK9oB7VTjLZXpKXXA_RR1n+HObmHEkA@mail.gmail.com>
 <CAMgWh9sYyBhN9f-wyCzt2Wu-mxRDj5q762x+gg9SmKcJacHK6A@mail.gmail.com>
 <CAB_cSPcYfrbvPS6EVo72twfVDuKV39JA-eARX3r=ZV1SRW7vbA@mail.gmail.com>
 <CAJoPsuDAq1aqiJ6th6pMNv+872RnYwb97zWCu5KWvMJzz8-5xA@mail.gmail.com>
Message-ID: <CABUjdS4GACtbUitJ_zkxGGAAGF-xKY-QetQiaUMT3FbWq1ZRMQ@mail.gmail.com>

On Thu, May 19, 2016 at 2:33 PM, Theodore Lief Gannon <tanuki at gmail.com> wrote:
> Whoops, responded privately (and also made a mistake I wanted to correct, so
> I guess that works out). To the list this time:
>
> I don't like using the 'zip' terminology here; I feel like that should be
> reserved for multiple distinct data sources.
>
> Why not 'map2'?

I too dislike the "zip" terminology here, for the same reason. But I
also I mislike "map" since this isn't functorial in any particular way
(I'd expect "map2" to have to do with some sort of 2-functors).

I'm agnostic on adding the function vs not, but If we're bikeshedding
for short names how about "twine"? (The problem I see with "pairwise"
is that it's ambiguous about whether values get "reused": i.e.,
matching even elements to odds[1], vs matching every element to the
next/last.)

[1] I also note without comment that this interpretation is the
inverse to what is traditionally called "zip" in the non-wellfounded
set theory community; e.g., when viewing streams (like the Thue?Morse
sequence) as a greatest solution to a system of equations.

-- 
Live well,
~wren

From david.feuer at gmail.com  Fri May 20 17:20:41 2016
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 20 May 2016 13:20:41 -0400
Subject: Proposal: add foldMapWithIndex to Data.Sequence
In-Reply-To: <CAMgWh9u0km8AY40id49KxiD-hoYO=gPbddM47SDqW0wZ=XGLaA@mail.gmail.com>
References: <CAMgWh9tWBgNu2b18xxKMRX47Yz-HzHJTPeTcJM1OSVi2GJnhcw@mail.gmail.com>
 <CAMgWh9v8gtRd6dBBQk9hD6qge7fVOJ+uSScVDhXnCcPpybjoDg@mail.gmail.com>
 <CAMgWh9vqgWip=Rwuom+wFdKPYzkzb_wCt+1Pmvkiiwnh4Ghbyw@mail.gmail.com>
 <CAMgWh9usC2Hc+uKi=0ZagA9Qns2uupkkjXAOatmSBd4UAuikSw@mail.gmail.com>
 <CAMgWh9sPW13wgQaktAkQA0S6jLaYsoTc2cSX8x906A+z7seacA@mail.gmail.com>
 <CAMgWh9uz=WCHLHTdv6hqEnMZxxcydszvDhOL8PLS463YSARUtQ@mail.gmail.com>
 <CAMgWh9tPGQMAoZniN5LKXta88jTJgpMgFUwLeqF7zejmZ7hTKg@mail.gmail.com>
 <CAMgWh9sR2nxj0y_u135FWutxcRbubZdNpP7cQjj=51ZK0r_d8w@mail.gmail.com>
 <CAMgWh9uz5M8MhdUYR9NDnKaWJ7b=2-2W2COfFXc1WQ3Lj==t5Q@mail.gmail.com>
 <CAMgWh9u0km8AY40id49KxiD-hoYO=gPbddM47SDqW0wZ=XGLaA@mail.gmail.com>
Message-ID: <CAMgWh9vRigkOvvgbnOD+owJ5EjncfOdiDCw=XhFGM-hdAuGzXw@mail.gmail.com>

foldMapWithIndex :: Monoid m
     => (Int -> a -> m) -> Seq a -> m

This would match both Data.Map.foldMapWithKey and
Control.Lens.Indexed.ifoldMap, filling out the indexed fold menagerie.

Annoyingly, the straightforward implementation I've come up with is rather
slow when used with Endo to implement either foldlWithIndex or
foldrWithIndex. I suspect the polymorphic recursion inherent in these
sequences is blinding GHC's optimizer. Oh well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160520/dbf6b77f/attachment.html>

From anfelor at posteo.de  Fri May 20 20:08:40 2016
From: anfelor at posteo.de (Anton Felix Lorenzen)
Date: Fri, 20 May 2016 22:08:40 +0200
Subject: Proposal: add fromRight and fromLeft to Data.Either
Message-ID: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>

When working with Either,
I am often missing two simple functions:
fromRight :: Either a b -> b
fromLeft  :: Either a b -> a

It has been implemented a couple of times:
http://hayoo.fh-wedel.de/?query=fromRight

But I don't want to depend on yet another library
for such a basic function.

Could it be added?

Anton

From qdunkan at gmail.com  Fri May 20 20:17:20 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Fri, 20 May 2016 13:17:20 -0700
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
Message-ID: <CACbaDy4LhT5B3MQ=ProRAVUGt9buw-e+m_M+4d7z-nkt-aA9Yg@mail.gmail.com>

I wouldn't want to encourage partial functions without even an error
message.  Usually with Either you'll want to use the unexpected value in
the error msg, e.g 'either (error . ("xyz: "++) . show) id'.

On Fri, May 20, 2016 at 1:08 PM, Anton Felix Lorenzen <anfelor at posteo.de>
wrote:

> When working with Either,
> I am often missing two simple functions:
> fromRight :: Either a b -> b
> fromLeft  :: Either a b -> a
>
> It has been implemented a couple of times:
> http://hayoo.fh-wedel.de/?query=fromRight
>
> But I don't want to depend on yet another library
> for such a basic function.
>
> Could it be added?
>
> Anton
> _______________________________________________
> 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/20160520/ed5d219d/attachment.html>

From david.feuer at gmail.com  Fri May 20 20:34:53 2016
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 20 May 2016 16:34:53 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
Message-ID: <CAMgWh9uCa83SCboqd5M+W+ZUh4YBJkc3PUNOjSvY5fgx37JnEQ@mail.gmail.com>

-1. I don't want to encourage this sort of bad coding practice practice
either. Keeping it inconvenient is fine by me.
On May 20, 2016 4:08 PM, "Anton Felix Lorenzen" <anfelor at posteo.de> wrote:

> When working with Either,
> I am often missing two simple functions:
> fromRight :: Either a b -> b
> fromLeft  :: Either a b -> a
>
> It has been implemented a couple of times:
> http://hayoo.fh-wedel.de/?query=fromRight
>
> But I don't want to depend on yet another library
> for such a basic function.
>
> Could it be added?
>
> Anton
> _______________________________________________
> 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/20160520/c784e488/attachment.html>

From danburton.email at gmail.com  Fri May 20 21:25:25 2016
From: danburton.email at gmail.com (Dan Burton)
Date: Fri, 20 May 2016 14:25:25 -0700
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CAMgWh9uCa83SCboqd5M+W+ZUh4YBJkc3PUNOjSvY5fgx37JnEQ@mail.gmail.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAMgWh9uCa83SCboqd5M+W+ZUh4YBJkc3PUNOjSvY5fgx37JnEQ@mail.gmail.com>
Message-ID: <CALSygwdOWtaKT_8wcEhZz62Uyhe-hLwfrLYHeUbmNmr5JXXhng@mail.gmail.com>

I wouldn't mind something like this being available... but only if prefixed
with the word "unsafe" or "partial" or other such scary words.

-- Dan Burton

On Fri, May 20, 2016 at 1:34 PM, David Feuer <david.feuer at gmail.com> wrote:

> -1. I don't want to encourage this sort of bad coding practice practice
> either. Keeping it inconvenient is fine by me.
> On May 20, 2016 4:08 PM, "Anton Felix Lorenzen" <anfelor at posteo.de> wrote:
>
>> When working with Either,
>> I am often missing two simple functions:
>> fromRight :: Either a b -> b
>> fromLeft  :: Either a b -> a
>>
>> It has been implemented a couple of times:
>> http://hayoo.fh-wedel.de/?query=fromRight
>>
>> But I don't want to depend on yet another library
>> for such a basic function.
>>
>> Could it be added?
>>
>> Anton
>> _______________________________________________
>> 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/20160520/89891ab7/attachment.html>

From _deepfire at feelingofgreen.ru  Fri May 20 21:36:20 2016
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Sat, 21 May 2016 00:36:20 +0300
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CALSygwdOWtaKT_8wcEhZz62Uyhe-hLwfrLYHeUbmNmr5JXXhng@mail.gmail.com>
 (sfid-20160521_015749_888764_DC2178F6) (Dan Burton's message of "Fri,
 20 May 2016 14:25:25 -0700")
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAMgWh9uCa83SCboqd5M+W+ZUh4YBJkc3PUNOjSvY5fgx37JnEQ@mail.gmail.com>
 <CALSygwdOWtaKT_8wcEhZz62Uyhe-hLwfrLYHeUbmNmr5JXXhng@mail.gmail.com>
Message-ID: <87y474fm3v.fsf@feelingofgreen.ru>

Dan Burton <danburton.email at gmail.com> writes:
> I wouldn't mind something like this being available... but only if
> prefixed with the word "unsafe" or "partial" or other such scary
> words.

Heh, `unsafePerformLeft` / `unsafePerformRight` ? : -)

-- 
? ???????e? / respectfully,
??????? ??????

From tanuki at gmail.com  Fri May 20 22:42:55 2016
From: tanuki at gmail.com (Theodore Lief Gannon)
Date: Fri, 20 May 2016 15:42:55 -0700
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <87y474fm3v.fsf@feelingofgreen.ru>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAMgWh9uCa83SCboqd5M+W+ZUh4YBJkc3PUNOjSvY5fgx37JnEQ@mail.gmail.com>
 <CALSygwdOWtaKT_8wcEhZz62Uyhe-hLwfrLYHeUbmNmr5JXXhng@mail.gmail.com>
 <87y474fm3v.fsf@feelingofgreen.ru>
Message-ID: <CAJoPsuCF-MQJdpqsqpiDCUFGQoxVxGgYJwegViM=Htbk3e07Lw@mail.gmail.com>

js :: a -> (Void, a)
js x = (undefined, x)

left :: (Void, Either a b) -> a
left (_, Left x) = x

There we go... now it looks truly terrifying:

left.js $(myValue)


(Apologies to Kosyrev for the double-send. Especially since that version
was broken.)

On Fri, May 20, 2016 at 2:36 PM, Kosyrev Serge <_deepfire at feelingofgreen.ru>
wrote:

> Dan Burton <danburton.email at gmail.com> writes:
> > I wouldn't mind something like this being available... but only if
> > prefixed with the word "unsafe" or "partial" or other such scary
> > words.
>
> Heh, `unsafePerformLeft` / `unsafePerformRight` ? : -)
>
> --
> ? ???????e? / respectfully,
> ??????? ??????
> _______________________________________________
> 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/20160520/5a25c9f5/attachment-0001.html>

From fa-ml at ariis.it  Fri May 20 23:22:36 2016
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sat, 21 May 2016 01:22:36 +0200
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
Message-ID: <20160520232236.GA7426@casa.casa>

On Fri, May 20, 2016 at 10:08:40PM +0200, Anton Felix Lorenzen wrote:
> When working with Either,
> I am often missing two simple functions:
> fromRight :: Either a b -> b
> fromLeft  :: Either a b -> a

Sometimes my lazy inner-self is guilty of longing for `fromRight` when
typing:

    ?> either undefined id xyz

but then again, importing Data.Either wouldn't make thing any shorter :P

    ?> :m +Da<tab>.Ei<tab>
    ?> fromRight zyx


I can see fromRight being useful in one-off script; anything bigger than
a few lines is asking for trouble!


From amindfv at gmail.com  Sat May 21 12:33:45 2016
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Sat, 21 May 2016 08:33:45 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <20160520232236.GA7426@casa.casa>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <20160520232236.GA7426@casa.casa>
Message-ID: <B00EE04F-1FB3-4784-940B-2C50BA38D1ED@gmail.com>

There's also (\(Right x)->x), which is pretty short and will give you a warning about the missing case.

(I could go either way on adding fromLeft/Right though)

Tom


> El 20 may 2016, a las 19:22, Francesco Ariis <fa-ml at ariis.it> escribi?:
> 
>> On Fri, May 20, 2016 at 10:08:40PM +0200, Anton Felix Lorenzen wrote:
>> When working with Either,
>> I am often missing two simple functions:
>> fromRight :: Either a b -> b
>> fromLeft  :: Either a b -> a
> 
> Sometimes my lazy inner-self is guilty of longing for `fromRight` when
> typing:
> 
>    ?> either undefined id xyz
> 
> but then again, importing Data.Either wouldn't make thing any shorter :P
> 
>    ?> :m +Da<tab>.Ei<tab>
>    ?> fromRight zyx
> 
> 
> I can see fromRight being useful in one-off script; anything bigger than
> a few lines is asking for trouble!
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From ekmett at gmail.com  Sat May 21 12:55:09 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 21 May 2016 08:55:09 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
Message-ID: <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>

I'm personally -1 on this.

A large portion of the community is vehemently against adding new partial
functions, and they have to share base with the rest of us. I'd say more
people want to remove fromMaybe, head, tail, etc. than want to double down
on the pattern at this time.

-Edward

On Fri, May 20, 2016 at 4:08 PM, Anton Felix Lorenzen <anfelor at posteo.de>
wrote:

> When working with Either,
> I am often missing two simple functions:
> fromRight :: Either a b -> b
> fromLeft  :: Either a b -> a
>
> It has been implemented a couple of times:
> http://hayoo.fh-wedel.de/?query=fromRight
>
> But I don't want to depend on yet another library
> for such a basic function.
>
> Could it be added?
>
> Anton
> _______________________________________________
> 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/20160521/9cbb0cba/attachment.html>

From david.feuer at gmail.com  Sat May 21 12:58:01 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 21 May 2016 08:58:01 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
Message-ID: <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>

No one wants to remove fromMaybe. In fact, it could serve as a template for
total fromLeft and fromRight:

fromLeft :: b -> (a -> b) -> Either a x -> b
fromRight :: b -> (a -> b) -> Either x a -> b
On May 21, 2016 8:55 AM, "Edward Kmett" <ekmett at gmail.com> wrote:

I'm personally -1 on this.

A large portion of the community is vehemently against adding new partial
functions, and they have to share base with the rest of us. I'd say more
people want to remove fromMaybe, head, tail, etc. than want to double down
on the pattern at this time.

-Edward

On Fri, May 20, 2016 at 4:08 PM, Anton Felix Lorenzen <anfelor at posteo.de>
wrote:

> When working with Either,
> I am often missing two simple functions:
> fromRight :: Either a b -> b
> fromLeft  :: Either a b -> a
>
> It has been implemented a couple of times:
> http://hayoo.fh-wedel.de/?query=fromRight
>
> But I don't want to depend on yet another library
> for such a basic function.
>
> Could it be added?
>
> Anton
> _______________________________________________
> 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/20160521/3cc2294e/attachment.html>

From cma at bitemyapp.com  Sat May 21 13:09:28 2016
From: cma at bitemyapp.com (Christopher Allen)
Date: Sat, 21 May 2016 07:09:28 -0600
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
Message-ID: <51454775-5B24-4DED-92C0-5BDE78E88B99@bitemyapp.com>

I think Edward meant fromJust given the context.

Sent from my iPhone

> On May 21, 2016, at 6:58 AM, David Feuer <david.feuer at gmail.com> wrote:
> 
> No one wants to remove fromMaybe. In fact, it could serve as a template for total fromLeft and fromRight:
> 
> fromLeft :: b -> (a -> b) -> Either a x -> b
> fromRight :: b -> (a -> b) -> Either x a -> b
> 
> On May 21, 2016 8:55 AM, "Edward Kmett" <ekmett at gmail.com> wrote:
> I'm personally -1 on this. 
> 
> A large portion of the community is vehemently against adding new partial functions, and they have to share base with the rest of us. I'd say more people want to remove fromMaybe, head, tail, etc. than want to double down on the pattern at this time.
> 
> -Edward
> 
>> On Fri, May 20, 2016 at 4:08 PM, Anton Felix Lorenzen <anfelor at posteo.de> wrote:
>> When working with Either,
>> I am often missing two simple functions:
>> fromRight :: Either a b -> b
>> fromLeft  :: Either a b -> a
>> 
>> It has been implemented a couple of times:
>> http://hayoo.fh-wedel.de/?query=fromRight
>> 
>> But I don't want to depend on yet another library
>> for such a basic function.
>> 
>> Could it be added?
>> 
>> Anton
>> _______________________________________________
>> 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
> 
> _______________________________________________
> 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/20160521/80701586/attachment.html>

From david.feuer at gmail.com  Sat May 21 13:10:38 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 21 May 2016 09:10:38 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <51454775-5B24-4DED-92C0-5BDE78E88B99@bitemyapp.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <51454775-5B24-4DED-92C0-5BDE78E88B99@bitemyapp.com>
Message-ID: <CAMgWh9suzaGpmCmwBpGg5F0nuzNsqsec2Skzhfk-rtER1v_Zow@mail.gmail.com>

I'm sure he did, but I figured I should take the opportunity to point out
other ways to use those names.
On May 21, 2016 9:09 AM, "Christopher Allen" <cma at bitemyapp.com> wrote:

> I think Edward meant fromJust given the context.
>
> Sent from my iPhone
>
> On May 21, 2016, at 6:58 AM, David Feuer <david.feuer at gmail.com> wrote:
>
> No one wants to remove fromMaybe. In fact, it could serve as a template
> for total fromLeft and fromRight:
>
> fromLeft :: b -> (a -> b) -> Either a x -> b
> fromRight :: b -> (a -> b) -> Either x a -> b
> On May 21, 2016 8:55 AM, "Edward Kmett" <ekmett at gmail.com> wrote:
>
> I'm personally -1 on this.
>
> A large portion of the community is vehemently against adding new partial
> functions, and they have to share base with the rest of us. I'd say more
> people want to remove fromMaybe, head, tail, etc. than want to double down
> on the pattern at this time.
>
> -Edward
>
> On Fri, May 20, 2016 at 4:08 PM, Anton Felix Lorenzen <anfelor at posteo.de>
> wrote:
>
>> When working with Either,
>> I am often missing two simple functions:
>> fromRight :: Either a b -> b
>> fromLeft  :: Either a b -> a
>>
>> It has been implemented a couple of times:
>> http://hayoo.fh-wedel.de/?query=fromRight
>>
>> But I don't want to depend on yet another library
>> for such a basic function.
>>
>> Could it be added?
>>
>> Anton
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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/20160521/0f39e07c/attachment-0001.html>

From ekmett at gmail.com  Sat May 21 13:16:32 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 21 May 2016 09:16:32 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
Message-ID: <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>

Sorry, I meant fromJust.

On Sat, May 21, 2016 at 8:58 AM, David Feuer <david.feuer at gmail.com> wrote:

> No one wants to remove fromMaybe. In fact, it could serve as a template
> for total fromLeft and fromRight:
>
> fromLeft :: b -> (a -> b) -> Either a x -> b
> fromRight :: b -> (a -> b) -> Either x a -> b
> On May 21, 2016 8:55 AM, "Edward Kmett" <ekmett at gmail.com> wrote:
>
> I'm personally -1 on this.
>
> A large portion of the community is vehemently against adding new partial
> functions, and they have to share base with the rest of us. I'd say more
> people want to remove fromMaybe, head, tail, etc. than want to double down
> on the pattern at this time.
>
> -Edward
>
> On Fri, May 20, 2016 at 4:08 PM, Anton Felix Lorenzen <anfelor at posteo.de>
> wrote:
>
>> When working with Either,
>> I am often missing two simple functions:
>> fromRight :: Either a b -> b
>> fromLeft  :: Either a b -> a
>>
>> It has been implemented a couple of times:
>> http://hayoo.fh-wedel.de/?query=fromRight
>>
>> But I don't want to depend on yet another library
>> for such a basic function.
>>
>> Could it be added?
>>
>> Anton
>> _______________________________________________
>> 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/20160521/6c8b340f/attachment.html>

From abela at chalmers.se  Sat May 21 18:06:50 2016
From: abela at chalmers.se (Andreas Abel)
Date: Sat, 21 May 2016 20:06:50 +0200
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
Message-ID: <5740A3BA.10306@chalmers.se>

Ah, yes, we want fromLeft and fromRight, but with types

   fromLeft  :: a -> Either a b -> a
   fromRight :: b -> Either a b -> b

where the first argument is the "default", like

   fromLeft a (Right b) = a

Then you can write

   fromLeft impossible e

where `impossible` does a controlled crash of your program.  (See 
fromMaybe.)

--Andreas

On 21.05.2016 15:16, Edward Kmett wrote:
> Sorry, I meant fromJust.
>
> On Sat, May 21, 2016 at 8:58 AM, David Feuer <david.feuer at gmail.com
> <mailto:david.feuer at gmail.com>> wrote:
>
>     No one wants to remove fromMaybe. In fact, it could serve as a
>     template for total fromLeft and fromRight:
>
>     fromLeft :: b -> (a -> b) -> Either a x -> b
>     fromRight :: b -> (a -> b) -> Either x a -> b
>
>     On May 21, 2016 8:55 AM, "Edward Kmett" <ekmett at gmail.com
>     <mailto:ekmett at gmail.com>> wrote:
>
>         I'm personally -1 on this.
>
>         A large portion of the community is vehemently against adding
>         new partial functions, and they have to share base with the rest
>         of us. I'd say more people want to remove fromMaybe, head, tail,
>         etc. than want to double down on the pattern at this time.
>
>         -Edward
>
>         On Fri, May 20, 2016 at 4:08 PM, Anton Felix Lorenzen
>         <anfelor at posteo.de <mailto:anfelor at posteo.de>> wrote:
>
>             When working with Either,
>             I am often missing two simple functions:
>             fromRight :: Either a b -> b
>             fromLeft  :: Either a b -> a
>
>             It has been implemented a couple of times:
>             http://hayoo.fh-wedel.de/?query=fromRight
>
>             But I don't want to depend on yet another library
>             for such a basic function.
>
>             Could it be added?
>
>             Anton
>             _______________________________________________
>             Libraries mailing list
>             Libraries at haskell.org <mailto:Libraries at haskell.org>
>             http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
>         _______________________________________________
>         Libraries mailing list
>         Libraries at haskell.org <mailto: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
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From david.feuer at gmail.com  Sat May 21 18:39:23 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 21 May 2016 14:39:23 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <5740A3BA.10306@chalmers.se>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
 <5740A3BA.10306@chalmers.se>
Message-ID: <CAMgWh9vAMcOOBo_6rar_oMij8SbXLiF57NHeYFaUjXwiyOBoqQ@mail.gmail.com>

That's what I meant. Sorry; typing in my sleep!
On May 21, 2016 2:06 PM, "Andreas Abel" <abela at chalmers.se> wrote:

> Ah, yes, we want fromLeft and fromRight, but with types
>
>   fromLeft  :: a -> Either a b -> a
>   fromRight :: b -> Either a b -> b
>
> where the first argument is the "default", like
>
>   fromLeft a (Right b) = a
>
> Then you can write
>
>   fromLeft impossible e
>
> where `impossible` does a controlled crash of your program.  (See
> fromMaybe.)
>
> --Andreas
>
> On 21.05.2016 15:16, Edward Kmett wrote:
>
>> Sorry, I meant fromJust.
>>
>> On Sat, May 21, 2016 at 8:58 AM, David Feuer <david.feuer at gmail.com
>> <mailto:david.feuer at gmail.com>> wrote:
>>
>>     No one wants to remove fromMaybe. In fact, it could serve as a
>>     template for total fromLeft and fromRight:
>>
>>     fromLeft :: b -> (a -> b) -> Either a x -> b
>>     fromRight :: b -> (a -> b) -> Either x a -> b
>>
>>     On May 21, 2016 8:55 AM, "Edward Kmett" <ekmett at gmail.com
>>     <mailto:ekmett at gmail.com>> wrote:
>>
>>         I'm personally -1 on this.
>>
>>         A large portion of the community is vehemently against adding
>>         new partial functions, and they have to share base with the rest
>>         of us. I'd say more people want to remove fromMaybe, head, tail,
>>         etc. than want to double down on the pattern at this time.
>>
>>         -Edward
>>
>>         On Fri, May 20, 2016 at 4:08 PM, Anton Felix Lorenzen
>>         <anfelor at posteo.de <mailto:anfelor at posteo.de>> wrote:
>>
>>             When working with Either,
>>             I am often missing two simple functions:
>>             fromRight :: Either a b -> b
>>             fromLeft  :: Either a b -> a
>>
>>             It has been implemented a couple of times:
>>             http://hayoo.fh-wedel.de/?query=fromRight
>>
>>             But I don't want to depend on yet another library
>>             for such a basic function.
>>
>>             Could it be added?
>>
>>             Anton
>>             _______________________________________________
>>             Libraries mailing list
>>             Libraries at haskell.org <mailto:Libraries at haskell.org>
>>             http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>>
>>         _______________________________________________
>>         Libraries mailing list
>>         Libraries at haskell.org <mailto: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
>>
>>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel at gu.se
> http://www2.tcs.ifi.lmu.de/~abel/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160521/b404f959/attachment.html>

From dan.doel at gmail.com  Sat May 21 18:42:58 2016
From: dan.doel at gmail.com (Dan Doel)
Date: Sat, 21 May 2016 14:42:58 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
Message-ID: <CAHEA9tNbarsV1r0E9WMKMBQQK9aagkEnCWUGX5boJrxjneZJ3g@mail.gmail.com>

I would add (as I probably did last time something like this came up)
that it's difficult to get excited about all these functions named by
a systematic grammar, when we know _today_ how to just implement that
grammar as a library of composable pieces. And it has been implemented
in lens (and possibly other libraries that are subsets of lens).

Then you can have `is`, `over` (like map), `from` (take your pick on
whether it's partial or with-default), `foldOf`, `traverseOf`, ...,
and `_Left`, `_Right`, `_Just`, `_Nothing` (not all of these
correspond to lens; just you could define them). These building blocks
make all these functions definable, with almost exactly the names
they'd be given as one-off functions in several modules. But of
course, they also compose in more interesting ways, too. You can have
`from (_Left . _Just)`, but we will never be adding a
`fromLeftAndJust` function to base.

I don't really expect (or hope for) base to start pulling in big
chunks of lens. And maybe it makes sense for all of these to be in
base just for uniformity. But it also seems like people could just be
using something better.

-- Dan


On Sat, May 21, 2016 at 8:55 AM, Edward Kmett <ekmett at gmail.com> wrote:
> I'm personally -1 on this.
>
> A large portion of the community is vehemently against adding new partial
> functions, and they have to share base with the rest of us. I'd say more
> people want to remove fromMaybe, head, tail, etc. than want to double down
> on the pattern at this time.
>
> -Edward
>
> On Fri, May 20, 2016 at 4:08 PM, Anton Felix Lorenzen <anfelor at posteo.de>
> wrote:
>>
>> When working with Either,
>> I am often missing two simple functions:
>> fromRight :: Either a b -> b
>> fromLeft  :: Either a b -> a
>>
>> It has been implemented a couple of times:
>> http://hayoo.fh-wedel.de/?query=fromRight
>>
>> But I don't want to depend on yet another library
>> for such a basic function.
>>
>> Could it be added?
>>
>> Anton
>> _______________________________________________
>> 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
>

From voldermort at hotmail.com  Sun May 22 07:17:43 2016
From: voldermort at hotmail.com (Jeremy .)
Date: Sun, 22 May 2016 07:17:43 +0000
Subject: TDNR without new operators or syntax changes
Message-ID: <AM4PR0401MB2052B011A41CA946B75B4688CD4D0@AM4PR0401MB2052.eurprd04.prod.outlook.com>

Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.)


1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports);

2. And exactly one of these definitions matches the type of a (or the expected type of f if given);

3. Then this is the definition to use.


That is all, although point 2 could be extended to consider the return type of f or other arguments as well. Even with the extension on, it would have no effect on programs which compile without it.


This has nothing to do with ORF, which relies on magic type classes (although there is some overlap in what it can achieve). The primary use-case I had in mind is disambiguating name clashes between local and/or unqualified imports.


Cross-posting to cafe and libraries as this doesn't seem to have attracted a lot of interest in users. Maybe it's just a boring proposal, maybe I didn't post it to the right list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160522/ae4ded22/attachment-0001.html>

From spam at scientician.net  Mon May 23 15:27:39 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Mon, 23 May 2016 17:27:39 +0200
Subject: Proposal: add foldMapWithIndex to Data.Sequence
In-Reply-To: <CAMgWh9vRigkOvvgbnOD+owJ5EjncfOdiDCw=XhFGM-hdAuGzXw@mail.gmail.com>
References: <CAMgWh9tWBgNu2b18xxKMRX47Yz-HzHJTPeTcJM1OSVi2GJnhcw@mail.gmail.com>
 <CAMgWh9v8gtRd6dBBQk9hD6qge7fVOJ+uSScVDhXnCcPpybjoDg@mail.gmail.com>
 <CAMgWh9vqgWip=Rwuom+wFdKPYzkzb_wCt+1Pmvkiiwnh4Ghbyw@mail.gmail.com>
 <CAMgWh9usC2Hc+uKi=0ZagA9Qns2uupkkjXAOatmSBd4UAuikSw@mail.gmail.com>
 <CAMgWh9sPW13wgQaktAkQA0S6jLaYsoTc2cSX8x906A+z7seacA@mail.gmail.com>
 <CAMgWh9uz=WCHLHTdv6hqEnMZxxcydszvDhOL8PLS463YSARUtQ@mail.gmail.com>
 <CAMgWh9tPGQMAoZniN5LKXta88jTJgpMgFUwLeqF7zejmZ7hTKg@mail.gmail.com>
 <CAMgWh9sR2nxj0y_u135FWutxcRbubZdNpP7cQjj=51ZK0r_d8w@mail.gmail.com>
 <CAMgWh9uz5M8MhdUYR9NDnKaWJ7b=2-2W2COfFXc1WQ3Lj==t5Q@mail.gmail.com>
 <CAMgWh9u0km8AY40id49KxiD-hoYO=gPbddM47SDqW0wZ=XGLaA@mail.gmail.com>
 <CAMgWh9vRigkOvvgbnOD+owJ5EjncfOdiDCw=XhFGM-hdAuGzXw@mail.gmail.com>
Message-ID: <nhv7hc$k60$3@ger.gmane.org>

On 05/20/2016 07:20 PM, David Feuer wrote:
> foldMapWithIndex :: Monoid m
>      => (Int -> a -> m) -> Seq a -> m
> 
> This would match both Data.Map.foldMapWithKey and
> Control.Lens.Indexed.ifoldMap, filling out the indexed fold menagerie.
> 

+1

on the general principle that having as uniform an interface to the
'collections' is a Good Thing.



From twanvl at gmail.com  Tue May 24 12:28:59 2016
From: twanvl at gmail.com (Twan van Laarhoven)
Date: Tue, 24 May 2016 14:28:59 +0200
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
Message-ID: <5744490B.3000409@gmail.com>

+1 from me.

I often use such functions when working in GHCi, and it is consistent with the 
existence of fromJust. That said, I understand the opposition, and these 
functions should never be used in production code.

Maybe we should put the lot of them (together with head, tail, fromJust) into a 
"Partial" module?

Twan

On 2016-05-20 22:08, Anton Felix Lorenzen wrote:
> When working with Either,
> I am often missing two simple functions:
> fromRight :: Either a b -> b
> fromLeft  :: Either a b -> a
>
> It has been implemented a couple of times:
> http://hayoo.fh-wedel.de/?query=fromRight
>
> But I don't want to depend on yet another library
> for such a basic function.
>
> Could it be added?
>
> Anton
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From dhelta.diaz at gmail.com  Fri May 27 18:51:19 2016
From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=)
Date: Fri, 27 May 2016 14:51:19 -0400
Subject: Proposal: Add `maxOn` and `minOn` functions to Data.Ord
Message-ID: <CAJFXAQhWvWZFWMpCT9B7X+=xf7cwJu18WGZQe7nF3MKw+B0GbA@mail.gmail.com>

I think these are useful in general, and that they would make a good
addition to `Data.Ord`. The names are inspired by `sortOn`. Definitions:

```
minOn :: Ord b => (a -> b) -> a -> a -> a
minOn f x y =
  case comparing f x y of
    LT -> x
    _ -> y

maxOn :: Ord b => (a -> b) -> a -> a -> a
maxOn f x y =
  case comparing f x y of
    GT -> x
    _ -> y
```

These don't need to be the exact definitions, but they convey the semantics
I'm looking for.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160527/571e53fb/attachment.html>

From ekmett at gmail.com  Fri May 27 19:02:43 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 27 May 2016 15:02:43 -0400
Subject: Proposal: Add `maxOn` and `minOn` functions to Data.Ord
In-Reply-To: <CAJFXAQhWvWZFWMpCT9B7X+=xf7cwJu18WGZQe7nF3MKw+B0GbA@mail.gmail.com>
References: <CAJFXAQhWvWZFWMpCT9B7X+=xf7cwJu18WGZQe7nF3MKw+B0GbA@mail.gmail.com>
Message-ID: <7DDDCCA1-5AEC-48B4-8F2F-7474DD5D0470@gmail.com>

Note: in general we have chosen to supply By methods, rather than On methods, because he on combinator can be used to get one in terms of the other. We explicitly added sortOn because it can use a Schwartzian transform to be more efficient than sortBy (comparing `on` f).

These don't have direct analogues there, however. So that usual argument against adding these sorts of methods doesn't hold up.

One thing of note is that what you are asking for here is usually called argmin and argmax. Perhaps consistency with the rest of mathematics should trump consistency with sortOn.

IIRC, We already have Arg in Data.Semigroup for use with the Min and Max semigroups for this purpose, so such naming would fit.

-Edward

> On May 27, 2016, at 2:51 PM, Daniel D?az Casanueva <dhelta.diaz at gmail.com> wrote:
> 
> I think these are useful in general, and that they would make a good addition to `Data.Ord`. The names are inspired by `sortOn`. Definitions:
> 
> ```
> minOn :: Ord b => (a -> b) -> a -> a -> a
> minOn f x y =
>   case comparing f x y of
>     LT -> x
>     _ -> y
> 
> maxOn :: Ord b => (a -> b) -> a -> a -> a
> maxOn f x y =
>   case comparing f x y of
>     GT -> x
>     _ -> y
> ```
> 
> These don't need to be the exact definitions, but they convey the semantics I'm looking for.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From qdunkan at gmail.com  Fri May 27 20:04:03 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Fri, 27 May 2016 13:04:03 -0700
Subject: Proposal: Add `maxOn` and `minOn` functions to Data.Ord
In-Reply-To: <7DDDCCA1-5AEC-48B4-8F2F-7474DD5D0470@gmail.com>
References: <CAJFXAQhWvWZFWMpCT9B7X+=xf7cwJu18WGZQe7nF3MKw+B0GbA@mail.gmail.com>
 <7DDDCCA1-5AEC-48B4-8F2F-7474DD5D0470@gmail.com>
Message-ID: <CACbaDy7hQFEwRX4Zf9qz_6TH8gh3BQv8RzQ8Xbk_X6_v=aj4Mw@mail.gmail.com>

On Fri, May 27, 2016 at 12:02 PM, Edward Kmett <ekmett at gmail.com> wrote:
> Note: in general we have chosen to supply By methods, rather than On methods, because he on combinator can be used to get one in terms of the other. We explicitly added sortOn because it can use a Schwartzian transform to be more efficient than sortBy (comparing `on` f).

I've noticed that I've needed the "by" only very rarely, while I use
"on" variants almost every time.  Specifically, for sorting, grouping
by key, max, min, and total versions of maximum and minimum, all
extremely useful.  I don't mind their absence from Data.List because I
have them all in a local library and I tend to think a local library
makes everyone happier than trying to put the union of everything
everyone wants in the standard library.

But I wonder if others have the same experience, and if it isn't one
of those cases where haskell prioritized more general over more
convenient.

I also like the On suffix because it can be applied universally to all
functions that take a key function.

But anyway, there is also a data-ordlist package out there that has a
bunch of utilities along those lines, perhaps its maintainer would be
receptive to maxOn and minOn.

From dhelta.diaz at gmail.com  Fri May 27 20:24:45 2016
From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=)
Date: Fri, 27 May 2016 16:24:45 -0400
Subject: Proposal: Add `maxOn` and `minOn` functions to Data.Ord
In-Reply-To: <CACbaDy7hQFEwRX4Zf9qz_6TH8gh3BQv8RzQ8Xbk_X6_v=aj4Mw@mail.gmail.com>
References: <CAJFXAQhWvWZFWMpCT9B7X+=xf7cwJu18WGZQe7nF3MKw+B0GbA@mail.gmail.com>
 <7DDDCCA1-5AEC-48B4-8F2F-7474DD5D0470@gmail.com>
 <CACbaDy7hQFEwRX4Zf9qz_6TH8gh3BQv8RzQ8Xbk_X6_v=aj4Mw@mail.gmail.com>
Message-ID: <CAJFXAQgHm6bN9z1fdA=-1FUNGzADZ+P9Fy3_kkHzB8Ndk2a-1Q@mail.gmail.com>

>
> But anyway, there is also a data-ordlist package out there that has a
> bunch of utilities along those lines, perhaps its maintainer would be
> receptive to maxOn and minOn.
>

Except that `maxOn` and `minOn` are not related to lists, and that package
is a set of functions related to ordered lists.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160527/75c45f51/attachment.html>

From dhelta.diaz at gmail.com  Fri May 27 20:30:54 2016
From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=)
Date: Fri, 27 May 2016 16:30:54 -0400
Subject: Proposal: Add `maxOn` and `minOn` functions to Data.Ord
In-Reply-To: <7DDDCCA1-5AEC-48B4-8F2F-7474DD5D0470@gmail.com>
References: <CAJFXAQhWvWZFWMpCT9B7X+=xf7cwJu18WGZQe7nF3MKw+B0GbA@mail.gmail.com>
 <7DDDCCA1-5AEC-48B4-8F2F-7474DD5D0470@gmail.com>
Message-ID: <CAJFXAQg6_G895x6D8+ibfkX-t_E3mdgozqeq-Qp1G0dvg_qZhQ@mail.gmail.com>

On Fri, May 27, 2016 at 3:02 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Note: in general we have chosen to supply By methods, rather than On
> methods, because he on combinator can be used to get one in terms of the
> other. We explicitly added sortOn because it can use a Schwartzian
> transform to be more efficient than sortBy (comparing `on` f).
>
> These don't have direct analogues there, however. So that usual argument
> against adding these sorts of methods doesn't hold up.
>
> One thing of note is that what you are asking for here is usually called
> argmin and argmax. Perhaps consistency with the rest of mathematics should
> trump consistency with sortOn.
>
> IIRC, We already have Arg in Data.Semigroup for use with the Min and Max
> semigroups for this purpose, so such naming would fit.
>

I'm not particularly concerned about the names that we decide. I just used
those names because I thought they were intuitive for the current
community. I'm happy with any other names that make sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160527/07d3667b/attachment.html>

From wren at community.haskell.org  Sun May 29 00:48:31 2016
From: wren at community.haskell.org (wren romano)
Date: Sat, 28 May 2016 20:48:31 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <5740A3BA.10306@chalmers.se>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
 <5740A3BA.10306@chalmers.se>
Message-ID: <CABUjdS5CmMY8s-g1WQ_ktBL-G6D=e+m2E6WLMZiVRsw9f2mZQA@mail.gmail.com>

On Sat, May 21, 2016 at 2:06 PM, Andreas Abel <abela at chalmers.se> wrote:
> Ah, yes, we want fromLeft and fromRight, but with types
>
>   fromLeft  :: a -> Either a b -> a
>   fromRight :: b -> Either a b -> b
>
> where the first argument is the "default", like

If anything is added, then +1 for these versions.

Very strong -1 for adding partial functions.

-- 
Live well,
~wren

From tikhon at jelv.is  Sun May 29 06:43:34 2016
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Sat, 28 May 2016 23:43:34 -0700
Subject: Proposal: Add `maxOn` and `minOn` functions to Data.Ord
In-Reply-To: <CAJFXAQg6_G895x6D8+ibfkX-t_E3mdgozqeq-Qp1G0dvg_qZhQ@mail.gmail.com>
References: <CAJFXAQhWvWZFWMpCT9B7X+=xf7cwJu18WGZQe7nF3MKw+B0GbA@mail.gmail.com>
 <7DDDCCA1-5AEC-48B4-8F2F-7474DD5D0470@gmail.com>
 <CAJFXAQg6_G895x6D8+ibfkX-t_E3mdgozqeq-Qp1G0dvg_qZhQ@mail.gmail.com>
Message-ID: <CAJN5CVKQsdw_PhzV6tM6e_CCj1X+5ZLEqGzG8q6B2rYCAOp52g@mail.gmail.com>

I've needed argmin and argmax a few times. In at least one of the cases I
remember, I was implementing some algorithm that was specified with argmax
in pseudocode, so those names make sense to me.

On Fri, May 27, 2016 at 1:30 PM, Daniel D?az Casanueva <
dhelta.diaz at gmail.com> wrote:

> On Fri, May 27, 2016 at 3:02 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> Note: in general we have chosen to supply By methods, rather than On
>> methods, because he on combinator can be used to get one in terms of the
>> other. We explicitly added sortOn because it can use a Schwartzian
>> transform to be more efficient than sortBy (comparing `on` f).
>>
>> These don't have direct analogues there, however. So that usual argument
>> against adding these sorts of methods doesn't hold up.
>>
>> One thing of note is that what you are asking for here is usually called
>> argmin and argmax. Perhaps consistency with the rest of mathematics should
>> trump consistency with sortOn.
>>
>> IIRC, We already have Arg in Data.Semigroup for use with the Min and Max
>> semigroups for this purpose, so such naming would fit.
>>
>
> I'm not particularly concerned about the names that we decide. I just used
> those names because I thought they were intuitive for the current
> community. I'm happy with any other names that make sense.
>
> _______________________________________________
> 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/20160528/ede4f6fe/attachment.html>

From david.feuer at gmail.com  Sun May 29 20:32:46 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 29 May 2016 16:32:46 -0400
Subject: Proposal: Add insertAt to Data.Sequence
Message-ID: <CAMgWh9uyRTDV8F=j-BVwACAeaAz_my0TK3vuorM-WTKdoF-=vw@mail.gmail.com>

I've come up with an implementation of

insertAt :: Int -> a -> Seq a -> Seq a
-- Defined to be equivalent to
insertAt i x xs
  | i < 0 || i > length xs = error "insertAt: index out of range"
  | otherwise = take i xs <> singleton x <> drop i xs

that inserts the given element at the given index with very little
tree restructuring. I came up with the vague notion that it might be
interesting to try to do something like this early last year, but I
wasn't sure how at the time. I largely forgot about it until today,
when someone on StackOverflow pointed to the issue I'd opened and
asked if it would be implemented, presumably because he wants it. What
do y'all think?

David Feuer

From david.feuer at gmail.com  Sun May 29 21:21:35 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 29 May 2016 17:21:35 -0400
Subject: Discussion: Add total indexing function to Data.Sequence
Message-ID: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>

Data.Sequence offers

index :: Seq a -> Int -> a

which throws an error if the index is out of range. I'd like to add
something like

indexMay :: Seq a -> Int -> Maybe a

Aside from the safety factor, indexMay would offer a way to ensure the
indexing occurs at a particular time. Much like Data.Vector.indexM,
this can help prevent memory leaks. In fact, an analogue of indexM can
be implemented in terms of indexMay:

indexM :: Applicative m => Seq a -> Int -> m a
indexM xs i = case xs `indexMay` i of
  Nothing -> error "indexM: index out of range"
  Just x -> pure x

From ivan.miljenovic at gmail.com  Sun May 29 22:10:48 2016
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Mon, 30 May 2016 08:10:48 +1000
Subject: Proposal: Add insertAt to Data.Sequence
In-Reply-To: <CAMgWh9uyRTDV8F=j-BVwACAeaAz_my0TK3vuorM-WTKdoF-=vw@mail.gmail.com>
References: <CAMgWh9uyRTDV8F=j-BVwACAeaAz_my0TK3vuorM-WTKdoF-=vw@mail.gmail.com>
Message-ID: <CA+u6gbzi6puHc4C9Nm2UbPqiTrPJ2iHrBCphVMGUTwURrdLxjg@mail.gmail.com>

On 30 May 2016 at 06:32, David Feuer <david.feuer at gmail.com> wrote:
> I've come up with an implementation of
>
> insertAt :: Int -> a -> Seq a -> Seq a
> -- Defined to be equivalent to
> insertAt i x xs
>   | i < 0 || i > length xs = error "insertAt: index out of range"
>   | otherwise = take i xs <> singleton x <> drop i xs
>
> that inserts the given element at the given index with very little
> tree restructuring. I came up with the vague notion that it might be
> interesting to try to do something like this early last year, but I
> wasn't sure how at the time. I largely forgot about it until today,
> when someone on StackOverflow pointed to the issue I'd opened and
> asked if it would be implemented, presumably because he wants it. What
> do y'all think?

The partiality is a little troubling; would it be feasible from a
usage point of view to have this function return a Maybe?

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From ivan.miljenovic at gmail.com  Sun May 29 22:12:31 2016
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Mon, 30 May 2016 08:12:31 +1000
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
Message-ID: <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>

On 30 May 2016 at 07:21, David Feuer <david.feuer at gmail.com> wrote:
> Data.Sequence offers
>
> index :: Seq a -> Int -> a
>
> which throws an error if the index is out of range. I'd like to add
> something like
>
> indexMay :: Seq a -> Int -> Maybe a

+1

(I personally don't like the "May" prefix used for functions like this
as I don't find it very readable, but not enough to argue over the
colour of the bikeshed ;-)

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From david.feuer at gmail.com  Sun May 29 22:26:59 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 29 May 2016 18:26:59 -0400
Subject: Proposal: Add insertAt to Data.Sequence
In-Reply-To: <CA+u6gbzi6puHc4C9Nm2UbPqiTrPJ2iHrBCphVMGUTwURrdLxjg@mail.gmail.com>
References: <CAMgWh9uyRTDV8F=j-BVwACAeaAz_my0TK3vuorM-WTKdoF-=vw@mail.gmail.com>
 <CA+u6gbzi6puHc4C9Nm2UbPqiTrPJ2iHrBCphVMGUTwURrdLxjg@mail.gmail.com>
Message-ID: <CAMgWh9tH+gwH8qh6+3u4pFVmHzukjh1YTJWDjrd-XYsAr4a0mw@mail.gmail.com>

No, it would not be feasible to have it return a Maybe; usability
would go down the drain. My preferred total alternative would be to
drop the bounds check in that spec, so

insertAt (-1) 99 [1,2,3]  ===  [99,1,2,3]
insertAt 12 99 [1,2,3] === [1,2,3,99]

The only potential concern is that trying to insert at an out-of-range
index seems likely to be a mistake someone might want to get an error
message about. There are a number of other functions in Data.Sequence
that are partial in similar ways; I'm very open to making them total,
but the previous maintainers were concerned about losing useful
errors.

On Sun, May 29, 2016 at 6:10 PM, Ivan Lazar Miljenovic
<ivan.miljenovic at gmail.com> wrote:
> On 30 May 2016 at 06:32, David Feuer <david.feuer at gmail.com> wrote:
>> I've come up with an implementation of
>>
>> insertAt :: Int -> a -> Seq a -> Seq a
>> -- Defined to be equivalent to
>> insertAt i x xs
>>   | i < 0 || i > length xs = error "insertAt: index out of range"
>>   | otherwise = take i xs <> singleton x <> drop i xs
>>
>> that inserts the given element at the given index with very little
>> tree restructuring. I came up with the vague notion that it might be
>> interesting to try to do something like this early last year, but I
>> wasn't sure how at the time. I largely forgot about it until today,
>> when someone on StackOverflow pointed to the issue I'd opened and
>> asked if it would be implemented, presumably because he wants it. What
>> do y'all think?
>
> The partiality is a little troubling; would it be feasible from a
> usage point of view to have this function return a Maybe?
>
> --
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com
> http://IvanMiljenovic.wordpress.com

From david.feuer at gmail.com  Sun May 29 22:28:25 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 29 May 2016 18:28:25 -0400
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
Message-ID: <CAMgWh9sW=aUyQ7b419XyAL=gXp=6j_Yo_HBppgZXoNTHh_S8Lw@mail.gmail.com>

I don't like that bikeshed color much either. Go ahead and suggest
something else.

On Sun, May 29, 2016 at 6:12 PM, Ivan Lazar Miljenovic
<ivan.miljenovic at gmail.com> wrote:
> On 30 May 2016 at 07:21, David Feuer <david.feuer at gmail.com> wrote:
>> Data.Sequence offers
>>
>> index :: Seq a -> Int -> a
>>
>> which throws an error if the index is out of range. I'd like to add
>> something like
>>
>> indexMay :: Seq a -> Int -> Maybe a
>
> +1
>
> (I personally don't like the "May" prefix used for functions like this
> as I don't find it very readable, but not enough to argue over the
> colour of the bikeshed ;-)
>
> --
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com
> http://IvanMiljenovic.wordpress.com

From fa-ml at ariis.it  Sun May 29 22:35:58 2016
From: fa-ml at ariis.it (Francesco Ariis)
Date: Mon, 30 May 2016 00:35:58 +0200
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CAMgWh9sW=aUyQ7b419XyAL=gXp=6j_Yo_HBppgZXoNTHh_S8Lw@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
 <CAMgWh9sW=aUyQ7b419XyAL=gXp=6j_Yo_HBppgZXoNTHh_S8Lw@mail.gmail.com>
Message-ID: <20160529223558.GA10336@casa.casa>

On Sun, May 29, 2016 at 06:28:25PM -0400, David Feuer wrote:
> I don't like that bikeshed color much either. Go ahead and suggest
> something else.

safeIndex? totalIndex? Best solution would be to rename index to
unsafeIndex and your proposed function to index, but it's obviously
not practicable.

From david.feuer at gmail.com  Sun May 29 22:52:53 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 29 May 2016 18:52:53 -0400
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <20160529223558.GA10336@casa.casa>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
 <CAMgWh9sW=aUyQ7b419XyAL=gXp=6j_Yo_HBppgZXoNTHh_S8Lw@mail.gmail.com>
 <20160529223558.GA10336@casa.casa>
Message-ID: <CAMgWh9toQmOno1cF+O9o9kHahb5VyGMU4xGbXn8to7HCr5O73w@mail.gmail.com>

I'm tempted to go with `lookup`, to match Data.IntMap.

On Sun, May 29, 2016 at 6:35 PM, Francesco Ariis <fa-ml at ariis.it> wrote:
> On Sun, May 29, 2016 at 06:28:25PM -0400, David Feuer wrote:
>> I don't like that bikeshed color much either. Go ahead and suggest
>> something else.
>
> safeIndex? totalIndex? Best solution would be to rename index to
> unsafeIndex and your proposed function to index, but it's obviously
> not practicable.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From qdunkan at gmail.com  Sun May 29 23:28:38 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun, 29 May 2016 16:28:38 -0700
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CAMgWh9toQmOno1cF+O9o9kHahb5VyGMU4xGbXn8to7HCr5O73w@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
 <CAMgWh9sW=aUyQ7b419XyAL=gXp=6j_Yo_HBppgZXoNTHh_S8Lw@mail.gmail.com>
 <20160529223558.GA10336@casa.casa>
 <CAMgWh9toQmOno1cF+O9o9kHahb5VyGMU4xGbXn8to7HCr5O73w@mail.gmail.com>
Message-ID: <CACbaDy68H3ULG24hg7rb3ARxXeCN_y0H3+9YHYRisk2j5dJtoA@mail.gmail.com>

I call my list version at: 'at :: (Num i, Ord i) => [a] -> i -> Maybe a'.

I also often use "lookup" as a shorthand for "returns Maybe" (and then
"get" means throws on Nothing).

On Sun, May 29, 2016 at 3:52 PM, David Feuer <david.feuer at gmail.com> wrote:
> I'm tempted to go with `lookup`, to match Data.IntMap.
>
> On Sun, May 29, 2016 at 6:35 PM, Francesco Ariis <fa-ml at ariis.it> wrote:
>> On Sun, May 29, 2016 at 06:28:25PM -0400, David Feuer wrote:
>>> I don't like that bikeshed color much either. Go ahead and suggest
>>> something else.
>>
>> safeIndex? totalIndex? Best solution would be to rename index to
>> unsafeIndex and your proposed function to index, but it's obviously
>> not practicable.
>> _______________________________________________
>> 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

From qdunkan at gmail.com  Sun May 29 23:37:13 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun, 29 May 2016 16:37:13 -0700
Subject: Proposal: Add insertAt to Data.Sequence
In-Reply-To: <CAMgWh9tH+gwH8qh6+3u4pFVmHzukjh1YTJWDjrd-XYsAr4a0mw@mail.gmail.com>
References: <CAMgWh9uyRTDV8F=j-BVwACAeaAz_my0TK3vuorM-WTKdoF-=vw@mail.gmail.com>
 <CA+u6gbzi6puHc4C9Nm2UbPqiTrPJ2iHrBCphVMGUTwURrdLxjg@mail.gmail.com>
 <CAMgWh9tH+gwH8qh6+3u4pFVmHzukjh1YTJWDjrd-XYsAr4a0mw@mail.gmail.com>
Message-ID: <CACbaDy5-4UxLMDS3gQZu9gFcakntv_x2RMZcZu7aCD5YdKq15Q@mail.gmail.com>

On Sun, May 29, 2016 at 3:26 PM, David Feuer <david.feuer at gmail.com> wrote:
> No, it would not be feasible to have it return a Maybe; usability
> would go down the drain. My preferred total alternative would be to
> drop the bounds check in that spec, so

This is also what I would expect, by analogy to splitAt (and take and drop).

From david.feuer at gmail.com  Mon May 30 00:42:41 2016
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 29 May 2016 20:42:41 -0400
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
Message-ID: <CAMgWh9ujAWm+jmRr+-3hKiUPhpay8BdCKo1bOo4dEpvO+8ozQw@mail.gmail.com>

How about (!?) like Data.Vector?

On Sun, May 29, 2016 at 5:21 PM, David Feuer <david.feuer at gmail.com> wrote:
> Data.Sequence offers
>
> index :: Seq a -> Int -> a
>
> which throws an error if the index is out of range. I'd like to add
> something like
>
> indexMay :: Seq a -> Int -> Maybe a
>
> Aside from the safety factor, indexMay would offer a way to ensure the
> indexing occurs at a particular time. Much like Data.Vector.indexM,
> this can help prevent memory leaks. In fact, an analogue of indexM can
> be implemented in terms of indexMay:
>
> indexM :: Applicative m => Seq a -> Int -> m a
> indexM xs i = case xs `indexMay` i of
>   Nothing -> error "indexM: index out of range"
>   Just x -> pure x

From michaelburge at pobox.com  Mon May 30 01:00:30 2016
From: michaelburge at pobox.com (Michael Burge)
Date: Sun, 29 May 2016 18:00:30 -0700
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CABUjdS5CmMY8s-g1WQ_ktBL-G6D=e+m2E6WLMZiVRsw9f2mZQA@mail.gmail.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
 <5740A3BA.10306@chalmers.se>
 <CABUjdS5CmMY8s-g1WQ_ktBL-G6D=e+m2E6WLMZiVRsw9f2mZQA@mail.gmail.com>
Message-ID: <CAOaSQ4fBm=ZuJx-Sp0h0eB7mnePNayONWy8om9oxBJFh=URC5Q@mail.gmail.com>

+1 on the total versions.

On Sat, May 28, 2016 at 5:48 PM, wren romano <wren at community.haskell.org>
wrote:

> On Sat, May 21, 2016 at 2:06 PM, Andreas Abel <abela at chalmers.se> wrote:
> > Ah, yes, we want fromLeft and fromRight, but with types
> >
> >   fromLeft  :: a -> Either a b -> a
> >   fromRight :: b -> Either a b -> b
> >
> > where the first argument is the "default", like
>
> If anything is added, then +1 for these versions.
>
> Very strong -1 for adding partial functions.
>
> --
> Live well,
> ~wren
> _______________________________________________
> 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/20160529/4a5f2b54/attachment.html>

From qdunkan at gmail.com  Mon May 30 01:10:05 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun, 29 May 2016 18:10:05 -0700
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CAMgWh9ujAWm+jmRr+-3hKiUPhpay8BdCKo1bOo4dEpvO+8ozQw@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CAMgWh9ujAWm+jmRr+-3hKiUPhpay8BdCKo1bOo4dEpvO+8ozQw@mail.gmail.com>
Message-ID: <CACbaDy7HQ-Dxv5tecdcAQ-4yjujjRs5TkF-KVeFewCkrN_=Paw@mail.gmail.com>

On Sun, May 29, 2016 at 5:42 PM, David Feuer <david.feuer at gmail.com> wrote:
> How about (!?) like Data.Vector?

That's good too, though I think most operators should also have an
alphanumeric version for those who either like qualified imports, or
use it rarely enough that it's not worth memorizing another operator.
Or are already using the Data.Vector one.

From ekmett at gmail.com  Mon May 30 01:38:38 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 29 May 2016 21:38:38 -0400
Subject: Proposal: Add insertAt to Data.Sequence
In-Reply-To: <CAMgWh9tH+gwH8qh6+3u4pFVmHzukjh1YTJWDjrd-XYsAr4a0mw@mail.gmail.com>
References: <CAMgWh9uyRTDV8F=j-BVwACAeaAz_my0TK3vuorM-WTKdoF-=vw@mail.gmail.com>
 <CA+u6gbzi6puHc4C9Nm2UbPqiTrPJ2iHrBCphVMGUTwURrdLxjg@mail.gmail.com>
 <CAMgWh9tH+gwH8qh6+3u4pFVmHzukjh1YTJWDjrd-XYsAr4a0mw@mail.gmail.com>
Message-ID: <CAJumaK9K365vu6KTsCAV5gx1OJgOV0yQg3xS2uhByW=6JmHKCA@mail.gmail.com>

I rather like the variant without the bounds check that does the right
thing at extremes.

-Edward

On Sun, May 29, 2016 at 6:26 PM, David Feuer <david.feuer at gmail.com> wrote:

> No, it would not be feasible to have it return a Maybe; usability
> would go down the drain. My preferred total alternative would be to
> drop the bounds check in that spec, so
>
> insertAt (-1) 99 [1,2,3]  ===  [99,1,2,3]
> insertAt 12 99 [1,2,3] === [1,2,3,99]
>
> The only potential concern is that trying to insert at an out-of-range
> index seems likely to be a mistake someone might want to get an error
> message about. There are a number of other functions in Data.Sequence
> that are partial in similar ways; I'm very open to making them total,
> but the previous maintainers were concerned about losing useful
> errors.
>
> On Sun, May 29, 2016 at 6:10 PM, Ivan Lazar Miljenovic
> <ivan.miljenovic at gmail.com> wrote:
> > On 30 May 2016 at 06:32, David Feuer <david.feuer at gmail.com> wrote:
> >> I've come up with an implementation of
> >>
> >> insertAt :: Int -> a -> Seq a -> Seq a
> >> -- Defined to be equivalent to
> >> insertAt i x xs
> >>   | i < 0 || i > length xs = error "insertAt: index out of range"
> >>   | otherwise = take i xs <> singleton x <> drop i xs
> >>
> >> that inserts the given element at the given index with very little
> >> tree restructuring. I came up with the vague notion that it might be
> >> interesting to try to do something like this early last year, but I
> >> wasn't sure how at the time. I largely forgot about it until today,
> >> when someone on StackOverflow pointed to the issue I'd opened and
> >> asked if it would be implemented, presumably because he wants it. What
> >> do y'all think?
> >
> > The partiality is a little troubling; would it be feasible from a
> > usage point of view to have this function return a Maybe?
> >
> > --
> > Ivan Lazar Miljenovic
> > Ivan.Miljenovic at gmail.com
> > http://IvanMiljenovic.wordpress.com
> _______________________________________________
> 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/20160529/b2178f9b/attachment.html>

From ekmett at gmail.com  Mon May 30 01:40:08 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 29 May 2016 21:40:08 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CAOaSQ4fBm=ZuJx-Sp0h0eB7mnePNayONWy8om9oxBJFh=URC5Q@mail.gmail.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
 <5740A3BA.10306@chalmers.se>
 <CABUjdS5CmMY8s-g1WQ_ktBL-G6D=e+m2E6WLMZiVRsw9f2mZQA@mail.gmail.com>
 <CAOaSQ4fBm=ZuJx-Sp0h0eB7mnePNayONWy8om9oxBJFh=URC5Q@mail.gmail.com>
Message-ID: <CAJumaK_wczX2MBPxX0jxhiRcyDUa_JOVY+zBoH57Veq5Tr8nPg@mail.gmail.com>

The main annoyance with the total versions is that the existing fromJust
has the wrong convention.

Oh well. Consistency is overrated.

-Edward

On Sun, May 29, 2016 at 9:00 PM, Michael Burge <michaelburge at pobox.com>
wrote:

> +1 on the total versions.
>
> On Sat, May 28, 2016 at 5:48 PM, wren romano <wren at community.haskell.org>
> wrote:
>
>> On Sat, May 21, 2016 at 2:06 PM, Andreas Abel <abela at chalmers.se> wrote:
>> > Ah, yes, we want fromLeft and fromRight, but with types
>> >
>> >   fromLeft  :: a -> Either a b -> a
>> >   fromRight :: b -> Either a b -> b
>> >
>> > where the first argument is the "default", like
>>
>> If anything is added, then +1 for these versions.
>>
>> Very strong -1 for adding partial functions.
>>
>> --
>> Live well,
>> ~wren
>> _______________________________________________
>> 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/20160529/9e067558/attachment-0001.html>

From ekmett at gmail.com  Mon May 30 01:40:54 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 29 May 2016 21:40:54 -0400
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CAMgWh9toQmOno1cF+O9o9kHahb5VyGMU4xGbXn8to7HCr5O73w@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
 <CAMgWh9sW=aUyQ7b419XyAL=gXp=6j_Yo_HBppgZXoNTHh_S8Lw@mail.gmail.com>
 <20160529223558.GA10336@casa.casa>
 <CAMgWh9toQmOno1cF+O9o9kHahb5VyGMU4xGbXn8to7HCr5O73w@mail.gmail.com>
Message-ID: <CAJumaK_qj_07mL+edWLDM_h_98+Pazt+Pztz-XVGPQ7by8eF=Q@mail.gmail.com>

lookup works for me.

-Edward

On Sun, May 29, 2016 at 6:52 PM, David Feuer <david.feuer at gmail.com> wrote:

> I'm tempted to go with `lookup`, to match Data.IntMap.
>
> On Sun, May 29, 2016 at 6:35 PM, Francesco Ariis <fa-ml at ariis.it> wrote:
> > On Sun, May 29, 2016 at 06:28:25PM -0400, David Feuer wrote:
> >> I don't like that bikeshed color much either. Go ahead and suggest
> >> something else.
> >
> > safeIndex? totalIndex? Best solution would be to rename index to
> > unsafeIndex and your proposed function to index, but it's obviously
> > not practicable.
> > _______________________________________________
> > 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/20160529/51228916/attachment.html>

From ekmett at gmail.com  Mon May 30 02:47:22 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 29 May 2016 22:47:22 -0400
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CAJumaK_qj_07mL+edWLDM_h_98+Pazt+Pztz-XVGPQ7by8eF=Q@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
 <CAMgWh9sW=aUyQ7b419XyAL=gXp=6j_Yo_HBppgZXoNTHh_S8Lw@mail.gmail.com>
 <20160529223558.GA10336@casa.casa>
 <CAMgWh9toQmOno1cF+O9o9kHahb5VyGMU4xGbXn8to7HCr5O73w@mail.gmail.com>
 <CAJumaK_qj_07mL+edWLDM_h_98+Pazt+Pztz-XVGPQ7by8eF=Q@mail.gmail.com>
Message-ID: <CAJumaK8iZ8E1T-TRpQR3UfnBU=o5u_HpC9iKnsOmDnYeSPknVg@mail.gmail.com>

Oops. Prelude. No I guess it doesn't.

On Sun, May 29, 2016 at 9:40 PM, Edward Kmett <ekmett at gmail.com> wrote:

> lookup works for me.
>
> -Edward
>
> On Sun, May 29, 2016 at 6:52 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
>> I'm tempted to go with `lookup`, to match Data.IntMap.
>>
>> On Sun, May 29, 2016 at 6:35 PM, Francesco Ariis <fa-ml at ariis.it> wrote:
>> > On Sun, May 29, 2016 at 06:28:25PM -0400, David Feuer wrote:
>> >> I don't like that bikeshed color much either. Go ahead and suggest
>> >> something else.
>> >
>> > safeIndex? totalIndex? Best solution would be to rename index to
>> > unsafeIndex and your proposed function to index, but it's obviously
>> > not practicable.
>> > _______________________________________________
>> > 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/20160529/9448f322/attachment.html>

From ekmett at gmail.com  Mon May 30 02:48:17 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 29 May 2016 22:48:17 -0400
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CAJumaK8iZ8E1T-TRpQR3UfnBU=o5u_HpC9iKnsOmDnYeSPknVg@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
 <CAMgWh9sW=aUyQ7b419XyAL=gXp=6j_Yo_HBppgZXoNTHh_S8Lw@mail.gmail.com>
 <20160529223558.GA10336@casa.casa>
 <CAMgWh9toQmOno1cF+O9o9kHahb5VyGMU4xGbXn8to7HCr5O73w@mail.gmail.com>
 <CAJumaK_qj_07mL+edWLDM_h_98+Pazt+Pztz-XVGPQ7by8eF=Q@mail.gmail.com>
 <CAJumaK8iZ8E1T-TRpQR3UfnBU=o5u_HpC9iKnsOmDnYeSPknVg@mail.gmail.com>
Message-ID: <CAJumaK8gX-puHi0sSiJWqBhOayM3tZrNBD82EJa7ti1nVg14nA@mail.gmail.com>

Then again, most of Data.Sequence already clashes with the Prelude.

On Sun, May 29, 2016 at 10:47 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Oops. Prelude. No I guess it doesn't.
>
> On Sun, May 29, 2016 at 9:40 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> lookup works for me.
>>
>> -Edward
>>
>> On Sun, May 29, 2016 at 6:52 PM, David Feuer <david.feuer at gmail.com>
>> wrote:
>>
>>> I'm tempted to go with `lookup`, to match Data.IntMap.
>>>
>>> On Sun, May 29, 2016 at 6:35 PM, Francesco Ariis <fa-ml at ariis.it> wrote:
>>> > On Sun, May 29, 2016 at 06:28:25PM -0400, David Feuer wrote:
>>> >> I don't like that bikeshed color much either. Go ahead and suggest
>>> >> something else.
>>> >
>>> > safeIndex? totalIndex? Best solution would be to rename index to
>>> > unsafeIndex and your proposed function to index, but it's obviously
>>> > not practicable.
>>> > _______________________________________________
>>> > 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/20160529/e2e5e87c/attachment.html>

From abela at chalmers.se  Mon May 30 06:09:49 2016
From: abela at chalmers.se (Andreas Abel)
Date: Mon, 30 May 2016 08:09:49 +0200
Subject: Proposal: Add insertAt to Data.Sequence
In-Reply-To: <CAMgWh9tH+gwH8qh6+3u4pFVmHzukjh1YTJWDjrd-XYsAr4a0mw@mail.gmail.com>
References: <CAMgWh9uyRTDV8F=j-BVwACAeaAz_my0TK3vuorM-WTKdoF-=vw@mail.gmail.com>
 <CA+u6gbzi6puHc4C9Nm2UbPqiTrPJ2iHrBCphVMGUTwURrdLxjg@mail.gmail.com>
 <CAMgWh9tH+gwH8qh6+3u4pFVmHzukjh1YTJWDjrd-XYsAr4a0mw@mail.gmail.com>
Message-ID: <574BD92D.9080408@chalmers.se>

On 30.05.2016 00:26, David Feuer wrote:
> No, it would not be feasible to have it return a Maybe; usability
> would go down the drain.

A priori, I cannot see why.  It is easy to make a Maybe-partial function 
"total" by prefixing it with

   fromMaybe (error "the universe is inconsistent")

If you want to insert at the beginning or at the end, I suppose special 
functions are already in place.

Cheers, Andreas

> My preferred total alternative would be to
> drop the bounds check in that spec, so
>
> insertAt (-1) 99 [1,2,3]  ===  [99,1,2,3]
> insertAt 12 99 [1,2,3] === [1,2,3,99]
>
> The only potential concern is that trying to insert at an out-of-range
> index seems likely to be a mistake someone might want to get an error
> message about. There are a number of other functions in Data.Sequence
> that are partial in similar ways; I'm very open to making them total,
> but the previous maintainers were concerned about losing useful
> errors.
>
> On Sun, May 29, 2016 at 6:10 PM, Ivan Lazar Miljenovic
> <ivan.miljenovic at gmail.com> wrote:
>> On 30 May 2016 at 06:32, David Feuer <david.feuer at gmail.com> wrote:
>>> I've come up with an implementation of
>>>
>>> insertAt :: Int -> a -> Seq a -> Seq a
>>> -- Defined to be equivalent to
>>> insertAt i x xs
>>>    | i < 0 || i > length xs = error "insertAt: index out of range"
>>>    | otherwise = take i xs <> singleton x <> drop i xs
>>>
>>> that inserts the given element at the given index with very little
>>> tree restructuring. I came up with the vague notion that it might be
>>> interesting to try to do something like this early last year, but I
>>> wasn't sure how at the time. I largely forgot about it until today,
>>> when someone on StackOverflow pointed to the issue I'd opened and
>>> asked if it would be implemented, presumably because he wants it. What
>>> do y'all think?
>>
>> The partiality is a little troubling; would it be feasible from a
>> usage point of view to have this function return a Maybe?
>>
>> --
>> Ivan Lazar Miljenovic
>> Ivan.Miljenovic at gmail.com
>> http://IvanMiljenovic.wordpress.com
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/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://www2.tcs.ifi.lmu.de/~abel/

From abela at chalmers.se  Mon May 30 06:12:04 2016
From: abela at chalmers.se (Andreas Abel)
Date: Mon, 30 May 2016 08:12:04 +0200
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CAJumaK8gX-puHi0sSiJWqBhOayM3tZrNBD82EJa7ti1nVg14nA@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
 <CAMgWh9sW=aUyQ7b419XyAL=gXp=6j_Yo_HBppgZXoNTHh_S8Lw@mail.gmail.com>
 <20160529223558.GA10336@casa.casa>
 <CAMgWh9toQmOno1cF+O9o9kHahb5VyGMU4xGbXn8to7HCr5O73w@mail.gmail.com>
 <CAJumaK_qj_07mL+edWLDM_h_98+Pazt+Pztz-XVGPQ7by8eF=Q@mail.gmail.com>
 <CAJumaK8iZ8E1T-TRpQR3UfnBU=o5u_HpC9iKnsOmDnYeSPknVg@mail.gmail.com>
 <CAJumaK8gX-puHi0sSiJWqBhOayM3tZrNBD82EJa7ti1nVg14nA@mail.gmail.com>
Message-ID: <574BD9B4.1080306@chalmers.se>

+1 for lookup.

On 30.05.2016 04:48, Edward Kmett wrote:
> Then again, most of Data.Sequence already clashes with the Prelude.
>
> On Sun, May 29, 2016 at 10:47 PM, Edward Kmett <ekmett at gmail.com
> <mailto:ekmett at gmail.com>> wrote:
>
>     Oops. Prelude. No I guess it doesn't.
>
>     On Sun, May 29, 2016 at 9:40 PM, Edward Kmett <ekmett at gmail.com
>     <mailto:ekmett at gmail.com>> wrote:
>
>         lookup works for me.
>
>         -Edward
>
>         On Sun, May 29, 2016 at 6:52 PM, David Feuer
>         <david.feuer at gmail.com <mailto:david.feuer at gmail.com>> wrote:
>
>             I'm tempted to go with `lookup`, to match Data.IntMap.
>
>             On Sun, May 29, 2016 at 6:35 PM, Francesco Ariis
>             <fa-ml at ariis.it <mailto:fa-ml at ariis.it>> wrote:
>              > On Sun, May 29, 2016 at 06:28:25PM -0400, David Feuer wrote:
>              >> I don't like that bikeshed color much either. Go ahead
>             and suggest
>              >> something else.
>              >
>              > safeIndex? totalIndex? Best solution would be to rename
>             index to
>              > unsafeIndex and your proposed function to index, but it's
>             obviously
>              > not practicable.
>              > _______________________________________________
>              > Libraries mailing list
>              > Libraries at haskell.org <mailto:Libraries at haskell.org>
>              > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>             _______________________________________________
>             Libraries mailing list
>             Libraries at haskell.org <mailto: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
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From m.farkasdyck at gmail.com  Mon May 30 06:16:06 2016
From: m.farkasdyck at gmail.com (M Farkas-Dyck)
Date: Sun, 29 May 2016 22:16:06 -0800
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
Message-ID: <CAL3m8eBj94Te8=6oo_omTXd-=0ioP+JizJ=e_n2Df4ib9pE2TQ@mail.gmail.com>

On 20/05/2016, Anton Felix Lorenzen <anfelor at posteo.de> wrote:
> fromRight :: Either a b -> b
> fromLeft  :: Either a b -> a

-1 partial functions in base

On 21/05/2016, Edward Kmett <ekmett at gmail.com> wrote:
> remove [fromJust], head, tail

+1 ?

From lsp at informatik.uni-kiel.de  Mon May 30 07:29:01 2016
From: lsp at informatik.uni-kiel.de (lennart spitzner)
Date: Mon, 30 May 2016 09:29:01 +0200
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <CAJumaK_wczX2MBPxX0jxhiRcyDUa_JOVY+zBoH57Veq5Tr8nPg@mail.gmail.com>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
 <5740A3BA.10306@chalmers.se>
 <CABUjdS5CmMY8s-g1WQ_ktBL-G6D=e+m2E6WLMZiVRsw9f2mZQA@mail.gmail.com>
 <CAOaSQ4fBm=ZuJx-Sp0h0eB7mnePNayONWy8om9oxBJFh=URC5Q@mail.gmail.com>
 <CAJumaK_wczX2MBPxX0jxhiRcyDUa_JOVY+zBoH57Veq5Tr8nPg@mail.gmail.com>
Message-ID: <03516ce9-639d-4443-6d34-9c43e456d5a2@informatik.uni-kiel.de>

On 30/05/16 03:40, Edward Kmett wrote:
> The main annoyance with the total versions is that the existing fromJust
> has the wrong convention.
> 
> Oh well. Consistency is overrated.

So you don't mind the breaking change in the `either` package?

For the lazy; `either` defines:

> Data.Either.Combinators.fromLeft  :: a -> Either a b -> a 
> Data.Either.Combinators.fromLeft' :: Either a b -> a
(~Right similarly)

Also, packages `MissingH` and `extra` define the consistent

> fromLeft :: Either a b -> a

(don't know if user numbers of those count as significant in any way.)

-1 on both partial and inconsistent total

From jon.fairbairn at cl.cam.ac.uk  Mon May 30 08:11:58 2016
From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn)
Date: Mon, 30 May 2016 09:11:58 +0100
Subject: Proposal: Add `maxOn` and `minOn` functions to Data.Ord
References: <CAJFXAQhWvWZFWMpCT9B7X+=xf7cwJu18WGZQe7nF3MKw+B0GbA@mail.gmail.com>
Message-ID: <wfy46st169.fsf@calligramme.charmers>

Daniel D?az Casanueva <dhelta.diaz at gmail.com> writes:

> I think these are useful in general, and that they would make a good
> addition to `Data.Ord`. The names are inspired by `sortOn`. Definitions:
>
> ```
> minOn :: Ord b => (a -> b) -> a -> a -> a
> minOn f x y =
>   case comparing f x y of
>     LT -> x
>     _ -> y

Bad name; it?s too close to on min, which has the same type.

-- 
J?n Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk



From ivan.miljenovic at gmail.com  Mon May 30 08:16:33 2016
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Mon, 30 May 2016 18:16:33 +1000
Subject: Proposal: Add `maxOn` and `minOn` functions to Data.Ord
In-Reply-To: <wfy46st169.fsf@calligramme.charmers>
References: <CAJFXAQhWvWZFWMpCT9B7X+=xf7cwJu18WGZQe7nF3MKw+B0GbA@mail.gmail.com>
 <wfy46st169.fsf@calligramme.charmers>
Message-ID: <CA+u6gbz7E2Pj7D8gFf+DjGe8vzTWem88HDb2QL1zTjzcuCwx9g@mail.gmail.com>

On 30 May 2016 at 18:11, Jon Fairbairn <jon.fairbairn at cl.cam.ac.uk> wrote:
> Daniel D?az Casanueva <dhelta.diaz at gmail.com> writes:
>> minOn :: Ord b => (a -> b) -> a -> a -> a
>> minOn f x y =
>>   case comparing f x y of
>>     LT -> x
>>     _ -> y
>
> Bad name; it?s too close to on min, which has the same type.

Not quite:

> :t on min
on min :: Ord c => (a -> c) -> a -> a -> c

(note the return type is different)

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From jon.fairbairn at cl.cam.ac.uk  Mon May 30 08:29:38 2016
From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn)
Date: Mon, 30 May 2016 09:29:38 +0100
Subject: Proposal: Add `maxOn` and `minOn` functions to Data.Ord
References: <CAJFXAQhWvWZFWMpCT9B7X+=xf7cwJu18WGZQe7nF3MKw+B0GbA@mail.gmail.com>
 <wfy46st169.fsf@calligramme.charmers>
 <CA+u6gbz7E2Pj7D8gFf+DjGe8vzTWem88HDb2QL1zTjzcuCwx9g@mail.gmail.com>
Message-ID: <wftwhgt0ct.fsf@calligramme.charmers>

Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> writes:

> On 30 May 2016 at 18:11, Jon Fairbairn <jon.fairbairn at cl.cam.ac.uk> wrote:
>> Daniel D?az Casanueva <dhelta.diaz at gmail.com> writes:
>>> minOn :: Ord b => (a -> b) -> a -> a -> a
>>> minOn f x y =
>>>   case comparing f x y of
>>>     LT -> x
>>>     _ -> y
>>
>> Bad name; it?s too close to on min, which has the same type.
>
> Not quite:
>
>> :t on min
> on min :: Ord c => (a -> c) -> a -> a -> c
>
> (note the return type is different)

Yes, sorry. /nearly/ the same type. Still too much risk of confusion.

-- 
J?n Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk



From andreas.abel at ifi.lmu.de  Mon May 30 10:54:26 2016
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Mon, 30 May 2016 12:54:26 +0200
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <03516ce9-639d-4443-6d34-9c43e456d5a2@informatik.uni-kiel.de>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
 <5740A3BA.10306@chalmers.se>
 <CABUjdS5CmMY8s-g1WQ_ktBL-G6D=e+m2E6WLMZiVRsw9f2mZQA@mail.gmail.com>
 <CAOaSQ4fBm=ZuJx-Sp0h0eB7mnePNayONWy8om9oxBJFh=URC5Q@mail.gmail.com>
 <CAJumaK_wczX2MBPxX0jxhiRcyDUa_JOVY+zBoH57Veq5Tr8nPg@mail.gmail.com>
 <03516ce9-639d-4443-6d34-9c43e456d5a2@informatik.uni-kiel.de>
Message-ID: <574C1BE2.5010909@ifi.lmu.de>

On 30.05.2016 09:29, lennart spitzner wrote:
> For the lazy; `either` defines:
>
>> Data.Either.Combinators.fromLeft  :: a -> Either a b -> a

This is the thing we want.


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From lsp at informatik.uni-kiel.de  Mon May 30 11:33:18 2016
From: lsp at informatik.uni-kiel.de (lennart spitzner)
Date: Mon, 30 May 2016 13:33:18 +0200
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <574C1BE2.5010909@ifi.lmu.de>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
 <5740A3BA.10306@chalmers.se>
 <CABUjdS5CmMY8s-g1WQ_ktBL-G6D=e+m2E6WLMZiVRsw9f2mZQA@mail.gmail.com>
 <CAOaSQ4fBm=ZuJx-Sp0h0eB7mnePNayONWy8om9oxBJFh=URC5Q@mail.gmail.com>
 <CAJumaK_wczX2MBPxX0jxhiRcyDUa_JOVY+zBoH57Veq5Tr8nPg@mail.gmail.com>
 <03516ce9-639d-4443-6d34-9c43e456d5a2@informatik.uni-kiel.de>
 <574C1BE2.5010909@ifi.lmu.de>
Message-ID: <be988c87-5e08-4fd6-3fb6-d4c8a8ea10da@informatik.uni-kiel.de>

>>> Data.Either.Combinators.fromLeft  :: a -> Either a b -> a
> 
> This is the thing we want.

Oh indeed, derp; still had the first suggestion in mind.
(b -> (a -> b) -> Either ..)

On this one i am neutral.


From alan.isaac at gmail.com  Mon May 30 13:21:57 2016
From: alan.isaac at gmail.com (Alan Isaac)
Date: Mon, 30 May 2016 09:21:57 -0400
Subject: Proposal: Add // for Data.Sequence
Message-ID: <67ce4f89-9096-04ee-a8b1-e8cdb0b73633@gmail.com>

BACKGROUND
----------

Data.Array provides (//) for incremental array updates.
Data.Sequence lacks this useful functionality.


SCOPE
-----

Doing this efficiently may require that Data.Sequence
access Data.IntMap. (It currently does not.)

David Feuer commented:
We may need to add some more splitting functions to Data.IntMap,
if it supports them, but we probably want to do so anyway to
match up with Data.Map.


SOLUTIONS
-----------

David Feuer offered the following implementation sketch.
(See https://github.com/haskell/containers/issues/262)

Collect all requested changes into an IntMap,
then use something similar to Data.Sequence.splitMap
with Data.IntMap.split to spread them through the tree.

David Feuer commented: splitMap itself is overkill,
because we'll likely be able to preserve whole subtrees.


WHAT MIGHT BREAK
----------------

No anticipated breakage.

From _deepfire at feelingofgreen.ru  Mon May 30 13:38:34 2016
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Mon, 30 May 2016 16:38:34 +0300
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <be988c87-5e08-4fd6-3fb6-d4c8a8ea10da@informatik.uni-kiel.de>
 (sfid-20160530_160710_882736_7BA13210) (lennart spitzner's message of
 "Mon, 30 May 2016 13:33:18 +0200")
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
 <5740A3BA.10306@chalmers.se>
 <CABUjdS5CmMY8s-g1WQ_ktBL-G6D=e+m2E6WLMZiVRsw9f2mZQA@mail.gmail.com>
 <CAOaSQ4fBm=ZuJx-Sp0h0eB7mnePNayONWy8om9oxBJFh=URC5Q@mail.gmail.com>
 <CAJumaK_wczX2MBPxX0jxhiRcyDUa_JOVY+zBoH57Veq5Tr8nPg@mail.gmail.com>
 <03516ce9-639d-4443-6d34-9c43e456d5a2@informatik.uni-kiel.de>
 <574C1BE2.5010909@ifi.lmu.de>
 <be988c87-5e08-4fd6-3fb6-d4c8a8ea10da@informatik.uni-kiel.de>
Message-ID: <8737ozfyxx.fsf@feelingofgreen.ru>

lennart spitzner <lsp at informatik.uni-kiel.de> writes:
>>>> Data.Either.Combinators.fromLeft  :: a -> Either a b -> a
>> 
>> This is the thing we want.
>
> Oh indeed, derp; still had the first suggestion in mind.
> (b -> (a -> b) -> Either ..)
>
> On this one i am neutral.

How should we address the part where we don't want to promote
Partiality Oriented Programming?

-- 
? ???????e? / respectfully,
??????? ??????

From evan at evanrutledgeborden.dreamhosters.com  Tue May 31 03:25:56 2016
From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com)
Date: Mon, 30 May 2016 23:25:56 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <8737ozfyxx.fsf@feelingofgreen.ru>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
 <5740A3BA.10306@chalmers.se>
 <CABUjdS5CmMY8s-g1WQ_ktBL-G6D=e+m2E6WLMZiVRsw9f2mZQA@mail.gmail.com>
 <CAOaSQ4fBm=ZuJx-Sp0h0eB7mnePNayONWy8om9oxBJFh=URC5Q@mail.gmail.com>
 <CAJumaK_wczX2MBPxX0jxhiRcyDUa_JOVY+zBoH57Veq5Tr8nPg@mail.gmail.com>
 <03516ce9-639d-4443-6d34-9c43e456d5a2@informatik.uni-kiel.de>
 <574C1BE2.5010909@ifi.lmu.de>
 <be988c87-5e08-4fd6-3fb6-d4c8a8ea10da@informatik.uni-kiel.de>
 <8737ozfyxx.fsf@feelingofgreen.ru>
Message-ID: <CABmRwSC499CQZYmhVS9fEKLqatVg2RzQtqN4Lood27g8wtEVZA@mail.gmail.com>

-1 for partial.

Indifferent on the total versions.

`either (const _) id` is easy enough.
On May 30, 2016 9:38 AM, "Kosyrev Serge" <_deepfire at feelingofgreen.ru>
wrote:

> lennart spitzner <lsp at informatik.uni-kiel.de> writes:
> >>>> Data.Either.Combinators.fromLeft  :: a -> Either a b -> a
> >>
> >> This is the thing we want.
> >
> > Oh indeed, derp; still had the first suggestion in mind.
> > (b -> (a -> b) -> Either ..)
> >
> > On this one i am neutral.
>
> How should we address the part where we don't want to promote
> Partiality Oriented Programming?
>
> --
> ? ???????e? / respectfully,
> ??????? ??????
> _______________________________________________
> 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/20160530/3c5eb96b/attachment.html>

From winterkoninkje at gmail.com  Tue May 31 08:38:25 2016
From: winterkoninkje at gmail.com (wren romano)
Date: Tue, 31 May 2016 04:38:25 -0400
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
Message-ID: <CABUjdS5Jw9r64+Tgwm0-Yqpx+DGfk7_zCf7WCoFELYTOfrxb5w@mail.gmail.com>

On Sun, May 29, 2016 at 6:12 PM, Ivan Lazar Miljenovic
<ivan.miljenovic at gmail.com> wrote:
> On 30 May 2016 at 07:21, David Feuer <david.feuer at gmail.com> wrote:
>> Data.Sequence offers
>>
>> index :: Seq a -> Int -> a
>>
>> which throws an error if the index is out of range. I'd like to add
>> something like
>>
>> indexMay :: Seq a -> Int -> Maybe a
>
> +1
>
> (I personally don't like the "May" prefix used for functions like this
> as I don't find it very readable, but not enough to argue over the
> colour of the bikeshed ;-)

I too am +1 for the total function, but -1 for the "May" naming scheme.

I'd go with "lookup", since that's what (Int)Map does.

I'd also be fine with Vector's (!?) if folks really want a symbolic
name. (IME this function tends to work better with an alphabetic name,
ymmv)

-- 
Live well,
~wren

From tikhon at jelv.is  Tue May 31 08:46:34 2016
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Tue, 31 May 2016 01:46:34 -0700
Subject: Discussion: Add total indexing function to Data.Sequence
In-Reply-To: <CABUjdS5Jw9r64+Tgwm0-Yqpx+DGfk7_zCf7WCoFELYTOfrxb5w@mail.gmail.com>
References: <CAMgWh9vvLbY6WMKLw5O=vXBD_rWUPOhPxUrkLBmuMz40Rs-vCQ@mail.gmail.com>
 <CA+u6gbzjmpEdyko8=kETjkfqCXfRW0SKkFX+b_GudCB-e+V+tw@mail.gmail.com>
 <CABUjdS5Jw9r64+Tgwm0-Yqpx+DGfk7_zCf7WCoFELYTOfrxb5w@mail.gmail.com>
Message-ID: <CAJN5CVKHhPAxmK1-L3R9UZKMCz7rO4+DL28mJgErK9y_tqwLCQ@mail.gmail.com>

+1 from me on 'lookup' and '!?'. Personally, I found the '!?' name
intuitive immediately when I first saw it in Vector, so I'm a fan of it.
Not as sure about 'lookup' because what it does on lists and maps is
different from indexing (ie it works with key-value pairs), but it does
scan significantly better than 'indexMay'.

On Tue, May 31, 2016 at 1:38 AM, wren romano <winterkoninkje at gmail.com>
wrote:

> On Sun, May 29, 2016 at 6:12 PM, Ivan Lazar Miljenovic
> <ivan.miljenovic at gmail.com> wrote:
> > On 30 May 2016 at 07:21, David Feuer <david.feuer at gmail.com> wrote:
> >> Data.Sequence offers
> >>
> >> index :: Seq a -> Int -> a
> >>
> >> which throws an error if the index is out of range. I'd like to add
> >> something like
> >>
> >> indexMay :: Seq a -> Int -> Maybe a
> >
> > +1
> >
> > (I personally don't like the "May" prefix used for functions like this
> > as I don't find it very readable, but not enough to argue over the
> > colour of the bikeshed ;-)
>
> I too am +1 for the total function, but -1 for the "May" naming scheme.
>
> I'd go with "lookup", since that's what (Int)Map does.
>
> I'd also be fine with Vector's (!?) if folks really want a symbolic
> name. (IME this function tends to work better with an alphabetic name,
> ymmv)
>
> --
> Live well,
> ~wren
> _______________________________________________
> 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/20160531/9a52d9dc/attachment.html>

From ekmett at gmail.com  Tue May 31 22:17:28 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 31 May 2016 18:17:28 -0400
Subject: Proposal: add fromRight and fromLeft to Data.Either
In-Reply-To: <03516ce9-639d-4443-6d34-9c43e456d5a2@informatik.uni-kiel.de>
References: <b2225ce4-7835-c30c-c0ba-470b9400208c@posteo.de>
 <CAJumaK_2972Mq4W-Y79LHDfr1-b9b7n_M4o6K05Gh3t=O7OJEg@mail.gmail.com>
 <CAMgWh9tH7_d7WSpwr_xEnTM4fuTUkUDrnEh_=zjyRvG=+YMwjg@mail.gmail.com>
 <CAMgWh9upV3to7f8dXyhaKDb9L37bHYB3ykZCmdOeG3SLDbX7Hw@mail.gmail.com>
 <CAJumaK-vSjq8SPoPLHDfunpnW4qjkCxouepWMwn_VPNj3f_Y4A@mail.gmail.com>
 <5740A3BA.10306@chalmers.se>
 <CABUjdS5CmMY8s-g1WQ_ktBL-G6D=e+m2E6WLMZiVRsw9f2mZQA@mail.gmail.com>
 <CAOaSQ4fBm=ZuJx-Sp0h0eB7mnePNayONWy8om9oxBJFh=URC5Q@mail.gmail.com>
 <CAJumaK_wczX2MBPxX0jxhiRcyDUa_JOVY+zBoH57Veq5Tr8nPg@mail.gmail.com>
 <03516ce9-639d-4443-6d34-9c43e456d5a2@informatik.uni-kiel.de>
Message-ID: <CAJumaK_0VFyYYoByzW0wz0WSUSp3dnMXU-z_RPz10gcsuXTt_A@mail.gmail.com>

It is a minor annoyance, not a -1. The fromLeft and fromRight there got
merged in from another package when we started consolidating.

I've never really given them conscious thought, but on the plus side, I'd
get to just re-export the combinators from base in Data.Either.Combinators
avoiding conflicts.

I'm a weak +1 on adding the total versions that Wren espoused above.

-Edward

On Mon, May 30, 2016 at 3:29 AM, lennart spitzner <
lsp at informatik.uni-kiel.de> wrote:

> On 30/05/16 03:40, Edward Kmett wrote:
> > The main annoyance with the total versions is that the existing fromJust
> > has the wrong convention.
> >
> > Oh well. Consistency is overrated.
>
> So you don't mind the breaking change in the `either` package?
>
> For the lazy; `either` defines:
>
> > Data.Either.Combinators.fromLeft  :: a -> Either a b -> a
> > Data.Either.Combinators.fromLeft' :: Either a b -> a
> (~Right similarly)
>
> Also, packages `MissingH` and `extra` define the consistent
>
> > fromLeft :: Either a b -> a
>
> (don't know if user numbers of those count as significant in any way.)
>
> -1 on both partial and inconsistent total
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160531/485f736a/attachment.html>