From simonpj at microsoft.com  Tue Jan  2 10:07:45 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 2 Jan 2018 10:07:45 +0000
Subject: Constraint implication
In-Reply-To: <CAJumaK_3LicCte6f7RKrmBOGko+eGZJqSyuOy3or9wMzEm0gxg@mail.gmail.com>
References: <CAO8Ockt5pDpjGj+1R-0K0-Gs=AaNwZvJduVKJ_QgmGPazMnZvQ@mail.gmail.com>
 <CAJumaK_3LicCte6f7RKrmBOGko+eGZJqSyuOy3or9wMzEm0gxg@mail.gmail.com>
Message-ID: <VI1PR83MB02051D193362CCD618B1A5FBAD190@VI1PR83MB0205.EURPRD83.prod.outlook.com>

Getting this stuff into GHC is the tricky part!
Indeed… but step 1 is to articulate a well-formed specification.  I’m not close enough to this conversation to understand all the details, let alone form a specification.  But perhaps some of you are.

I think (2) is described here: https://ghc.haskell.org/trac/ghc/wiki/QuantifiedContexts.  I have been keen on this proposal for years, just lacking time to execute on it.

Simon

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Edward Kmett
Sent: 27 December 2017 19:18
To: Ryan Reich <ryan.reich at gmail.com>
Cc: Haskell Libraries <libraries at haskell.org>
Subject: Re: Constraint implication

Just a few old observations I've made from implementing these things into type systems of my own:

1.) An internal hom for the category of constraints is admissible:

(|-) :: Constraint -> Constraint -> Constraint

models entailment, and effectively brings into scope a local rule, but global instance resolution isn't lost if this is only produced from existing instances.

To your point, this is analogous to the (:-) :: Constraint -> Constraint -> * external hom for the category of constraints provided by my constraints package, but it is internal, with all of the appropriate CCC operations.

2.) Quantification over constraints is also admissible.

Neither one compromises the "thinness" of the category of constraints that provides us global coherence of instance resolution

In this case the property that if D is thin, so is [C,D]. forall here can quantify over any other kind you want.

Unfortunately, neither implemented in Haskell.

You'd need both of them to be able to talk about constraints like (forall a. Eq a |- Eq (f a)).

Together could eliminate, morally, the entire Data.Functor.Classes mess. (That said, as implemented those classes are a bit stronger than the quantified form)

3.) Constraint also admits a sum type, (\/) but it acts more like a least upper bound than an either.

It is much easier to talk about in the category of constraints using the first part above.

Given (p |- r, q |- r), (p \/ q) |- r and vice versa.

The key to keeping the category of constraints thin is that you can't case analyze on it, its more like if you look at, say, Ord [a] \/ Eq a you can get to any constraint that you could get to given the intersection of both, not using the particulars of either. e.g. its morally as powerful as Eq [a] in this case.

Getting this stuff into GHC is the tricky part!

-Edward

On Wed, Dec 27, 2017 at 2:50 AM, Ryan Reich <ryan.reich at gmail.com<mailto:ryan.reich at gmail.com>> wrote:
The Constraint kind appears to lack an interface to an important capability that is already part of the type checker: constraint implication.  Namely, the ability to provide a witness for the statement "constraint c1 implies constraint c2" or, more importantly, "for all a, constraint (c1 a) implies constraint (c2 a)", where c1 and c2 are now constraint-valued type functions (and possibly even for constraint functions with multiple parameters).  It seems to me that this can follow the pattern of the "magic" Coercible type class and the (non-magic) Coercion data type; it provides the programmer with an analogous value to this example that can be obtained in apparently no other way.

_______________________________________________
Libraries mailing list
Libraries at haskell.org<mailto:Libraries at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flibraries&data=04%7C01%7Csimonpj%40microsoft.com%7C8f41822fa9ff4b253ea808d54d5e9adc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636499991092450873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=QquaudC3jd%2FHr33l6N3e0OCRRK8%2F2qhYX7p5m3uSyAc%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180102/8ee3f923/attachment.html>

From david.feuer at gmail.com  Tue Jan  2 10:41:28 2018
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 2 Jan 2018 05:41:28 -0500
Subject: Constraint implication
In-Reply-To: <VI1PR83MB02051D193362CCD618B1A5FBAD190@VI1PR83MB0205.EURPRD83.prod.outlook.com>
References: <CAO8Ockt5pDpjGj+1R-0K0-Gs=AaNwZvJduVKJ_QgmGPazMnZvQ@mail.gmail.com>
 <CAJumaK_3LicCte6f7RKrmBOGko+eGZJqSyuOy3or9wMzEm0gxg@mail.gmail.com>
 <VI1PR83MB02051D193362CCD618B1A5FBAD190@VI1PR83MB0205.EURPRD83.prod.outlook.com>
Message-ID: <CAMgWh9u9hsQstNCpO7Zh_GiToN19RaajO=xGjOcih1uAjnY2Xw@mail.gmail.com>

For whatever it's worth, it seems to me that the two next steps, in no
particular order, should likely be

1. Add quantified contexts. These should obsolete Data.Constraint.Forall by
offering a much nicer API (without needing to use `inst`, etc., manually).

2. Add the ability to at least express constraint implication at the
constraint level, and propagate some of that information automatically.
Trying to be too clever seems to run into backtracking, so it's not clear
that we should try to jump straight to a full constraint implication
system. If we could even get a version that requires manual guidance to use
(like Data.Constraint.Forall does today), we'd surely be making some
progress.

On Jan 2, 2018 5:08 AM, "Simon Peyton Jones via Libraries" <
libraries at haskell.org> wrote:

> Getting this stuff into GHC is the tricky part!
>
> Indeed… but step 1 is to articulate a well-formed specification.  I’m not
> close enough to this conversation to understand all the details, let alone
> form a specification.  But perhaps some of you are.
>
>
>
> I think (2) is described here: https://ghc.haskell.org/trac/
> ghc/wiki/QuantifiedContexts.  I have been keen on this proposal for
> years, just lacking time to execute on it.
>
>
>
> Simon
>
>
>
> *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Edward
> Kmett
> *Sent:* 27 December 2017 19:18
> *To:* Ryan Reich <ryan.reich at gmail.com>
> *Cc:* Haskell Libraries <libraries at haskell.org>
> *Subject:* Re: Constraint implication
>
>
>
> Just a few old observations I've made from implementing these things into
> type systems of my own:
>
>
>
> 1.) An internal hom for the category of constraints is admissible:
>
>
>
> (|-) :: Constraint -> Constraint -> Constraint
>
>
>
> models entailment, and effectively brings into scope a local rule, but
> global instance resolution isn't lost if this is only produced from
> existing instances.
>
>
>
> To your point, this is analogous to the (:-) :: Constraint -> Constraint
> -> * external hom for the category of constraints provided by my
> constraints package, but it is internal, with all of the appropriate CCC
> operations.
>
>
>
> 2.) Quantification over constraints is also admissible.
>
>
>
> Neither one compromises the "thinness" of the category of constraints that
> provides us global coherence of instance resolution
>
>
>
> In this case the property that if D is thin, so is [C,D]. forall here can
> quantify over any other kind you want.
>
>
>
> Unfortunately, neither implemented in Haskell.
>
>
>
> You'd need both of them to be able to talk about constraints like (forall
> a. Eq a |- Eq (f a)).
>
>
>
> Together could eliminate, morally, the entire Data.Functor.Classes mess.
> (That said, as implemented those classes are a bit stronger than the
> quantified form)
>
>
>
> 3.) Constraint also admits a sum type, (\/) but it acts more like a least
> upper bound than an either.
>
>
>
> It is much easier to talk about in the category of constraints using the
> first part above.
>
>
>
> Given (p |- r, q |- r), (p \/ q) |- r and vice versa.
>
>
>
> The key to keeping the category of constraints thin is that you can't case
> analyze on it, its more like if you look at, say, Ord [a] \/ Eq a you can
> get to any constraint that you could get to given the intersection of both,
> not using the particulars of either. e.g. its morally as powerful as Eq [a]
> in this case.
>
>
>
> Getting this stuff into GHC is the tricky part!
>
>
>
> -Edward
>
>
>
> On Wed, Dec 27, 2017 at 2:50 AM, Ryan Reich <ryan.reich at gmail.com> wrote:
>
> The Constraint kind appears to lack an interface to an important
> capability that is already part of the type checker: constraint
> implication.  Namely, the ability to provide a witness for the statement
> "constraint c1 implies constraint c2" or, more importantly, "for all a,
> constraint (c1 a) implies constraint (c2 a)", where c1 and c2 are now
> constraint-valued type functions (and possibly even for constraint
> functions with multiple parameters).  It seems to me that this can follow
> the pattern of the "magic" Coercible type class and the (non-magic)
> Coercion data type; it provides the programmer with an analogous value to
> this example that can be obtained in apparently no other way.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flibraries&data=04%7C01%7Csimonpj%40microsoft.com%7C8f41822fa9ff4b253ea808d54d5e9adc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636499991092450873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=QquaudC3jd%2FHr33l6N3e0OCRRK8%2F2qhYX7p5m3uSyAc%3D&reserved=0>
>
>
>
> _______________________________________________
> 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/20180102/77b24ec9/attachment-0001.html>

From simons at nospf.cryp.to  Thu Jan 11 14:50:09 2018
From: simons at nospf.cryp.to (Peter Simons)
Date: Thu, 11 Jan 2018 15:50:09 +0100
Subject: Taking over maintainership of cabal2spec
Message-ID: <87inc8fo0u.fsf@write-only.cryp.to>

Fellow Haskell Hackers,

I would like to take over the package cabal2spec [1], which hasn't seen
any activity in the last 9 years. I have tried to contact the Hackage
maintainers Conrad Meyer and Yaakov M. Nemoy to get them involved in the
decision, but unfortunately I was unable to reach either one of them.

Best regards,
Peter



[1] http://hackage.haskell.org/package/cabal2spec


From david.feuer at gmail.com  Fri Jan 12 03:28:37 2018
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 11 Jan 2018 22:28:37 -0500
Subject: Proposal: add unzips for Data.Sequence
In-Reply-To: <CAMgWh9sL7e9kRb_SGZNyrL0ZHQV=EZP+=KOfSjq2Xj91psVACQ@mail.gmail.com>
References: <CAMgWh9ua+BEsxvrMCQnvxuj9cmxCFyzFgtN4wOujGX1Bb0ZTmg@mail.gmail.com>
 <CAMgWh9sL7e9kRb_SGZNyrL0ZHQV=EZP+=KOfSjq2Xj91psVACQ@mail.gmail.com>
Message-ID: <CAMgWh9vE54HxJAGeeKXBpHq8SmHnq0bbQnQZk748BCt02TTTrw@mail.gmail.com>

Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function to
Data.Sequence. I agree. I propose adding

  unzip :: Seq (a,b) -> (Seq a, Seq b)

  unzipWith :: (x -> (a, b)) -> Seq x -> (Seq a, Seq b)

Does anyone object?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180111/9b6cb876/attachment.html>

From ivan.miljenovic at gmail.com  Fri Jan 12 03:32:19 2018
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Fri, 12 Jan 2018 13:32:19 +1000
Subject: Proposal: add unzips for Data.Sequence
In-Reply-To: <CAMgWh9vE54HxJAGeeKXBpHq8SmHnq0bbQnQZk748BCt02TTTrw@mail.gmail.com>
References: <CAMgWh9ua+BEsxvrMCQnvxuj9cmxCFyzFgtN4wOujGX1Bb0ZTmg@mail.gmail.com>
 <CAMgWh9sL7e9kRb_SGZNyrL0ZHQV=EZP+=KOfSjq2Xj91psVACQ@mail.gmail.com>
 <CAMgWh9vE54HxJAGeeKXBpHq8SmHnq0bbQnQZk748BCt02TTTrw@mail.gmail.com>
Message-ID: <CA+u6gbxsTEXfG4CwhafTsAnjR2z6wze3UfqW=R8JMdgadwS8qQ@mail.gmail.com>

On 12 January 2018 at 13:28, David Feuer <david.feuer at gmail.com> wrote:
> Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function to
> Data.Sequence. I agree. I propose adding
>
>   unzip :: Seq (a,b) -> (Seq a, Seq b)
>
>   unzipWith :: (x -> (a, b)) -> Seq x -> (Seq a, Seq b)
>
> Does anyone object?

I see no problem with this.  Though I think it's worth pointing out
that Data.List doesn't have unzipWith (though unzipWith f = unzip .
map f).

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

From david.feuer at gmail.com  Fri Jan 12 04:54:29 2018
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 11 Jan 2018 23:54:29 -0500
Subject: Proposal: add unzips for Data.Sequence
In-Reply-To: <CA+u6gbxsTEXfG4CwhafTsAnjR2z6wze3UfqW=R8JMdgadwS8qQ@mail.gmail.com>
References: <CAMgWh9ua+BEsxvrMCQnvxuj9cmxCFyzFgtN4wOujGX1Bb0ZTmg@mail.gmail.com>
 <CAMgWh9sL7e9kRb_SGZNyrL0ZHQV=EZP+=KOfSjq2Xj91psVACQ@mail.gmail.com>
 <CAMgWh9vE54HxJAGeeKXBpHq8SmHnq0bbQnQZk748BCt02TTTrw@mail.gmail.com>
 <CA+u6gbxsTEXfG4CwhafTsAnjR2z6wze3UfqW=R8JMdgadwS8qQ@mail.gmail.com>
Message-ID: <CAMgWh9vzSpbAqNZwnc1ZK7dPOrVRsEqvw-V1QiFHrk78MNbMgA@mail.gmail.com>

We don't strictly *need* to add either of these functions. Users can use
munzip from the MonadZip instance, and we can add a rewrite rule to turn

    munzip (fmap f xs)

into

    Data.Sequence.Internal.unzipWith f xs

On the other hand, MonadZip isn't a terribly well-known class, and
unzipWith has always struck me as an obvious analogue of zipWith.

On Jan 11, 2018 10:32 PM, "Ivan Lazar Miljenovic" <ivan.miljenovic at gmail.com>
wrote:

> On 12 January 2018 at 13:28, David Feuer <david.feuer at gmail.com> wrote:
> > Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function to
> > Data.Sequence. I agree. I propose adding
> >
> >   unzip :: Seq (a,b) -> (Seq a, Seq b)
> >
> >   unzipWith :: (x -> (a, b)) -> Seq x -> (Seq a, Seq b)
> >
> > Does anyone object?
>
> I see no problem with this.  Though I think it's worth pointing out
> that Data.List doesn't have unzipWith (though unzipWith f = unzip .
> map f).
>
> --
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com
> http://IvanMiljenovic.wordpress.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180111/ab2abc1a/attachment.html>

From tikhon at jelv.is  Fri Jan 12 06:47:46 2018
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Thu, 11 Jan 2018 22:47:46 -0800
Subject: Proposal: add unzips for Data.Sequence
In-Reply-To: <CAMgWh9vzSpbAqNZwnc1ZK7dPOrVRsEqvw-V1QiFHrk78MNbMgA@mail.gmail.com>
References: <CAMgWh9ua+BEsxvrMCQnvxuj9cmxCFyzFgtN4wOujGX1Bb0ZTmg@mail.gmail.com>
 <CAMgWh9sL7e9kRb_SGZNyrL0ZHQV=EZP+=KOfSjq2Xj91psVACQ@mail.gmail.com>
 <CAMgWh9vE54HxJAGeeKXBpHq8SmHnq0bbQnQZk748BCt02TTTrw@mail.gmail.com>
 <CA+u6gbxsTEXfG4CwhafTsAnjR2z6wze3UfqW=R8JMdgadwS8qQ@mail.gmail.com>
 <CAMgWh9vzSpbAqNZwnc1ZK7dPOrVRsEqvw-V1QiFHrk78MNbMgA@mail.gmail.com>
Message-ID: <CAJN5CVLDvN8sbykhPQrFd0_tSiUfVgMixRy9UnaxH7Vhdsm_Rw@mail.gmail.com>

I did not know about MonadZip and wouldn't have thought to look for it.

On the other hand, unzip and unzipWith are immediately intuitive.

I think they'd be a solid addition.

On Thu, Jan 11, 2018 at 8:54 PM, David Feuer <david.feuer at gmail.com> wrote:

> We don't strictly *need* to add either of these functions. Users can use
> munzip from the MonadZip instance, and we can add a rewrite rule to turn
>
>     munzip (fmap f xs)
>
> into
>
>     Data.Sequence.Internal.unzipWith f xs
>
> On the other hand, MonadZip isn't a terribly well-known class, and
> unzipWith has always struck me as an obvious analogue of zipWith.
>
> On Jan 11, 2018 10:32 PM, "Ivan Lazar Miljenovic" <
> ivan.miljenovic at gmail.com> wrote:
>
>> On 12 January 2018 at 13:28, David Feuer <david.feuer at gmail.com> wrote:
>> > Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function to
>> > Data.Sequence. I agree. I propose adding
>> >
>> >   unzip :: Seq (a,b) -> (Seq a, Seq b)
>> >
>> >   unzipWith :: (x -> (a, b)) -> Seq x -> (Seq a, Seq b)
>> >
>> > Does anyone object?
>>
>> I see no problem with this.  Though I think it's worth pointing out
>> that Data.List doesn't have unzipWith (though unzipWith f = unzip .
>> map f).
>>
>> --
>> 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/20180111/ca843c1c/attachment.html>

From tmorris at tmorris.net  Fri Jan 12 07:07:50 2018
From: tmorris at tmorris.net (Tony Morris)
Date: Fri, 12 Jan 2018 17:07:50 +1000
Subject: Proposal: add unzips for Data.Sequence
In-Reply-To: <CAMgWh9vE54HxJAGeeKXBpHq8SmHnq0bbQnQZk748BCt02TTTrw@mail.gmail.com>
References: <CAMgWh9ua+BEsxvrMCQnvxuj9cmxCFyzFgtN4wOujGX1Bb0ZTmg@mail.gmail.com>
 <CAMgWh9sL7e9kRb_SGZNyrL0ZHQV=EZP+=KOfSjq2Xj91psVACQ@mail.gmail.com>
 <CAMgWh9vE54HxJAGeeKXBpHq8SmHnq0bbQnQZk748BCt02TTTrw@mail.gmail.com>
Message-ID: <CAJf6Usiuw3ZJk5RxyXFA=aOHf=QFr8JuoHnsyW7_62wm6OOGPQ@mail.gmail.com>

This idea has been around a while:

https://hackage.haskell.org/package/category-extras-0.52.1/docs/Control-Functor-Zip.html

Here is an article:

http://comonad.com/reader/2008/zipping-and-unzipping-functors/

Note that all functors give unzip:

\x -> (fmap fst x, fmap snd x)


On Fri, Jan 12, 2018 at 1:28 PM, David Feuer <david.feuer at gmail.com> wrote:

> Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function to
> Data.Sequence. I agree. I propose adding
>
>   unzip :: Seq (a,b) -> (Seq a, Seq b)
>
>   unzipWith :: (x -> (a, b)) -> Seq x -> (Seq a, Seq b)
>
> Does anyone object?
>
> _______________________________________________
> 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/20180112/a9fe0d82/attachment-0001.html>

From david.feuer at gmail.com  Fri Jan 12 07:31:29 2018
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 12 Jan 2018 02:31:29 -0500
Subject: Proposal: add unzips for Data.Sequence
In-Reply-To: <CAJf6Usiuw3ZJk5RxyXFA=aOHf=QFr8JuoHnsyW7_62wm6OOGPQ@mail.gmail.com>
References: <CAMgWh9ua+BEsxvrMCQnvxuj9cmxCFyzFgtN4wOujGX1Bb0ZTmg@mail.gmail.com>
 <CAMgWh9sL7e9kRb_SGZNyrL0ZHQV=EZP+=KOfSjq2Xj91psVACQ@mail.gmail.com>
 <CAMgWh9vE54HxJAGeeKXBpHq8SmHnq0bbQnQZk748BCt02TTTrw@mail.gmail.com>
 <CAJf6Usiuw3ZJk5RxyXFA=aOHf=QFr8JuoHnsyW7_62wm6OOGPQ@mail.gmail.com>
Message-ID: <CAMgWh9va4siMYLOMEs1dnTj11CNE6BGc2-idJG4shJc71y1QbQ@mail.gmail.com>

The semantics that seem most natural from an implementation standpoint are

unzip xs = xs `seq` (fmap fst xs, fmap snd xs)

Is there some reason that extra drop of strictness will be troublesome?

It is true that all functors give an unzip, but it seems valuable to
offer a custom version
anyway for situations where the universal implementation could lead to
a space leak.
For example, suppose I have a function

f :: A -> (B, C)

where B is very large and C is not. Suppose I then

let (bs, cs) = unzipWith f xs

immediately fold bs up into a small summary value, and never use bs
again. With the
universal implementation of unzip, all the B values will be kept alive
by cs. With the
hand-written implementation, assuming the GC hack works out [*], we
should be able
to free the Bs promptly. Of course, nothing is free, so we'll build up
some structure for
cs even if we never use it. I think it makes sense to offer users the choice.

[*] http://homepages.inf.ed.ac.uk/wadler/papers/leak/

On Fri, Jan 12, 2018 at 2:07 AM, Tony Morris <tmorris at tmorris.net> wrote:
> This idea has been around a while:
>
> https://hackage.haskell.org/package/category-extras-0.52.1/docs/Control-Functor-Zip.html
>
> Here is an article:
>
> http://comonad.com/reader/2008/zipping-and-unzipping-functors/
>
> Note that all functors give unzip:
>
> \x -> (fmap fst x, fmap snd x)
>
>
> On Fri, Jan 12, 2018 at 1:28 PM, David Feuer <david.feuer at gmail.com> wrote:
>>
>> Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function to
>> Data.Sequence. I agree. I propose adding
>>
>>   unzip :: Seq (a,b) -> (Seq a, Seq b)
>>
>>   unzipWith :: (x -> (a, b)) -> Seq x -> (Seq a, Seq b)
>>
>> Does anyone object?
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>

From ryan.reich at gmail.com  Fri Jan 12 07:36:08 2018
From: ryan.reich at gmail.com (Ryan Reich)
Date: Thu, 11 Jan 2018 23:36:08 -0800
Subject: Proposal: add unzips for Data.Sequence
In-Reply-To: <CAJN5CVLDvN8sbykhPQrFd0_tSiUfVgMixRy9UnaxH7Vhdsm_Rw@mail.gmail.com>
References: <CAMgWh9ua+BEsxvrMCQnvxuj9cmxCFyzFgtN4wOujGX1Bb0ZTmg@mail.gmail.com>
 <CAMgWh9sL7e9kRb_SGZNyrL0ZHQV=EZP+=KOfSjq2Xj91psVACQ@mail.gmail.com>
 <CAMgWh9vE54HxJAGeeKXBpHq8SmHnq0bbQnQZk748BCt02TTTrw@mail.gmail.com>
 <CA+u6gbxsTEXfG4CwhafTsAnjR2z6wze3UfqW=R8JMdgadwS8qQ@mail.gmail.com>
 <CAMgWh9vzSpbAqNZwnc1ZK7dPOrVRsEqvw-V1QiFHrk78MNbMgA@mail.gmail.com>
 <CAJN5CVLDvN8sbykhPQrFd0_tSiUfVgMixRy9UnaxH7Vhdsm_Rw@mail.gmail.com>
Message-ID: <CAO8OcksHgLhNiSCsPP65JQp67HE5K=ndSny2wLUYiAuMJKMGTQ@mail.gmail.com>

I have found from time to time, when using Data.Sequence, that a list-like
function that I expect to be there is in fact not present and its absence
is not mentioned; it always turns out to be implicit in one of Sequence's
instances.  Examples: map, fold, (++).  This is in principle no different,
except that MonadZip is apparently relatively obscure and, possibly, not
the "right" class according to Tony Morris' link.

I can't tell if this is an argument for or against the proposal, but it
does seem to reflect a choice to populate the Sequence API via
instantiating standard classes rather than writing standalone functions
(with possibly conflicting names, not that this is a new thing with these
container libraries).  Both map and fold have Seq-specific indexed variants
that are *not* part of those classes, and if neatness is what the module
authors were going for, then this kind of variation is the only thing that
should actually appear in Data.Sequence itself.  It does impact the
usefulness of the documentation, though.  I think that's the real issue
here.

On Thu, Jan 11, 2018 at 10:47 PM, Tikhon Jelvis <tikhon at jelv.is> wrote:

> I did not know about MonadZip and wouldn't have thought to look for it.
>
> On the other hand, unzip and unzipWith are immediately intuitive.
>
> I think they'd be a solid addition.
>
> On Thu, Jan 11, 2018 at 8:54 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
>> We don't strictly *need* to add either of these functions. Users can use
>> munzip from the MonadZip instance, and we can add a rewrite rule to turn
>>
>>     munzip (fmap f xs)
>>
>> into
>>
>>     Data.Sequence.Internal.unzipWith f xs
>>
>> On the other hand, MonadZip isn't a terribly well-known class, and
>> unzipWith has always struck me as an obvious analogue of zipWith.
>>
>> On Jan 11, 2018 10:32 PM, "Ivan Lazar Miljenovic" <
>> ivan.miljenovic at gmail.com> wrote:
>>
>>> On 12 January 2018 at 13:28, David Feuer <david.feuer at gmail.com> wrote:
>>> > Paolo G. Giarrusso (Blaisorblade) would like to add an unzip function
>>> to
>>> > Data.Sequence. I agree. I propose adding
>>> >
>>> >   unzip :: Seq (a,b) -> (Seq a, Seq b)
>>> >
>>> >   unzipWith :: (x -> (a, b)) -> Seq x -> (Seq a, Seq b)
>>> >
>>> > Does anyone object?
>>>
>>> I see no problem with this.  Though I think it's worth pointing out
>>> that Data.List doesn't have unzipWith (though unzipWith f = unzip .
>>> map f).
>>>
>>> --
>>> 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
>>
>>
>
> _______________________________________________
> 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/20180111/12bc722f/attachment.html>

From 78emil at gmail.com  Fri Jan 12 10:47:30 2018
From: 78emil at gmail.com (Emil Axelsson)
Date: Fri, 12 Jan 2018 10:47:30 +0000
Subject: Proposal: Lifting to TExpQ
Message-ID: <3c14d2ba-9b97-33c1-401d-01d8aee145da@gmail.com>

Hi!

I wasn't able to find a function like this anywhere:

   liftT :: Lift a => a -> TExpQ a
   liftT = unsafeTExpCoerce . lift

It seems like a nice addition that would reduce the need for 
`unsafeTExpCoerce` in user code.

Should it be added?

/ Emil

From simonpj at microsoft.com  Fri Jan 12 13:17:31 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 12 Jan 2018 13:17:31 +0000
Subject: Proposal: Lifting to TExpQ
In-Reply-To: <3c14d2ba-9b97-33c1-401d-01d8aee145da@gmail.com>
References: <3c14d2ba-9b97-33c1-401d-01d8aee145da@gmail.com>
Message-ID: <VI1PR83MB0205ECF08AB74095661CE670AD170@VI1PR83MB0205.EURPRD83.prod.outlook.com>

Indeed.  Moreover there is nothing unsafe about this, so I'd like to see this done without using unsafe-anything.

To do this, the Lift class would need to change, from

	class Lift t where
	  lift :: t -> Q Exp

to

	class Lift t where
	  lift :: t -> Q (TExp t)

This would take a bit of work, but it looks to me as if it would be a Good Thing.
Maybe someone could write up a design?   

Simon

|  -----Original Message-----
|  From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of
|  Emil Axelsson
|  Sent: 12 January 2018 10:48
|  To: Haskell Libraries <libraries at haskell.org>
|  Subject: Proposal: Lifting to TExpQ
|  
|  Hi!
|  
|  I wasn't able to find a function like this anywhere:
|  
|     liftT :: Lift a => a -> TExpQ a
|     liftT = unsafeTExpCoerce . lift
|  
|  It seems like a nice addition that would reduce the need for
|  `unsafeTExpCoerce` in user code.
|  
|  Should it be added?
|  
|  / Emil
|  _______________________________________________
|  Libraries mailing list
|  Libraries at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-
|  bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsof
|  t.com%7C3f68f4551f724d2d8cfa08d559a9f13b%7C72f988bf86f141af91ab2d7cd01
|  1db47%7C1%7C0%7C636513508787847030&sdata=FUvPD77GrLn%2Bkc3ZUwfinQacU8p
|  s00oXFvfI6VhoD1Q%3D&reserved=0

From 78emil at gmail.com  Sat Jan 13 22:42:04 2018
From: 78emil at gmail.com (Emil Axelsson)
Date: Sat, 13 Jan 2018 22:42:04 +0000
Subject: Proposal: Lifting to TExpQ
In-Reply-To: <VI1PR83MB0205ECF08AB74095661CE670AD170@VI1PR83MB0205.EURPRD83.prod.outlook.com>
References: <3c14d2ba-9b97-33c1-401d-01d8aee145da@gmail.com>
 <VI1PR83MB0205ECF08AB74095661CE670AD170@VI1PR83MB0205.EURPRD83.prod.outlook.com>
Message-ID: <d516534c-c064-7011-dbd5-fb20efd567c4@gmail.com>

Ah, yes. That's more than I could take on now, but sounds like the right 
way to do lifting.

/ Emil

Den 2018-01-12 kl. 13:17, skrev Simon Peyton Jones:
> Indeed.  Moreover there is nothing unsafe about this, so I'd like to see this done without using unsafe-anything.
> 
> To do this, the Lift class would need to change, from
> 
> 	class Lift t where
> 	  lift :: t -> Q Exp
> 
> to
> 
> 	class Lift t where
> 	  lift :: t -> Q (TExp t)
> 
> This would take a bit of work, but it looks to me as if it would be a Good Thing.
> Maybe someone could write up a design?
> 
> Simon
> 
> |  -----Original Message-----
> |  From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of
> |  Emil Axelsson
> |  Sent: 12 January 2018 10:48
> |  To: Haskell Libraries <libraries at haskell.org>
> |  Subject: Proposal: Lifting to TExpQ
> |
> |  Hi!
> |
> |  I wasn't able to find a function like this anywhere:
> |
> |     liftT :: Lift a => a -> TExpQ a
> |     liftT = unsafeTExpCoerce . lift
> |
> |  It seems like a nice addition that would reduce the need for
> |  `unsafeTExpCoerce` in user code.
> |
> |  Should it be added?
> |
> |  / Emil
> |  _______________________________________________
> |  Libraries mailing list
> |  Libraries at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
> |  askell.org%2Fcgi-
> |  bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsof
> |  t.com%7C3f68f4551f724d2d8cfa08d559a9f13b%7C72f988bf86f141af91ab2d7cd01
> |  1db47%7C1%7C0%7C636513508787847030&sdata=FUvPD77GrLn%2Bkc3ZUwfinQacU8p
> |  s00oXFvfI6VhoD1Q%3D&reserved=0
> 

From mgsloan at gmail.com  Sat Jan 13 23:02:38 2018
From: mgsloan at gmail.com (Michael Sloan)
Date: Sat, 13 Jan 2018 15:02:38 -0800
Subject: Proposal: Lifting to TExpQ
In-Reply-To: <VI1PR83MB0205ECF08AB74095661CE670AD170@VI1PR83MB0205.EURPRD83.prod.outlook.com>
References: <3c14d2ba-9b97-33c1-401d-01d8aee145da@gmail.com>
 <VI1PR83MB0205ECF08AB74095661CE670AD170@VI1PR83MB0205.EURPRD83.prod.outlook.com>
Message-ID: <CAEDDsWf0G+ApdZ6fTAHGQx1bLS-cPeNnNSc01i16WCVCZgRxyA@mail.gmail.com>

Hmm, I'm not sure about changing the Lift class, there are good
reasons to leave it the same and good reasons to change as well.
There is a lot of precedent for providing safe functions which use
unsafe functions (e.g. unsafeDupablePerformIO in bytestring / text).
Also, not much of the TH API uses TExp, just typed splices.  On the
other hand, it does make the method's type stronger and directly
suggest more properties.  It may encourage people to use typed splices
to define manual instances, which I think is good.

I propose a somewhat less breaking change, defining the following:

    class Lift t where
      typedLift :: t -> Q (TExp t)

    lift :: Lift t => t -> Q t
    lift = fmap unType . typedLift

The advantage of this is that a lot more code depends on usage of
'lift' than defining instances of 'Lift'.  A lot of the code that
defines instances of 'Lift' does it via the 'th-lift' package.  I
believe that only a handful of packages would need to be updated as a
result of this change, vs the dozens that would need to be updated by
changing the type of 'lift'.

Even after this change, I think that since 'TExp' is only useful with
typed splices, the 'lift' form would still find much more usage as the
more convenient function.

-Michael

From danburton.email at gmail.com  Sun Jan 14 20:05:58 2018
From: danburton.email at gmail.com (Dan Burton)
Date: Sun, 14 Jan 2018 12:05:58 -0800
Subject: Proposal: Lifting to TExpQ
In-Reply-To: <CALSygweRJXrU4coOUsEFrQ1uUwLeNTykLrKNndepNwtnCSDhwQ@mail.gmail.com>
References: <3c14d2ba-9b97-33c1-401d-01d8aee145da@gmail.com>
 <VI1PR83MB0205ECF08AB74095661CE670AD170@VI1PR83MB0205.EURPRD83.prod.outlook.com>
 <CAEDDsWf0G+ApdZ6fTAHGQx1bLS-cPeNnNSc01i16WCVCZgRxyA@mail.gmail.com>
 <CALSygweRJXrU4coOUsEFrQ1uUwLeNTykLrKNndepNwtnCSDhwQ@mail.gmail.com>
Message-ID: <CALSygweh9NPyA=0aeV5w=BPgW6x-wew2R5As_NCN0hhgz4SOiw@mail.gmail.com>

+1 to Michael's suggestion; that's basically the same thing I would have
suggested, modulo bikeshedding.

On Jan 13, 2018 15:03, "Michael Sloan" <mgsloan at gmail.com> wrote:

Hmm, I'm not sure about changing the Lift class, there are good
reasons to leave it the same and good reasons to change as well.
There is a lot of precedent for providing safe functions which use
unsafe functions (e.g. unsafeDupablePerformIO in bytestring / text).
Also, not much of the TH API uses TExp, just typed splices.  On the
other hand, it does make the method's type stronger and directly
suggest more properties.  It may encourage people to use typed splices
to define manual instances, which I think is good.

I propose a somewhat less breaking change, defining the following:

    class Lift t where
      typedLift :: t -> Q (TExp t)

    lift :: Lift t => t -> Q t
    lift = fmap unType . typedLift

The advantage of this is that a lot more code depends on usage of
'lift' than defining instances of 'Lift'.  A lot of the code that
defines instances of 'Lift' does it via the 'th-lift' package.  I
believe that only a handful of packages would need to be updated as a
result of this change, vs the dozens that would need to be updated by
changing the type of 'lift'.

Even after this change, I think that since 'TExp' is only useful with
typed splices, the 'lift' form would still find much more usage as the
more convenient function.

-Michael
_______________________________________________
Libraries mailing list
Libraries at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180114/d28fb40c/attachment.html>

From mgsloan at gmail.com  Sun Jan 14 22:13:57 2018
From: mgsloan at gmail.com (Michael Sloan)
Date: Sun, 14 Jan 2018 14:13:57 -0800
Subject: Proposal: Lifting to TExpQ
In-Reply-To: <CALSygweh9NPyA=0aeV5w=BPgW6x-wew2R5As_NCN0hhgz4SOiw@mail.gmail.com>
References: <3c14d2ba-9b97-33c1-401d-01d8aee145da@gmail.com>
 <VI1PR83MB0205ECF08AB74095661CE670AD170@VI1PR83MB0205.EURPRD83.prod.outlook.com>
 <CAEDDsWf0G+ApdZ6fTAHGQx1bLS-cPeNnNSc01i16WCVCZgRxyA@mail.gmail.com>
 <CALSygweRJXrU4coOUsEFrQ1uUwLeNTykLrKNndepNwtnCSDhwQ@mail.gmail.com>
 <CALSygweh9NPyA=0aeV5w=BPgW6x-wew2R5As_NCN0hhgz4SOiw@mail.gmail.com>
Message-ID: <CAEDDsWevH=2oQmQy39shhHz_5WOu1=NiDWp2wr20zJMd4B4rxA@mail.gmail.com>

Cool!  Yeah, the name bikeshedding on typedLift vs liftT is that
"lift" is already too transformer-ey for my taste, and liftT makes it
even moreso.

Also, I realized I mistyped the type of 'lift', it should be 'Lift t
=> t -> Q Exp'.

-Michael

On Sun, Jan 14, 2018 at 12:05 PM, Dan Burton <danburton.email at gmail.com> wrote:
> +1 to Michael's suggestion; that's basically the same thing I would have
> suggested, modulo bikeshedding.
>
> On Jan 13, 2018 15:03, "Michael Sloan" <mgsloan at gmail.com> wrote:
>
> Hmm, I'm not sure about changing the Lift class, there are good
> reasons to leave it the same and good reasons to change as well.
> There is a lot of precedent for providing safe functions which use
> unsafe functions (e.g. unsafeDupablePerformIO in bytestring / text).
> Also, not much of the TH API uses TExp, just typed splices.  On the
> other hand, it does make the method's type stronger and directly
> suggest more properties.  It may encourage people to use typed splices
> to define manual instances, which I think is good.
>
> I propose a somewhat less breaking change, defining the following:
>
>     class Lift t where
>       typedLift :: t -> Q (TExp t)
>
>     lift :: Lift t => t -> Q t
>     lift = fmap unType . typedLift
>
> The advantage of this is that a lot more code depends on usage of
> 'lift' than defining instances of 'Lift'.  A lot of the code that
> defines instances of 'Lift' does it via the 'th-lift' package.  I
> believe that only a handful of packages would need to be updated as a
> result of this change, vs the dozens that would need to be updated by
> changing the type of 'lift'.
>
> Even after this change, I think that since 'TExp' is only useful with
> typed splices, the 'lift' form would still find much more usage as the
> more convenient function.
>
> -Michael
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>

From simonpj at microsoft.com  Mon Jan 15 09:00:22 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 15 Jan 2018 09:00:22 +0000
Subject: Proposal: Lifting to TExpQ
In-Reply-To: <CAEDDsWevH=2oQmQy39shhHz_5WOu1=NiDWp2wr20zJMd4B4rxA@mail.gmail.com>
References: <3c14d2ba-9b97-33c1-401d-01d8aee145da@gmail.com>
 <VI1PR83MB0205ECF08AB74095661CE670AD170@VI1PR83MB0205.EURPRD83.prod.outlook.com>
 <CAEDDsWf0G+ApdZ6fTAHGQx1bLS-cPeNnNSc01i16WCVCZgRxyA@mail.gmail.com>
 <CALSygweRJXrU4coOUsEFrQ1uUwLeNTykLrKNndepNwtnCSDhwQ@mail.gmail.com>
 <CALSygweh9NPyA=0aeV5w=BPgW6x-wew2R5As_NCN0hhgz4SOiw@mail.gmail.com>
 <CAEDDsWevH=2oQmQy39shhHz_5WOu1=NiDWp2wr20zJMd4B4rxA@mail.gmail.com>
Message-ID: <VI1PR83MB02059F553457A0E40AC641BFADEB0@VI1PR83MB0205.EURPRD83.prod.outlook.com>

I agree too. I've created
https://ghc.haskell.org/trac/ghc/ticket/14671

Now all we need is someone to execute on it.

Simon

|  -----Original Message-----
|  From: Michael Sloan [mailto:mgsloan at gmail.com]
|  Sent: 14 January 2018 22:14
|  To: Dan Burton <danburton.email at gmail.com>
|  Cc: Simon Peyton Jones <simonpj at microsoft.com>; Haskell Libraries
|  <libraries at haskell.org>
|  Subject: Re: Proposal: Lifting to TExpQ
|  
|  Cool!  Yeah, the name bikeshedding on typedLift vs liftT is that
|  "lift" is already too transformer-ey for my taste, and liftT makes it
|  even moreso.
|  
|  Also, I realized I mistyped the type of 'lift', it should be 'Lift t
|  => t -> Q Exp'.
|  
|  -Michael
|  
|  On Sun, Jan 14, 2018 at 12:05 PM, Dan Burton
|  <danburton.email at gmail.com> wrote:
|  > +1 to Michael's suggestion; that's basically the same thing I would
|  > +have
|  > suggested, modulo bikeshedding.
|  >
|  > On Jan 13, 2018 15:03, "Michael Sloan" <mgsloan at gmail.com> wrote:
|  >
|  > Hmm, I'm not sure about changing the Lift class, there are good
|  > reasons to leave it the same and good reasons to change as well.
|  > There is a lot of precedent for providing safe functions which use
|  > unsafe functions (e.g. unsafeDupablePerformIO in bytestring / text).
|  > Also, not much of the TH API uses TExp, just typed splices.  On the
|  > other hand, it does make the method's type stronger and directly
|  > suggest more properties.  It may encourage people to use typed
|  splices
|  > to define manual instances, which I think is good.
|  >
|  > I propose a somewhat less breaking change, defining the following:
|  >
|  >     class Lift t where
|  >       typedLift :: t -> Q (TExp t)
|  >
|  >     lift :: Lift t => t -> Q t
|  >     lift = fmap unType . typedLift
|  >
|  > The advantage of this is that a lot more code depends on usage of
|  > 'lift' than defining instances of 'Lift'.  A lot of the code that
|  > defines instances of 'Lift' does it via the 'th-lift' package.  I
|  > believe that only a handful of packages would need to be updated as
|  a
|  > result of this change, vs the dozens that would need to be updated
|  by
|  > changing the type of 'lift'.
|  >
|  > Even after this change, I think that since 'TExp' is only useful
|  with
|  > typed splices, the 'lift' form would still find much more usage as
|  the
|  > more convenient function.
|  >
|  > -Michael
|  > _______________________________________________
|  > Libraries mailing list
|  > Libraries at haskell.org
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  > askell.org%2Fcgi-
|  bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Cs
|  >
|  imonpj%40microsoft.com%7C1a64d01a0c6141a3e75808d55b9c27dc%7C72f988bf86
|  >
|  f141af91ab2d7cd011db47%7C1%7C0%7C636515648605968445&sdata=%2FsPADsgmpl
|  > J2zKS3q8oPC4HUwrU7P3VQrutIODMIjsY%3D&reserved=0
|  >
|  >

From simonpj at microsoft.com  Mon Jan 15 09:00:22 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 15 Jan 2018 09:00:22 +0000
Subject: Proposal: Lifting to TExpQ
In-Reply-To: <CAEDDsWevH=2oQmQy39shhHz_5WOu1=NiDWp2wr20zJMd4B4rxA@mail.gmail.com>
References: <3c14d2ba-9b97-33c1-401d-01d8aee145da@gmail.com>
 <VI1PR83MB0205ECF08AB74095661CE670AD170@VI1PR83MB0205.EURPRD83.prod.outlook.com>
 <CAEDDsWf0G+ApdZ6fTAHGQx1bLS-cPeNnNSc01i16WCVCZgRxyA@mail.gmail.com>
 <CALSygweRJXrU4coOUsEFrQ1uUwLeNTykLrKNndepNwtnCSDhwQ@mail.gmail.com>
 <CALSygweh9NPyA=0aeV5w=BPgW6x-wew2R5As_NCN0hhgz4SOiw@mail.gmail.com>
 <CAEDDsWevH=2oQmQy39shhHz_5WOu1=NiDWp2wr20zJMd4B4rxA@mail.gmail.com>
Message-ID: <VI1PR83MB02059F553457A0E40AC641BFADEB0@VI1PR83MB0205.EURPRD83.prod.outlook.com>

I agree too. I've created
https://ghc.haskell.org/trac/ghc/ticket/14671

Now all we need is someone to execute on it.

Simon

|  -----Original Message-----
|  From: Michael Sloan [mailto:mgsloan at gmail.com]
|  Sent: 14 January 2018 22:14
|  To: Dan Burton <danburton.email at gmail.com>
|  Cc: Simon Peyton Jones <simonpj at microsoft.com>; Haskell Libraries
|  <libraries at haskell.org>
|  Subject: Re: Proposal: Lifting to TExpQ
|  
|  Cool!  Yeah, the name bikeshedding on typedLift vs liftT is that
|  "lift" is already too transformer-ey for my taste, and liftT makes it
|  even moreso.
|  
|  Also, I realized I mistyped the type of 'lift', it should be 'Lift t
|  => t -> Q Exp'.
|  
|  -Michael
|  
|  On Sun, Jan 14, 2018 at 12:05 PM, Dan Burton
|  <danburton.email at gmail.com> wrote:
|  > +1 to Michael's suggestion; that's basically the same thing I would
|  > +have
|  > suggested, modulo bikeshedding.
|  >
|  > On Jan 13, 2018 15:03, "Michael Sloan" <mgsloan at gmail.com> wrote:
|  >
|  > Hmm, I'm not sure about changing the Lift class, there are good
|  > reasons to leave it the same and good reasons to change as well.
|  > There is a lot of precedent for providing safe functions which use
|  > unsafe functions (e.g. unsafeDupablePerformIO in bytestring / text).
|  > Also, not much of the TH API uses TExp, just typed splices.  On the
|  > other hand, it does make the method's type stronger and directly
|  > suggest more properties.  It may encourage people to use typed
|  splices
|  > to define manual instances, which I think is good.
|  >
|  > I propose a somewhat less breaking change, defining the following:
|  >
|  >     class Lift t where
|  >       typedLift :: t -> Q (TExp t)
|  >
|  >     lift :: Lift t => t -> Q t
|  >     lift = fmap unType . typedLift
|  >
|  > The advantage of this is that a lot more code depends on usage of
|  > 'lift' than defining instances of 'Lift'.  A lot of the code that
|  > defines instances of 'Lift' does it via the 'th-lift' package.  I
|  > believe that only a handful of packages would need to be updated as
|  a
|  > result of this change, vs the dozens that would need to be updated
|  by
|  > changing the type of 'lift'.
|  >
|  > Even after this change, I think that since 'TExp' is only useful
|  with
|  > typed splices, the 'lift' form would still find much more usage as
|  the
|  > more convenient function.
|  >
|  > -Michael
|  > _______________________________________________
|  > Libraries mailing list
|  > Libraries at haskell.org
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  > askell.org%2Fcgi-
|  bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Cs
|  >
|  imonpj%40microsoft.com%7C1a64d01a0c6141a3e75808d55b9c27dc%7C72f988bf86
|  >
|  f141af91ab2d7cd011db47%7C1%7C0%7C636515648605968445&sdata=%2FsPADsgmpl
|  > J2zKS3q8oPC4HUwrU7P3VQrutIODMIjsY%3D&reserved=0
|  >
|  >

From adam at bergmark.nl  Tue Jan 16 10:47:30 2018
From: adam at bergmark.nl (Adam Bergmark)
Date: Tue, 16 Jan 2018 10:47:30 +0000
Subject: Taking over maintainership of cabal2spec
In-Reply-To: <87inc8fo0u.fsf@write-only.cryp.to>
References: <87inc8fo0u.fsf@write-only.cryp.to>
Message-ID: <CACnqJZYfqK=9fFK+-FhDXNWYHKs_9Y_hyi=p4DmhR+-BuObLUA@mail.gmail.com>

cc'ing the cabal2spec maintainer

On Thu, 11 Jan 2018 at 15:57 Peter Simons <simons at nospf.cryp.to> wrote:

> Fellow Haskell Hackers,
>
> I would like to take over the package cabal2spec [1], which hasn't seen
> any activity in the last 9 years. I have tried to contact the Hackage
> maintainers Conrad Meyer and Yaakov M. Nemoy to get them involved in the
> decision, but unfortunately I was unable to reach either one of them.
>
> Best regards,
> Peter
>
>
>
> [1] http://hackage.haskell.org/package/cabal2spec
>
> _______________________________________________
> 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/20180116/12a55b8e/attachment.html>

From adam at bergmark.nl  Tue Jan 16 10:48:56 2018
From: adam at bergmark.nl (Adam Bergmark)
Date: Tue, 16 Jan 2018 10:48:56 +0000
Subject: Taking over maintainership of cabal2spec
In-Reply-To: <CACnqJZYfqK=9fFK+-FhDXNWYHKs_9Y_hyi=p4DmhR+-BuObLUA@mail.gmail.com>
References: <87inc8fo0u.fsf@write-only.cryp.to>
 <CACnqJZYfqK=9fFK+-FhDXNWYHKs_9Y_hyi=p4DmhR+-BuObLUA@mail.gmail.com>
Message-ID: <CACnqJZZOxGS5yeFpRY5xAAVTf-aa0G3krMShf9Vyr8SDjLZVxg@mail.gmail.com>

His e-mail is defunct...

On Tue, 16 Jan 2018 at 11:47 Adam Bergmark <adam at bergmark.nl> wrote:

> cc'ing the cabal2spec maintainer
>
>
> On Thu, 11 Jan 2018 at 15:57 Peter Simons <simons at nospf.cryp.to> wrote:
>
>> Fellow Haskell Hackers,
>>
>> I would like to take over the package cabal2spec [1], which hasn't seen
>> any activity in the last 9 years. I have tried to contact the Hackage
>> maintainers Conrad Meyer and Yaakov M. Nemoy to get them involved in the
>> decision, but unfortunately I was unable to reach either one of them.
>>
>> Best regards,
>> Peter
>>
>>
>>
>> [1] http://hackage.haskell.org/package/cabal2spec
>>
>> _______________________________________________
>> 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/20180116/df054ef2/attachment.html>

From ivan.miljenovic at gmail.com  Tue Jan 16 23:34:21 2018
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Wed, 17 Jan 2018 10:34:21 +1100
Subject: ANNOUNCE: servant-pandoc 0.5.0.0
Message-ID: <CA+u6gbyE=zoakgN-da9ftb7a1tAt8Spt=HjBqRLcmjk0fJSa2w@mail.gmail.com>

I'm pleased to announce the latest release of the servant-pandoc
library: https://hackage.haskell.org/package/servant-pandoc-0.5.0.0

servant-pandoc allows you to take the documentation created with
servant-docs and use Pandoc to convert it into whichever format you
want (rather than the Markdown generated by servant-docs).

The main changes in this release are to provide compatibility with
servant-docs-0.11.1; specifically, servant-pandoc now emits all the
information that servant-docs does with the same configuration
options.  As such, there are behavioural changes which necessitated
the major version bump.

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

From andrew.thaddeus at gmail.com  Wed Jan 17 23:46:30 2018
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Wed, 17 Jan 2018 18:46:30 -0500
Subject: Name of 1-Tuple Data Type
Message-ID: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>

Required background information:
https://ghc.haskell.org/trac/ghc/ticket/14673

GHC has a one-tuple (both a boxed variant and an unboxed variant). The
unboxed variant currently must be fully applied whenever it is used. This
is in stark contrast to all the other n-tuples (n > 1). It stems entirely
from an issue of syntax. The solution decided on is to provide a normal
prefix name for the 1-tuple. The name that GHC uses internally for this
type is `Unit#` (there is also a boxed variant Unit). However, in the
haskell community, the word "unit" already refers to the nullary tuple, not
the unary tuple. So, we're bikeshedding the name.

Here are some possible options:

* Unary (as in unary tuple)
* Single (as in single, double, triple)
* Singleton (as is singleton, doubleton, tripleton)
* Only (
https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html)
* OneTuple (
https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html
)
* Uni (means "one" in latin or greek or something like that)
* Mono (means "one" in latin or greek or something like that)

I would appreciate any feedback on the suggestions I provided or any
additional suggestions for the name. If you have concerns about the feature
itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
focused on just the problem of coming up with a name.

-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180117/7b37f15a/attachment.html>

From david.feuer at gmail.com  Thu Jan 18 00:15:45 2018
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 17 Jan 2018 19:15:45 -0500
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
Message-ID: <CAMgWh9ua5tXtbXb0naYnW4x_X2z9x-H04U2PFkO-8dAGQjT-uw@mail.gmail.com>

At present, Unit# is the only way to turn a lifted type into an unlifted
one. Perhaps
Unlift# or Lower# would make sense? The tricky bit is that one could easily
imagine eventually having a version with a strict constructor, in which
case it becomes a bit hard to guess which is which.

On Wed, Jan 17, 2018 at 6:46 PM, Andrew Martin <andrew.thaddeus at gmail.com>
wrote:
> Required background information:
> https://ghc.haskell.org/trac/ghc/ticket/14673
>
> GHC has a one-tuple (both a boxed variant and an unboxed variant). The
> unboxed variant currently must be fully applied whenever it is used. This
is
> in stark contrast to all the other n-tuples (n > 1). It stems entirely
from
> an issue of syntax. The solution decided on is to provide a normal prefix
> name for the 1-tuple. The name that GHC uses internally for this type is
> `Unit#` (there is also a boxed variant Unit). However, in the haskell
> community, the word "unit" already refers to the nullary tuple, not the
> unary tuple. So, we're bikeshedding the name.
>
> Here are some possible options:
>
> * Unary (as in unary tuple)
> * Single (as in single, double, triple)
> * Singleton (as is singleton, doubleton, tripleton)
> * Only
> (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html)
> * OneTuple
> (
https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html
)
> * Uni (means "one" in latin or greek or something like that)
> * Mono (means "one" in latin or greek or something like that)
>
> I would appreciate any feedback on the suggestions I provided or any
> additional suggestions for the name. If you have concerns about the
feature
> itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
> focused on just the problem of coming up with a name.
>
> --
> -Andrew Thaddeus Martin
>
> _______________________________________________
> 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/20180117/acb149ab/attachment.html>

From m.farkasdyck at gmail.com  Thu Jan 18 00:27:22 2018
From: m.farkasdyck at gmail.com (M Farkas-Dyck)
Date: Wed, 17 Jan 2018 16:27:22 -0800
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
Message-ID: <CAL3m8eB4a+9HSiXzZUShUHRtQ=X3UFjQPVaFTX-m7B5Gu-=OWA@mail.gmail.com>

Identity#

From ryan.reich at gmail.com  Thu Jan 18 00:34:26 2018
From: ryan.reich at gmail.com (Ryan Reich)
Date: Wed, 17 Jan 2018 16:34:26 -0800
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
Message-ID: <CAO8Ockto1UnTd2LPdMRW5ic7H03HjX7s_ciXx69xx4X5t-E92g@mail.gmail.com>

Only has two virtues I can see easily: it's short (shorter than almost all
the others), and it has the same feel as Maybe.

There is also Id, the name of the mathematical function that this type (and
corresponding data) constructor is. Less pithy but even less intrusive.

On Jan 17, 2018 15:47, "Andrew Martin" <andrew.thaddeus at gmail.com> wrote:

Required background information: https://ghc.haskell.org/trac/ghc/ticket/
14673

GHC has a one-tuple (both a boxed variant and an unboxed variant). The
unboxed variant currently must be fully applied whenever it is used. This
is in stark contrast to all the other n-tuples (n > 1). It stems entirely
from an issue of syntax. The solution decided on is to provide a normal
prefix name for the 1-tuple. The name that GHC uses internally for this
type is `Unit#` (there is also a boxed variant Unit). However, in the
haskell community, the word "unit" already refers to the nullary tuple, not
the unary tuple. So, we're bikeshedding the name.

Here are some possible options:

* Unary (as in unary tuple)
* Single (as in single, double, triple)
* Singleton (as is singleton, doubleton, tripleton)
* Only (https://hackage.haskell.org/package/Only-0.1/docs/Data-
Tuple-Only.html)
* OneTuple (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/
Data-Tuple-OneTuple.html)
* Uni (means "one" in latin or greek or something like that)
* Mono (means "one" in latin or greek or something like that)

I would appreciate any feedback on the suggestions I provided or any
additional suggestions for the name. If you have concerns about the feature
itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
focused on just the problem of coming up with a name.

-- 
-Andrew Thaddeus Martin

_______________________________________________
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/20180117/fb03c988/attachment.html>

From tanuki at gmail.com  Thu Jan 18 02:41:55 2018
From: tanuki at gmail.com (Theodore Lief Gannon)
Date: Wed, 17 Jan 2018 18:41:55 -0800
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CAO8Ockto1UnTd2LPdMRW5ic7H03HjX7s_ciXx69xx4X5t-E92g@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <CAO8Ockto1UnTd2LPdMRW5ic7H03HjX7s_ciXx69xx4X5t-E92g@mail.gmail.com>
Message-ID: <CAJoPsuD=4CkUc1vg8NiOpAMdVMcfbDXp1V+4UErMp-0mr=d5tg@mail.gmail.com>

I've seen Only in the wild, and it's probably my favorite of the initial
suggestions for the same reasons as Ryan. Mono is my second pick from that
list.

Id is very clean, but I could see pedagogical issues arising from name
confusion. Sing(le(ton)) is a terrible idea for the same reason.

Venturing my own paint swatch: Solo fits in nicely with the established
size-specific names (pair, triple, etc.) and has all the good traits:
short, self-explanatory, nothing with a confusingly similar name (that I
know of).

On Jan 17, 2018 4:35 PM, "Ryan Reich" <ryan.reich at gmail.com> wrote:

Only has two virtues I can see easily: it's short (shorter than almost all
the others), and it has the same feel as Maybe.

There is also Id, the name of the mathematical function that this type (and
corresponding data) constructor is. Less pithy but even less intrusive.

On Jan 17, 2018 15:47, "Andrew Martin" <andrew.thaddeus at gmail.com> wrote:

Required background information: https://ghc.haske
ll.org/trac/ghc/ticket/14673

GHC has a one-tuple (both a boxed variant and an unboxed variant). The
unboxed variant currently must be fully applied whenever it is used. This
is in stark contrast to all the other n-tuples (n > 1). It stems entirely
from an issue of syntax. The solution decided on is to provide a normal
prefix name for the 1-tuple. The name that GHC uses internally for this
type is `Unit#` (there is also a boxed variant Unit). However, in the
haskell community, the word "unit" already refers to the nullary tuple, not
the unary tuple. So, we're bikeshedding the name.

Here are some possible options:

* Unary (as in unary tuple)
* Single (as in single, double, triple)
* Singleton (as is singleton, doubleton, tripleton)
* Only (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tupl
e-Only.html)
* OneTuple (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Dat
a-Tuple-OneTuple.html)
* Uni (means "one" in latin or greek or something like that)
* Mono (means "one" in latin or greek or something like that)

I would appreciate any feedback on the suggestions I provided or any
additional suggestions for the name. If you have concerns about the feature
itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
focused on just the problem of coming up with a name.

-- 
-Andrew Thaddeus Martin

_______________________________________________
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/20180117/ee24c9b4/attachment-0001.html>

From simonpj at microsoft.com  Thu Jan 18 08:17:54 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 18 Jan 2018 08:17:54 +0000
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
Message-ID: <VI1PR83MB02056AFEDFBAC89715053C66ADE80@VI1PR83MB0205.EURPRD83.prod.outlook.com>

Just to add: it would be sensible to use the same name for the data constructor as for the type constructor.  Thus, currently
            (,) ‘x’ True  ::  (,) Char Bool

So we’d expect
            Solo ‘x’  ::  Solo Char

or whatever name we choose.  Just worth bearing in mind when evaluating suggestions.

Simon

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Andrew Martin
Sent: 17 January 2018 23:47
To: Haskell Libraries <libraries at haskell.org>
Subject: Name of 1-Tuple Data Type

Required background information: https://ghc.haskell.org/trac/ghc/ticket/14673

GHC has a one-tuple (both a boxed variant and an unboxed variant). The unboxed variant currently must be fully applied whenever it is used. This is in stark contrast to all the other n-tuples (n > 1). It stems entirely from an issue of syntax. The solution decided on is to provide a normal prefix name for the 1-tuple. The name that GHC uses internally for this type is `Unit#` (there is also a boxed variant Unit). However, in the haskell community, the word "unit" already refers to the nullary tuple, not the unary tuple. So, we're bikeshedding the name.

Here are some possible options:

* Unary (as in unary tuple)
* Single (as in single, double, triple)
* Singleton (as is singleton, doubleton, tripleton)
* Only (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2FOnly-0.1%2Fdocs%2FData-Tuple-Only.html&data=02%7C01%7Csimonpj%40microsoft.com%7Ca8ed746f117d4516461308d55e049d1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518296297754534&sdata=mybVg29s2zbHvQLBgDytHhlJ2ZmdQr4blayOBW2rubI%3D&reserved=0>)
* OneTuple (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2FOneTuple-0.2.1%2Fdocs%2FData-Tuple-OneTuple.html&data=02%7C01%7Csimonpj%40microsoft.com%7Ca8ed746f117d4516461308d55e049d1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518296297754534&sdata=Pcu2ONC5rQbDpe2iPMgDYbJcoSIke%2F5pfYmSWyYhJn0%3D&reserved=0>)
* Uni (means "one" in latin or greek or something like that)
* Mono (means "one" in latin or greek or something like that)

I would appreciate any feedback on the suggestions I provided or any additional suggestions for the name. If you have concerns about the feature itself, comment on the GHC Trac ticket. I'd prefer to keep this thread focused on just the problem of coming up with a name.

--
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180118/acd3a3ed/attachment.html>

From simonpj at microsoft.com  Thu Jan 18 08:19:19 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 18 Jan 2018 08:19:19 +0000
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CAMgWh9ua5tXtbXb0naYnW4x_X2z9x-H04U2PFkO-8dAGQjT-uw@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <CAMgWh9ua5tXtbXb0naYnW4x_X2z9x-H04U2PFkO-8dAGQjT-uw@mail.gmail.com>
Message-ID: <VI1PR83MB0205CA287D524E8304B13474ADE80@VI1PR83MB0205.EURPRD83.prod.outlook.com>

At present, Unit# is the only way to turn a lifted type into an unlifted one

Actually, (# Int, Bool #) does so too. Unboxed one-tuples (currnently called Unit#) is the special case with one argument.

Simon

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of David Feuer
Sent: 18 January 2018 00:16
To: Andrew Martin <andrew.thaddeus at gmail.com>
Cc: Haskell Libraries <libraries at haskell.org>
Subject: Re: Name of 1-Tuple Data Type

At present, Unit# is the only way to turn a lifted type into an unlifted one. Perhaps
Unlift# or Lower# would make sense? The tricky bit is that one could easily imagine eventually having a version with a strict constructor, in which case it becomes a bit hard to guess which is which.

On Wed, Jan 17, 2018 at 6:46 PM, Andrew Martin <andrew.thaddeus at gmail.com<mailto:andrew.thaddeus at gmail.com>> wrote:
> Required background information:
> https://ghc.haskell.org/trac/ghc/ticket/14673
>
> GHC has a one-tuple (both a boxed variant and an unboxed variant). The
> unboxed variant currently must be fully applied whenever it is used. This is
> in stark contrast to all the other n-tuples (n > 1). It stems entirely from
> an issue of syntax. The solution decided on is to provide a normal prefix
> name for the 1-tuple. The name that GHC uses internally for this type is
> `Unit#` (there is also a boxed variant Unit). However, in the haskell
> community, the word "unit" already refers to the nullary tuple, not the
> unary tuple. So, we're bikeshedding the name.
>
> Here are some possible options:
>
> * Unary (as in unary tuple)
> * Single (as in single, double, triple)
> * Singleton (as is singleton, doubleton, tripleton)
> * Only
> (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2FOnly-0.1%2Fdocs%2FData-Tuple-Only.html&data=02%7C01%7Csimonpj%40microsoft.com%7C7d81930a5d3b407cfd7608d55e08b60f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518313867711942&sdata=qujBDi9OVAc1Vm68gI%2FK1Yv9us7xtomLwRw9UnUrefo%3D&reserved=0>)
> * OneTuple
> (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2FOneTuple-0.2.1%2Fdocs%2FData-Tuple-OneTuple.html&data=02%7C01%7Csimonpj%40microsoft.com%7C7d81930a5d3b407cfd7608d55e08b60f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518313867711942&sdata=l7aIxyiWUBdzTHKqTx3%2FkftDWFFlQ1Z4ODlVsNR5wGE%3D&reserved=0>)
> * Uni (means "one" in latin or greek or something like that)
> * Mono (means "one" in latin or greek or something like that)
>
> I would appreciate any feedback on the suggestions I provided or any
> additional suggestions for the name. If you have concerns about the feature
> itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
> focused on just the problem of coming up with a name.
>
> --
> -Andrew Thaddeus Martin
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org<mailto:Libraries at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.com%7C7d81930a5d3b407cfd7608d55e08b60f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518313867711942&sdata=tI176CxY4pnpeEMxTbGfv9vDO4%2B9VffmF0kreQuQViU%3D&reserved=0>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180118/cd192af0/attachment-0001.html>

From simonpj at microsoft.com  Thu Jan 18 08:22:29 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 18 Jan 2018 08:22:29 +0000
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CAJoPsuD=4CkUc1vg8NiOpAMdVMcfbDXp1V+4UErMp-0mr=d5tg@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <CAO8Ockto1UnTd2LPdMRW5ic7H03HjX7s_ciXx69xx4X5t-E92g@mail.gmail.com>
 <CAJoPsuD=4CkUc1vg8NiOpAMdVMcfbDXp1V+4UErMp-0mr=d5tg@mail.gmail.com>
Message-ID: <VI1PR83MB0205D2291AE8BD520B26045BADE80@VI1PR83MB0205.EURPRD83.prod.outlook.com>

I quite like Solo.

Simon

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Theodore Lief Gannon
Sent: 18 January 2018 02:42
To: Ryan Reich <ryan.reich at gmail.com>
Cc: Haskell Libraries <Libraries at haskell.org>
Subject: Re: Name of 1-Tuple Data Type

I've seen Only in the wild, and it's probably my favorite of the initial suggestions for the same reasons as Ryan. Mono is my second pick from that list.

Id is very clean, but I could see pedagogical issues arising from name confusion. Sing(le(ton)) is a terrible idea for the same reason.

Venturing my own paint swatch: Solo fits in nicely with the established size-specific names (pair, triple, etc.) and has all the good traits: short, self-explanatory, nothing with a confusingly similar name (that I know of).

On Jan 17, 2018 4:35 PM, "Ryan Reich" <ryan.reich at gmail.com<mailto:ryan.reich at gmail.com>> wrote:
Only has two virtues I can see easily: it's short (shorter than almost all the others), and it has the same feel as Maybe.

There is also Id, the name of the mathematical function that this type (and corresponding data) constructor is. Less pithy but even less intrusive.

On Jan 17, 2018 15:47, "Andrew Martin" <andrew.thaddeus at gmail.com<mailto:andrew.thaddeus at gmail.com>> wrote:
Required background information: https://ghc.haskell.org/trac/ghc/ticket/14673

GHC has a one-tuple (both a boxed variant and an unboxed variant). The unboxed variant currently must be fully applied whenever it is used. This is in stark contrast to all the other n-tuples (n > 1). It stems entirely from an issue of syntax. The solution decided on is to provide a normal prefix name for the 1-tuple. The name that GHC uses internally for this type is `Unit#` (there is also a boxed variant Unit). However, in the haskell community, the word "unit" already refers to the nullary tuple, not the unary tuple. So, we're bikeshedding the name.

Here are some possible options:

* Unary (as in unary tuple)
* Single (as in single, double, triple)
* Singleton (as is singleton, doubleton, tripleton)
* Only (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2FOnly-0.1%2Fdocs%2FData-Tuple-Only.html&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=fMbHCFU%2Br3JHwmI8a4QgHD26fhoclfklE3xA0O6tCE4%3D&reserved=0>)
* OneTuple (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2FOneTuple-0.2.1%2Fdocs%2FData-Tuple-OneTuple.html&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=rRLW8KJoKT5IQ5Y6s3kMrUOiUGk6xa77zb5VvGuAfGw%3D&reserved=0>)
* Uni (means "one" in latin or greek or something like that)
* Mono (means "one" in latin or greek or something like that)

I would appreciate any feedback on the suggestions I provided or any additional suggestions for the name. If you have concerns about the feature itself, comment on the GHC Trac ticket. I'd prefer to keep this thread focused on just the problem of coming up with a name.

--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
Libraries at haskell.org<mailto:Libraries at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=AytyB%2BhKwE1TDDc8ohTJ9gDcCZgcizoyt8Tmue0u9Zs%3D&reserved=0>


_______________________________________________
Libraries mailing list
Libraries at haskell.org<mailto:Libraries at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=AytyB%2BhKwE1TDDc8ohTJ9gDcCZgcizoyt8Tmue0u9Zs%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180118/5079e4f3/attachment-0001.html>

From abela at chalmers.se  Thu Jan 18 08:25:08 2018
From: abela at chalmers.se (Andreas Abel)
Date: Thu, 18 Jan 2018 09:25:08 +0100
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
Message-ID: <9eec1f95-c102-07f1-6bc7-035efa1507b1@chalmers.se>

-1.

Don't grap any of these nice names for that obscure feature.  Take some 
ugly name.

On 18.01.2018 00:46, Andrew Martin wrote:
> Required background information: 
> https://ghc.haskell.org/trac/ghc/ticket/14673
> 
> GHC has a one-tuple (both a boxed variant and an unboxed variant). The 
> unboxed variant currently must be fully applied whenever it is used. 
> This is in stark contrast to all the other n-tuples (n > 1). It stems 
> entirely from an issue of syntax. The solution decided on is to provide 
> a normal prefix name for the 1-tuple. The name that GHC uses internally 
> for this type is `Unit#` (there is also a boxed variant Unit). However, 
> in the haskell community, the word "unit" already refers to the nullary 
> tuple, not the unary tuple. So, we're bikeshedding the name.
> 
> Here are some possible options:
> 
> * Unary (as in unary tuple)
> * Single (as in single, double, triple)
> * Singleton (as is singleton, doubleton, tripleton)
> * Only 
> (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html)
> * OneTuple 
> (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html)
> * Uni (means "one" in latin or greek or something like that)
> * Mono (means "one" in latin or greek or something like that)
> 
> I would appreciate any feedback on the suggestions I provided or any 
> additional suggestions for the name. If you have concerns about the 
> feature itself, comment on the GHC Trac ticket. I'd prefer to keep this 
> thread focused on just the problem of coming up with a name.


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

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

andreas.abel at gu.se
http://www.cse.chalmers.se/~abela/

From abela at chalmers.se  Thu Jan 18 08:27:47 2018
From: abela at chalmers.se (Andreas Abel)
Date: Thu, 18 Jan 2018 09:27:47 +0100
Subject: Name of 1-Tuple Data Type
In-Reply-To: <VI1PR83MB0205D2291AE8BD520B26045BADE80@VI1PR83MB0205.EURPRD83.prod.outlook.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <CAO8Ockto1UnTd2LPdMRW5ic7H03HjX7s_ciXx69xx4X5t-E92g@mail.gmail.com>
 <CAJoPsuD=4CkUc1vg8NiOpAMdVMcfbDXp1V+4UErMp-0mr=d5tg@mail.gmail.com>
 <VI1PR83MB0205D2291AE8BD520B26045BADE80@VI1PR83MB0205.EURPRD83.prod.outlook.com>
Message-ID: <15873de2-e72e-8bf3-4ff8-e4b868fb8e30@chalmers.se>

I deem this feature outside of the mainstream, so it should not occupy a 
short nice name.

I suggest  UnaryTuple.

On 18.01.2018 09:22, Simon Peyton Jones via Libraries wrote:
> I quite like Solo.
> 
> Simon
> 
> *From:*Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of 
> *Theodore Lief Gannon
> *Sent:* 18 January 2018 02:42
> *To:* Ryan Reich <ryan.reich at gmail.com>
> *Cc:* Haskell Libraries <Libraries at haskell.org>
> *Subject:* Re: Name of 1-Tuple Data Type
> 
> I've seen Only in the wild, and it's probably my favorite of the initial 
> suggestions for the same reasons as Ryan. Mono is my second pick from 
> that list.
> 
> Id is very clean, but I could see pedagogical issues arising from name 
> confusion. Sing(le(ton)) is a terrible idea for the same reason.
> 
> Venturing my own paint swatch: Solo fits in nicely with the established 
> size-specific names (pair, triple, etc.) and has all the good traits: 
> short, self-explanatory, nothing with a confusingly similar name (that I 
> know of).
> 
> On Jan 17, 2018 4:35 PM, "Ryan Reich" <ryan.reich at gmail.com 
> <mailto:ryan.reich at gmail.com>> wrote:
> 
>     Only has two virtues I can see easily: it's short (shorter than
>     almost all the others), and it has the same feel as Maybe.
> 
>     There is also Id, the name of the mathematical function that this
>     type (and corresponding data) constructor is. Less pithy but even
>     less intrusive.
> 
>     On Jan 17, 2018 15:47, "Andrew Martin" <andrew.thaddeus at gmail.com
>     <mailto:andrew.thaddeus at gmail.com>> wrote:
> 
>         Required background information:
>         https://ghc.haskell.org/trac/ghc/ticket/14673
> 
>         GHC has a one-tuple (both a boxed variant and an unboxed
>         variant). The unboxed variant currently must be fully applied
>         whenever it is used. This is in stark contrast to all the other
>         n-tuples (n > 1). It stems entirely from an issue of syntax. The
>         solution decided on is to provide a normal prefix name for the
>         1-tuple. The name that GHC uses internally for this type is
>         `Unit#` (there is also a boxed variant Unit). However, in the
>         haskell community, the word "unit" already refers to the nullary
>         tuple, not the unary tuple. So, we're bikeshedding the name.
> 
>         Here are some possible options:
> 
>         * Unary (as in unary tuple)
> 
>         * Single (as in single, double, triple)
> 
>         * Singleton (as is singleton, doubleton, tripleton)
> 
>         * Only
>         (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html
>         <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2FOnly-0.1%2Fdocs%2FData-Tuple-Only.html&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=fMbHCFU%2Br3JHwmI8a4QgHD26fhoclfklE3xA0O6tCE4%3D&reserved=0>)
> 
>         * OneTuple
>         (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html
>         <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2FOneTuple-0.2.1%2Fdocs%2FData-Tuple-OneTuple.html&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=rRLW8KJoKT5IQ5Y6s3kMrUOiUGk6xa77zb5VvGuAfGw%3D&reserved=0>)
> 
>         * Uni (means "one" in latin or greek or something like that)
> 
>         * Mono (means "one" in latin or greek or something like that)
> 
>         I would appreciate any feedback on the suggestions I provided or
>         any additional suggestions for the name. If you have concerns
>         about the feature itself, comment on the GHC Trac ticket. I'd
>         prefer to keep this thread focused on just the problem of coming
>         up with a name.
> 
>         -- 
> 
>         -Andrew Thaddeus Martin
> 
>         _______________________________________________
>         Libraries mailing list
>         Libraries at haskell.org <mailto:Libraries at haskell.org>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>         <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=AytyB%2BhKwE1TDDc8ohTJ9gDcCZgcizoyt8Tmue0u9Zs%3D&reserved=0>
> 
> 
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>     <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=AytyB%2BhKwE1TDDc8ohTJ9gDcCZgcizoyt8Tmue0u9Zs%3D&reserved=0>
> 
> 
> 
> _______________________________________________
> 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://www.cse.chalmers.se/~abela/

From david.feuer at gmail.com  Thu Jan 18 08:27:51 2018
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 18 Jan 2018 03:27:51 -0500
Subject: Name of 1-Tuple Data Type
In-Reply-To: <9eec1f95-c102-07f1-6bc7-035efa1507b1@chalmers.se>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <9eec1f95-c102-07f1-6bc7-035efa1507b1@chalmers.se>
Message-ID: <CAMgWh9vxzn7b_L7tZqwUdjpJFPmY9VgzAOPSsto=hxwaLBWOxw@mail.gmail.com>

I imagine whatever name is chosen will have a # at the end.

On Thu, Jan 18, 2018 at 3:25 AM, Andreas Abel <abela at chalmers.se> wrote:
> -1.
>
> Don't grap any of these nice names for that obscure feature.  Take some ugly
> name.
>
> On 18.01.2018 00:46, Andrew Martin wrote:
>>
>> Required background information:
>> https://ghc.haskell.org/trac/ghc/ticket/14673
>>
>> GHC has a one-tuple (both a boxed variant and an unboxed variant). The
>> unboxed variant currently must be fully applied whenever it is used. This is
>> in stark contrast to all the other n-tuples (n > 1). It stems entirely from
>> an issue of syntax. The solution decided on is to provide a normal prefix
>> name for the 1-tuple. The name that GHC uses internally for this type is
>> `Unit#` (there is also a boxed variant Unit). However, in the haskell
>> community, the word "unit" already refers to the nullary tuple, not the
>> unary tuple. So, we're bikeshedding the name.
>>
>> Here are some possible options:
>>
>> * Unary (as in unary tuple)
>> * Single (as in single, double, triple)
>> * Singleton (as is singleton, doubleton, tripleton)
>> * Only
>> (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html)
>> * OneTuple
>> (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html)
>> * Uni (means "one" in latin or greek or something like that)
>> * Mono (means "one" in latin or greek or something like that)
>>
>> I would appreciate any feedback on the suggestions I provided or any
>> additional suggestions for the name. If you have concerns about the feature
>> itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
>> focused on just the problem of coming up with a name.
>
>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel at gu.se
> http://www.cse.chalmers.se/~abela/
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From oleg.grenrus at iki.fi  Thu Jan 18 08:36:37 2018
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Thu, 18 Jan 2018 10:36:37 +0200
Subject: Name of 1-Tuple Data Type
In-Reply-To: <15873de2-e72e-8bf3-4ff8-e4b868fb8e30@chalmers.se>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <CAO8Ockto1UnTd2LPdMRW5ic7H03HjX7s_ciXx69xx4X5t-E92g@mail.gmail.com>
 <CAJoPsuD=4CkUc1vg8NiOpAMdVMcfbDXp1V+4UErMp-0mr=d5tg@mail.gmail.com>
 <VI1PR83MB0205D2291AE8BD520B26045BADE80@VI1PR83MB0205.EURPRD83.prod.outlook.com>
 <15873de2-e72e-8bf3-4ff8-e4b868fb8e30@chalmers.se>
Message-ID: <84e26e3b-7686-2de4-35d4-cba70b1bb5a3@iki.fi>

Are we talking about the following:

    {-# LANGUAGE MagicHash, KindSignatures #-}

    import GHC.Exts

    data Unit# (a :: TYPE 'UnliftedRep) = Unit# a

    -- | Also known as:
    --
    --
https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Fusion-Util.html#t:Box
    --
https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html#t:OneTuple
    data Unit  (a :: TYPE 'LiftedRep)   = Unit a

    -- | Also known as
    --
    --
https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Fusion-Util.html#t:Id
    --
https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html
    --
https://hackage.haskell.org/package/generics-sop-0.3.2.0/docs/Generics-SOP-BasicFunctors.html#t:I
    newtype Identity a = Identity a


-- 

Some libraries (cassava, postgresql-simple - today they use different
`Only`!)
need a wrapper around a type to provide `Field a => Row a` instances,

I haven't needed a `Box` around lifted type, except when putting things
into strict containers. That name weren't proposed, but I don't feel
strongly for or against. Yet, I think `Box#` and `Box` have nice
intuition in them.

- Oleg


On 18.01.2018 10:27, Andreas Abel wrote:
> I deem this feature outside of the mainstream, so it should not occupy
> a short nice name.
>
> I suggest  UnaryTuple.
>
> On 18.01.2018 09:22, Simon Peyton Jones via Libraries wrote:
>> I quite like Solo.
>>
>> Simon
>>
>> *From:*Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of
>> *Theodore Lief Gannon
>> *Sent:* 18 January 2018 02:42
>> *To:* Ryan Reich <ryan.reich at gmail.com>
>> *Cc:* Haskell Libraries <Libraries at haskell.org>
>> *Subject:* Re: Name of 1-Tuple Data Type
>>
>> I've seen Only in the wild, and it's probably my favorite of the
>> initial suggestions for the same reasons as Ryan. Mono is my second
>> pick from that list.
>>
>> Id is very clean, but I could see pedagogical issues arising from
>> name confusion. Sing(le(ton)) is a terrible idea for the same reason.
>>
>> Venturing my own paint swatch: Solo fits in nicely with the
>> established size-specific names (pair, triple, etc.) and has all the
>> good traits: short, self-explanatory, nothing with a confusingly
>> similar name (that I know of).
>>
>> On Jan 17, 2018 4:35 PM, "Ryan Reich" <ryan.reich at gmail.com
>> <mailto:ryan.reich at gmail.com>> wrote:
>>
>>     Only has two virtues I can see easily: it's short (shorter than
>>     almost all the others), and it has the same feel as Maybe.
>>
>>     There is also Id, the name of the mathematical function that this
>>     type (and corresponding data) constructor is. Less pithy but even
>>     less intrusive.
>>
>>     On Jan 17, 2018 15:47, "Andrew Martin" <andrew.thaddeus at gmail.com
>>     <mailto:andrew.thaddeus at gmail.com>> wrote:
>>
>>         Required background information:
>>         https://ghc.haskell.org/trac/ghc/ticket/14673
>>
>>         GHC has a one-tuple (both a boxed variant and an unboxed
>>         variant). The unboxed variant currently must be fully applied
>>         whenever it is used. This is in stark contrast to all the other
>>         n-tuples (n > 1). It stems entirely from an issue of syntax. The
>>         solution decided on is to provide a normal prefix name for the
>>         1-tuple. The name that GHC uses internally for this type is
>>         `Unit#` (there is also a boxed variant Unit). However, in the
>>         haskell community, the word "unit" already refers to the nullary
>>         tuple, not the unary tuple. So, we're bikeshedding the name.
>>
>>         Here are some possible options:
>>
>>         * Unary (as in unary tuple)
>>
>>         * Single (as in single, double, triple)
>>
>>         * Singleton (as is singleton, doubleton, tripleton)
>>
>>         * Only
>>        
>> (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html
>>        
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2FOnly-0.1%2Fdocs%2FData-Tuple-Only.html&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=fMbHCFU%2Br3JHwmI8a4QgHD26fhoclfklE3xA0O6tCE4%3D&reserved=0>)
>>
>>         * OneTuple
>>        
>> (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html
>>        
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2FOneTuple-0.2.1%2Fdocs%2FData-Tuple-OneTuple.html&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=rRLW8KJoKT5IQ5Y6s3kMrUOiUGk6xa77zb5VvGuAfGw%3D&reserved=0>)
>>
>>         * Uni (means "one" in latin or greek or something like that)
>>
>>         * Mono (means "one" in latin or greek or something like that)
>>
>>         I would appreciate any feedback on the suggestions I provided or
>>         any additional suggestions for the name. If you have concerns
>>         about the feature itself, comment on the GHC Trac ticket. I'd
>>         prefer to keep this thread focused on just the problem of coming
>>         up with a name.
>>
>>         --
>>         -Andrew Thaddeus Martin
>>
>>         _______________________________________________
>>         Libraries mailing list
>>         Libraries at haskell.org <mailto:Libraries at haskell.org>
>>         http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>        
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=AytyB%2BhKwE1TDDc8ohTJ9gDcCZgcizoyt8Tmue0u9Zs%3D&reserved=0>
>>
>>
>>     _______________________________________________
>>     Libraries mailing list
>>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>    
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flibraries&data=02%7C01%7Csimonpj%40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=AytyB%2BhKwE1TDDc8ohTJ9gDcCZgcizoyt8Tmue0u9Zs%3D&reserved=0>
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180118/793484d6/attachment-0001.sig>

From ivan.miljenovic at gmail.com  Thu Jan 18 09:05:04 2018
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Thu, 18 Jan 2018 20:05:04 +1100
Subject: Name of 1-Tuple Data Type
In-Reply-To: <9eec1f95-c102-07f1-6bc7-035efa1507b1@chalmers.se>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <9eec1f95-c102-07f1-6bc7-035efa1507b1@chalmers.se>
Message-ID: <CA+u6gbzK=MCVqtS8KvQzmSQcwSMqZFW+OOFcSa5usKZLWx0ArA@mail.gmail.com>

On 18 January 2018 at 19:25, Andreas Abel <abela at chalmers.se> wrote:
> -1.
>
> Don't grap any of these nice names for that obscure feature.  Take some ugly
> name.

It seems like an obscure feature, but something similar has been
re-implemented by a suprising number of libraries (vector,
postgresql-simple, cassava, etc.).  Typically when you want to
differentiate a raw value from a (possible singular) collection of
values (e.g. field vs row).

>
> On 18.01.2018 00:46, Andrew Martin wrote:
>>
>> Required background information:
>> https://ghc.haskell.org/trac/ghc/ticket/14673
>>
>> GHC has a one-tuple (both a boxed variant and an unboxed variant). The
>> unboxed variant currently must be fully applied whenever it is used. This is
>> in stark contrast to all the other n-tuples (n > 1). It stems entirely from
>> an issue of syntax. The solution decided on is to provide a normal prefix
>> name for the 1-tuple. The name that GHC uses internally for this type is
>> `Unit#` (there is also a boxed variant Unit). However, in the haskell
>> community, the word "unit" already refers to the nullary tuple, not the
>> unary tuple. So, we're bikeshedding the name.
>>
>> Here are some possible options:
>>
>> * Unary (as in unary tuple)
>> * Single (as in single, double, triple)
>> * Singleton (as is singleton, doubleton, tripleton)
>> * Only
>> (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tuple-Only.html)
>> * OneTuple
>> (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Data-Tuple-OneTuple.html)
>> * Uni (means "one" in latin or greek or something like that)
>> * Mono (means "one" in latin or greek or something like that)
>>
>> I would appreciate any feedback on the suggestions I provided or any
>> additional suggestions for the name. If you have concerns about the feature
>> itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
>> focused on just the problem of coming up with a name.
>
>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel at gu.se
> http://www.cse.chalmers.se/~abela/
>
> _______________________________________________
> 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 lemming at henning-thielemann.de  Thu Jan 18 08:31:58 2018
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 18 Jan 2018 09:31:58 +0100 (CET)
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CAMgWh9vxzn7b_L7tZqwUdjpJFPmY9VgzAOPSsto=hxwaLBWOxw@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <9eec1f95-c102-07f1-6bc7-035efa1507b1@chalmers.se>
 <CAMgWh9vxzn7b_L7tZqwUdjpJFPmY9VgzAOPSsto=hxwaLBWOxw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1801180931210.9005@sputnik>


On Thu, 18 Jan 2018, David Feuer wrote:

> I imagine whatever name is chosen will have a # at the end.

... and you can disambiguate using qualification.

From andrew.thaddeus at gmail.com  Thu Jan 18 18:30:10 2018
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Thu, 18 Jan 2018 13:30:10 -0500
Subject: Name of 1-Tuple Data Type
In-Reply-To: <15873de2-e72e-8bf3-4ff8-e4b868fb8e30@chalmers.se>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <CAO8Ockto1UnTd2LPdMRW5ic7H03HjX7s_ciXx69xx4X5t-E92g@mail.gmail.com>
 <CAJoPsuD=4CkUc1vg8NiOpAMdVMcfbDXp1V+4UErMp-0mr=d5tg@mail.gmail.com>
 <VI1PR83MB0205D2291AE8BD520B26045BADE80@VI1PR83MB0205.EURPRD83.prod.outlook.com>
 <15873de2-e72e-8bf3-4ff8-e4b868fb8e30@chalmers.se>
Message-ID: <CABNC7eMKLWY_XgbaRsMyJadag700y4qDLV6BZsxw8JhzEGuLGA@mail.gmail.com>

It's certainly outside of the mainstream, but it's not going to be part of
the prelude. You'll need to import GHC.Prim or GHC.Exts to get a hold of
it. For this reason, I'm not too worried about stealing a good name.

On Thu, Jan 18, 2018 at 3:27 AM, Andreas Abel <abela at chalmers.se> wrote:

> I deem this feature outside of the mainstream, so it should not occupy a
> short nice name.
>
> I suggest  UnaryTuple.
>
> On 18.01.2018 09:22, Simon Peyton Jones via Libraries wrote:
>
>> I quite like Solo.
>>
>> Simon
>>
>> *From:*Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of
>> *Theodore Lief Gannon
>> *Sent:* 18 January 2018 02:42
>> *To:* Ryan Reich <ryan.reich at gmail.com>
>> *Cc:* Haskell Libraries <Libraries at haskell.org>
>> *Subject:* Re: Name of 1-Tuple Data Type
>>
>> I've seen Only in the wild, and it's probably my favorite of the initial
>> suggestions for the same reasons as Ryan. Mono is my second pick from that
>> list.
>>
>> Id is very clean, but I could see pedagogical issues arising from name
>> confusion. Sing(le(ton)) is a terrible idea for the same reason.
>>
>> Venturing my own paint swatch: Solo fits in nicely with the established
>> size-specific names (pair, triple, etc.) and has all the good traits:
>> short, self-explanatory, nothing with a confusingly similar name (that I
>> know of).
>>
>> On Jan 17, 2018 4:35 PM, "Ryan Reich" <ryan.reich at gmail.com <mailto:
>> ryan.reich at gmail.com>> wrote:
>>
>>     Only has two virtues I can see easily: it's short (shorter than
>>     almost all the others), and it has the same feel as Maybe.
>>
>>     There is also Id, the name of the mathematical function that this
>>     type (and corresponding data) constructor is. Less pithy but even
>>     less intrusive.
>>
>>     On Jan 17, 2018 15:47, "Andrew Martin" <andrew.thaddeus at gmail.com
>>     <mailto:andrew.thaddeus at gmail.com>> wrote:
>>
>>         Required background information:
>>         https://ghc.haskell.org/trac/ghc/ticket/14673
>>
>>         GHC has a one-tuple (both a boxed variant and an unboxed
>>         variant). The unboxed variant currently must be fully applied
>>         whenever it is used. This is in stark contrast to all the other
>>         n-tuples (n > 1). It stems entirely from an issue of syntax. The
>>         solution decided on is to provide a normal prefix name for the
>>         1-tuple. The name that GHC uses internally for this type is
>>         `Unit#` (there is also a boxed variant Unit). However, in the
>>         haskell community, the word "unit" already refers to the nullary
>>         tuple, not the unary tuple. So, we're bikeshedding the name.
>>
>>         Here are some possible options:
>>
>>         * Unary (as in unary tuple)
>>
>>         * Single (as in single, double, triple)
>>
>>         * Singleton (as is singleton, doubleton, tripleton)
>>
>>         * Only
>>         (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tupl
>> e-Only.html
>>         <https://na01.safelinks.protection.outlook.com/?url=https%
>> 3A%2F%2Fhackage.haskell.org%2Fpackage%2FOnly-0.1%2Fdocs%
>> 2FData-Tuple-Only.html&data=02%7C01%7Csimonpj%40microsoft.
>> com%7C3db602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91a
>> b2d7cd011db47%7C1%7C0%7C636518401685292292&sdata=fMbHCFU%2Br
>> 3JHwmI8a4QgHD26fhoclfklE3xA0O6tCE4%3D&reserved=0>)
>>
>>         * OneTuple
>>         (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Dat
>> a-Tuple-OneTuple.html
>>         <https://na01.safelinks.protection.outlook.com/?url=https%
>> 3A%2F%2Fhackage.haskell.org%2Fpackage%2FOneTuple-0.2.1%
>> 2Fdocs%2FData-Tuple-OneTuple.html&data=02%7C01%7Csimonpj%
>> 40microsoft.com%7C3db602b14f26474965ff08d55e1d285f%7C72f988b
>> f86f141af91ab2d7cd011db47%7C1%7C0%7C636518401685292292&
>> sdata=rRLW8KJoKT5IQ5Y6s3kMrUOiUGk6xa77zb5VvGuAfGw%3D&reserved=0>)
>>
>>         * Uni (means "one" in latin or greek or something like that)
>>
>>         * Mono (means "one" in latin or greek or something like that)
>>
>>         I would appreciate any feedback on the suggestions I provided or
>>         any additional suggestions for the name. If you have concerns
>>         about the feature itself, comment on the GHC Trac ticket. I'd
>>         prefer to keep this thread focused on just the problem of coming
>>         up with a name.
>>
>>         --
>>         -Andrew Thaddeus Martin
>>
>>         _______________________________________________
>>         Libraries mailing list
>>         Libraries at haskell.org <mailto:Libraries at haskell.org>
>>         http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>         <https://na01.safelinks.protection.outlook.com/?url=http%3A%
>> 2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%
>> 2Flibraries&data=02%7C01%7Csimonpj%40microsoft.com%7C3d
>> b602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd01
>> 1db47%7C1%7C0%7C636518401685292292&sdata=AytyB%2BhKwE1TDDc8o
>> hTJ9gDcCZgcizoyt8Tmue0u9Zs%3D&reserved=0>
>>
>>
>>     _______________________________________________
>>     Libraries mailing list
>>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>     <https://na01.safelinks.protection.outlook.com/?url=http%3A%
>> 2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%
>> 2Flibraries&data=02%7C01%7Csimonpj%40microsoft.com%7C3d
>> b602b14f26474965ff08d55e1d285f%7C72f988bf86f141af91ab2d7cd01
>> 1db47%7C1%7C0%7C636518401685292292&sdata=AytyB%2BhKwE1TDDc8o
>> hTJ9gDcCZgcizoyt8Tmue0u9Zs%3D&reserved=0>
>>
>>
>>
>> _______________________________________________
>> 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://www.cse.chalmers.se/~abela/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180118/200d9add/attachment.html>

From andrew.thaddeus at gmail.com  Thu Jan 18 18:32:26 2018
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Thu, 18 Jan 2018 13:32:26 -0500
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CAL3m8eB4a+9HSiXzZUShUHRtQ=X3UFjQPVaFTX-m7B5Gu-=OWA@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <CAL3m8eB4a+9HSiXzZUShUHRtQ=X3UFjQPVaFTX-m7B5Gu-=OWA@mail.gmail.com>
Message-ID: <CABNC7eP_2yRHqjFFYUfhDmY7-rU7mHBM8+71FQzisz9wP+xdCg@mail.gmail.com>

The problem with using Identity and Identity# is that there's already
something in base named Identity, and since it's a newtype (not a data
type), it has the wrong semantics concerning laziness for this kind of
thing.

On Wed, Jan 17, 2018 at 7:27 PM, M Farkas-Dyck <m.farkasdyck at gmail.com>
wrote:

> Identity#
>



-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180118/18e23011/attachment.html>

From andrew.thaddeus at gmail.com  Thu Jan 18 18:36:35 2018
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Thu, 18 Jan 2018 13:36:35 -0500
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CAJoPsuD=4CkUc1vg8NiOpAMdVMcfbDXp1V+4UErMp-0mr=d5tg@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <CAO8Ockto1UnTd2LPdMRW5ic7H03HjX7s_ciXx69xx4X5t-E92g@mail.gmail.com>
 <CAJoPsuD=4CkUc1vg8NiOpAMdVMcfbDXp1V+4UErMp-0mr=d5tg@mail.gmail.com>
Message-ID: <CABNC7ePoyXc7Lcj8wJh=OfRCM12yQGcVQb8obxsYa3_PYsY8Cw@mail.gmail.com>

I like Solo. I think it would be a very good name for this for the reasons
you listed.

On Wed, Jan 17, 2018 at 9:41 PM, Theodore Lief Gannon <tanuki at gmail.com>
wrote:

> I've seen Only in the wild, and it's probably my favorite of the initial
> suggestions for the same reasons as Ryan. Mono is my second pick from that
> list.
>
> Id is very clean, but I could see pedagogical issues arising from name
> confusion. Sing(le(ton)) is a terrible idea for the same reason.
>
> Venturing my own paint swatch: Solo fits in nicely with the established
> size-specific names (pair, triple, etc.) and has all the good traits:
> short, self-explanatory, nothing with a confusingly similar name (that I
> know of).
>
>
> On Jan 17, 2018 4:35 PM, "Ryan Reich" <ryan.reich at gmail.com> wrote:
>
> Only has two virtues I can see easily: it's short (shorter than almost all
> the others), and it has the same feel as Maybe.
>
> There is also Id, the name of the mathematical function that this type
> (and corresponding data) constructor is. Less pithy but even less intrusive.
>
> On Jan 17, 2018 15:47, "Andrew Martin" <andrew.thaddeus at gmail.com> wrote:
>
> Required background information: https://ghc.haske
> ll.org/trac/ghc/ticket/14673
>
> GHC has a one-tuple (both a boxed variant and an unboxed variant). The
> unboxed variant currently must be fully applied whenever it is used. This
> is in stark contrast to all the other n-tuples (n > 1). It stems entirely
> from an issue of syntax. The solution decided on is to provide a normal
> prefix name for the 1-tuple. The name that GHC uses internally for this
> type is `Unit#` (there is also a boxed variant Unit). However, in the
> haskell community, the word "unit" already refers to the nullary tuple, not
> the unary tuple. So, we're bikeshedding the name.
>
> Here are some possible options:
>
> * Unary (as in unary tuple)
> * Single (as in single, double, triple)
> * Singleton (as is singleton, doubleton, tripleton)
> * Only (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tupl
> e-Only.html)
> * OneTuple (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Dat
> a-Tuple-OneTuple.html)
> * Uni (means "one" in latin or greek or something like that)
> * Mono (means "one" in latin or greek or something like that)
>
> I would appreciate any feedback on the suggestions I provided or any
> additional suggestions for the name. If you have concerns about the feature
> itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
> focused on just the problem of coming up with a name.
>
> --
> -Andrew Thaddeus Martin
>
> _______________________________________________
> 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
>
>
>


-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180118/274786eb/attachment-0001.html>

From carter.schonwald at gmail.com  Thu Jan 18 21:17:38 2018
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 18 Jan 2018 16:17:38 -0500
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CABNC7ePoyXc7Lcj8wJh=OfRCM12yQGcVQb8obxsYa3_PYsY8Cw@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <CAO8Ockto1UnTd2LPdMRW5ic7H03HjX7s_ciXx69xx4X5t-E92g@mail.gmail.com>
 <CAJoPsuD=4CkUc1vg8NiOpAMdVMcfbDXp1V+4UErMp-0mr=d5tg@mail.gmail.com>
 <CABNC7ePoyXc7Lcj8wJh=OfRCM12yQGcVQb8obxsYa3_PYsY8Cw@mail.gmail.com>
Message-ID: <CAHYVw0zkQzPm1-2ySeLVXy1TWYT_EkDSRn3xu4gBpM4tbHvtvQ@mail.gmail.com>

Unit# seems fine to me, its not gonna be in prelude, its a short name,

i dislike Only because i've only really seen it come up in in DB libraries
:)

On Thu, Jan 18, 2018 at 1:36 PM, Andrew Martin <andrew.thaddeus at gmail.com>
wrote:

> I like Solo. I think it would be a very good name for this for the reasons
> you listed.
>
> On Wed, Jan 17, 2018 at 9:41 PM, Theodore Lief Gannon <tanuki at gmail.com>
> wrote:
>
>> I've seen Only in the wild, and it's probably my favorite of the initial
>> suggestions for the same reasons as Ryan. Mono is my second pick from that
>> list.
>>
>> Id is very clean, but I could see pedagogical issues arising from name
>> confusion. Sing(le(ton)) is a terrible idea for the same reason.
>>
>> Venturing my own paint swatch: Solo fits in nicely with the established
>> size-specific names (pair, triple, etc.) and has all the good traits:
>> short, self-explanatory, nothing with a confusingly similar name (that I
>> know of).
>>
>>
>> On Jan 17, 2018 4:35 PM, "Ryan Reich" <ryan.reich at gmail.com> wrote:
>>
>> Only has two virtues I can see easily: it's short (shorter than almost
>> all the others), and it has the same feel as Maybe.
>>
>> There is also Id, the name of the mathematical function that this type
>> (and corresponding data) constructor is. Less pithy but even less intrusive.
>>
>> On Jan 17, 2018 15:47, "Andrew Martin" <andrew.thaddeus at gmail.com> wrote:
>>
>> Required background information: https://ghc.haske
>> ll.org/trac/ghc/ticket/14673
>>
>> GHC has a one-tuple (both a boxed variant and an unboxed variant). The
>> unboxed variant currently must be fully applied whenever it is used. This
>> is in stark contrast to all the other n-tuples (n > 1). It stems entirely
>> from an issue of syntax. The solution decided on is to provide a normal
>> prefix name for the 1-tuple. The name that GHC uses internally for this
>> type is `Unit#` (there is also a boxed variant Unit). However, in the
>> haskell community, the word "unit" already refers to the nullary tuple, not
>> the unary tuple. So, we're bikeshedding the name.
>>
>> Here are some possible options:
>>
>> * Unary (as in unary tuple)
>> * Single (as in single, double, triple)
>> * Singleton (as is singleton, doubleton, tripleton)
>> * Only (https://hackage.haskell.org/package/Only-0.1/docs/Data-Tupl
>> e-Only.html)
>> * OneTuple (https://hackage.haskell.org/package/OneTuple-0.2.1/docs/Dat
>> a-Tuple-OneTuple.html)
>> * Uni (means "one" in latin or greek or something like that)
>> * Mono (means "one" in latin or greek or something like that)
>>
>> I would appreciate any feedback on the suggestions I provided or any
>> additional suggestions for the name. If you have concerns about the feature
>> itself, comment on the GHC Trac ticket. I'd prefer to keep this thread
>> focused on just the problem of coming up with a name.
>>
>> --
>> -Andrew Thaddeus Martin
>>
>> _______________________________________________
>> 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
>>
>>
>>
>
>
> --
> -Andrew Thaddeus Martin
>
> _______________________________________________
> 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/20180118/7d4dc961/attachment.html>

From kris.nuttycombe at gmail.com  Thu Jan 18 22:37:59 2018
From: kris.nuttycombe at gmail.com (Kris Nuttycombe)
Date: Thu, 18 Jan 2018 15:37:59 -0700
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CAL3m8eB4a+9HSiXzZUShUHRtQ=X3UFjQPVaFTX-m7B5Gu-=OWA@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <CAL3m8eB4a+9HSiXzZUShUHRtQ=X3UFjQPVaFTX-m7B5Gu-=OWA@mail.gmail.com>
Message-ID: <CAHFpbunGgKsUnJmAZRqmK8XUgPZc3ehRgprA5WSmyW0gHxL8OA@mail.gmail.com>

Identity# is my favorite of all those I've seen suggested thus far.

On Wed, Jan 17, 2018 at 5:27 PM, M Farkas-Dyck <m.farkasdyck at gmail.com>
wrote:

> Identity#
> _______________________________________________
> 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/20180118/027dc5b8/attachment.html>

From abela at chalmers.se  Fri Jan 19 08:48:55 2018
From: abela at chalmers.se (Andreas Abel)
Date: Fri, 19 Jan 2018 09:48:55 +0100
Subject: Name of 1-Tuple Data Type
In-Reply-To: <alpine.DEB.2.20.1801180931210.9005@sputnik>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
 <9eec1f95-c102-07f1-6bc7-035efa1507b1@chalmers.se>
 <CAMgWh9vxzn7b_L7tZqwUdjpJFPmY9VgzAOPSsto=hxwaLBWOxw@mail.gmail.com>
 <alpine.DEB.2.20.1801180931210.9005@sputnik>
Message-ID: <b0d1d4ec-83d6-ce48-d441-02bf4fd3dc67@chalmers.se>

 >> I imagine whatever name is chosen will have a # at the end.

Then there is no concern.

On 18.01.2018 09:31, Henning Thielemann wrote:
> 
> On Thu, 18 Jan 2018, David Feuer wrote:
> 
>> I imagine whatever name is chosen will have a # at the end.
> 
> ... and you can disambiguate using qualification.
> _______________________________________________
> 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://www.cse.chalmers.se/~abela/

From andrew.lelechenko at gmail.com  Sat Jan 20 18:45:17 2018
From: andrew.lelechenko at gmail.com (Andrew Lelechenko)
Date: Sat, 20 Jan 2018 18:45:17 +0000
Subject: Taking over maintainership of exact-pi
Message-ID: <2A8272FA-F807-4C4E-84C8-E6139A41DBDF@gmail.com>

I would like to take over `exact-pi` package (https://hackage.haskell.org/package/exact-pi).
Unfortunately, the package became incompatible with upcoming GHC 8.4 and needs an upgrade. The relevant pull request (https://github.com/dmcclean/exact-pi/pull/5), prepared by @konn, has been open for a month without response. I also tried to reach its maintainer Douglas McClean (cced) by email, but have not heard back.

I am so interested in upgrading `exact-pi`, because it is a dependency of my package `arithmoi`.

— 
Best regards,
Andrew


From douglas.mcclean at gmail.com  Sat Jan 20 19:18:54 2018
From: douglas.mcclean at gmail.com (Douglas McClean)
Date: Sat, 20 Jan 2018 14:18:54 -0500
Subject: Taking over maintainership of exact-pi
In-Reply-To: <2A8272FA-F807-4C4E-84C8-E6139A41DBDF@gmail.com>
References: <2A8272FA-F807-4C4E-84C8-E6139A41DBDF@gmail.com>
Message-ID: <CACruqwQc3e38Q6qYGrgZDLnrD4oM-b7Th92r9Nv1NycFbs44bA@mail.gmail.com>

Sorry everyone, new baby. Will review PR by end of weekend.

On Jan 20, 2018 1:45 PM, "Andrew Lelechenko" <andrew.lelechenko at gmail.com>
wrote:

> I would like to take over `exact-pi` package (https://hackage.haskell.org/
> package/exact-pi).
> Unfortunately, the package became incompatible with upcoming GHC 8.4 and
> needs an upgrade. The relevant pull request (https://github.com/dmcclean/
> exact-pi/pull/5), prepared by @konn, has been open for a month without
> response. I also tried to reach its maintainer Douglas McClean (cced) by
> email, but have not heard back.
>
> I am so interested in upgrading `exact-pi`, because it is a dependency of
> my package `arithmoi`.
>
> —
> Best regards,
> Andrew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180120/7985d463/attachment.html>

From lemming at henning-thielemann.de  Mon Jan 22 08:44:23 2018
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 22 Jan 2018 09:44:23 +0100 (CET)
Subject: generalized IntMap - IntegerMap or IntegralMap
Message-ID: <alpine.DEB.2.20.1801220936250.5529@sputnik>


I want to use Word32 or Word64 bit patterns as indices for a Map. I have 
checked that IntMap is more efficient than Map in my application. However, 
the Haskell 98 report warrants only 30 bits for Int including the sign 
bit. Is there a generalization of IntMap for Map Integer or (Integral k, 
Bits k) => Map k or would there be general interest in such a data 
structure?

From david.feuer at gmail.com  Mon Jan 22 09:05:37 2018
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 22 Jan 2018 04:05:37 -0500
Subject: generalized IntMap - IntegerMap or IntegralMap
In-Reply-To: <alpine.DEB.2.20.1801220936250.5529@sputnik>
References: <alpine.DEB.2.20.1801220936250.5529@sputnik>
Message-ID: <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>

There has been some discussion in the past, but it hasn't gone far. A
few points:

1. Integer is a bit tough to deal with. It might make sense to use
some sort of trie for Integer keys.

2. I would very much like to add Data.Int64{Map,Set} and perhaps also
Data.Int32{Map,Set} to containers. Unfortunately, I don't have the
time to consider such a thing at the moment. Jonathan S. has been
working (on and off) on a wholesale replacement for IntMap. Perhaps he
has ideas for this extension as well. IntMap itself could become a
wrapper around one of those two, or could perhaps be implemented
separately (although I doubt it's worth the trouble).

3. I don't think any existing classes really get the point across. To
fit in an IntMap, a type must *actually* satisfy the law that   toEnum
. fromEnum = id. Furthermore, some operations will only make sense if
toEnum is strictly order-preserving. One option would be to add an ad
hoc class for just this purpose:

class SmallKey k where
  -- Laws:
  -- fromInt . toInt = id
  -- If k has an Ord instance, then toInt is strictly order-preserving.
  toInt :: k -> Int
  fromInt :: Int -> k

Of course, if (2) should happen, then we'll need SmallKey32 and
SmallKey64 classes.

On Mon, Jan 22, 2018 at 3:44 AM, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
>
> I want to use Word32 or Word64 bit patterns as indices for a Map. I have
> checked that IntMap is more efficient than Map in my application. However,
> the Haskell 98 report warrants only 30 bits for Int including the sign bit.
> Is there a generalization of IntMap for Map Integer or (Integral k, Bits k)
> => Map k or would there be general interest in such a data structure?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From lemming at henning-thielemann.de  Mon Jan 22 09:14:18 2018
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 22 Jan 2018 10:14:18 +0100 (CET)
Subject: generalized IntMap - IntegerMap or IntegralMap
In-Reply-To: <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
References: <alpine.DEB.2.20.1801220936250.5529@sputnik>
 <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1801221012270.5529@sputnik>


On Mon, 22 Jan 2018, David Feuer wrote:

> 3. I don't think any existing classes really get the point across.

I would be happy with a custom class that has Word32 and Word64 as member, 
and optimally a way to compose these words, e.g.
    type Word96 = Stack Word32 Word64

From david.feuer at gmail.com  Mon Jan 22 09:19:04 2018
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 22 Jan 2018 04:19:04 -0500
Subject: generalized IntMap - IntegerMap or IntegralMap
In-Reply-To: <alpine.DEB.2.20.1801221012270.5529@sputnik>
References: <alpine.DEB.2.20.1801220936250.5529@sputnik>
 <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
 <alpine.DEB.2.20.1801221012270.5529@sputnik>
Message-ID: <CAMgWh9tqgyeov-qUVTHjn0Dbm3nQ0v_11Hd4eSwn06BGj1Xohg@mail.gmail.com>

Word64 is an entirely different story, because it's not
order-isomorphic to Int64. That means lots of operations will actually
have to be implemented differently for it. Anyway, you should probably
check out the generic-trie package for ways to compose things.

On Mon, Jan 22, 2018 at 4:14 AM, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
>
> On Mon, 22 Jan 2018, David Feuer wrote:
>
>> 3. I don't think any existing classes really get the point across.
>
>
> I would be happy with a custom class that has Word32 and Word64 as member,
> and optimally a way to compose these words, e.g.
>    type Word96 = Stack Word32 Word64

From david.feuer at gmail.com  Mon Jan 22 09:20:06 2018
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 22 Jan 2018 04:20:06 -0500
Subject: generalized IntMap - IntegerMap or IntegralMap
In-Reply-To: <CAMgWh9tqgyeov-qUVTHjn0Dbm3nQ0v_11Hd4eSwn06BGj1Xohg@mail.gmail.com>
References: <alpine.DEB.2.20.1801220936250.5529@sputnik>
 <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
 <alpine.DEB.2.20.1801221012270.5529@sputnik>
 <CAMgWh9tqgyeov-qUVTHjn0Dbm3nQ0v_11Hd4eSwn06BGj1Xohg@mail.gmail.com>
Message-ID: <CAMgWh9tNey_TKvysFRRbn3s08wqY3Vbe0o1bvEm47qqh6SE9AA@mail.gmail.com>

Er... what am I thinking? Of course it's order-isomorphic. The
isomorphism just isn't a coercion, so it's not free.

On Mon, Jan 22, 2018 at 4:19 AM, David Feuer <david.feuer at gmail.com> wrote:
> Word64 is an entirely different story, because it's not
> order-isomorphic to Int64. That means lots of operations will actually
> have to be implemented differently for it. Anyway, you should probably
> check out the generic-trie package for ways to compose things.
>
> On Mon, Jan 22, 2018 at 4:14 AM, Henning Thielemann
> <lemming at henning-thielemann.de> wrote:
>>
>> On Mon, 22 Jan 2018, David Feuer wrote:
>>
>>> 3. I don't think any existing classes really get the point across.
>>
>>
>> I would be happy with a custom class that has Word32 and Word64 as member,
>> and optimally a way to compose these words, e.g.
>>    type Word96 = Stack Word32 Word64

From lemming at henning-thielemann.de  Mon Jan 22 09:23:27 2018
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 22 Jan 2018 10:23:27 +0100 (CET)
Subject: generalized IntMap - IntegerMap or IntegralMap
In-Reply-To: <CAMgWh9tqgyeov-qUVTHjn0Dbm3nQ0v_11Hd4eSwn06BGj1Xohg@mail.gmail.com>
References: <alpine.DEB.2.20.1801220936250.5529@sputnik>
 <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
 <alpine.DEB.2.20.1801221012270.5529@sputnik>
 <CAMgWh9tqgyeov-qUVTHjn0Dbm3nQ0v_11Hd4eSwn06BGj1Xohg@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1801221022390.5529@sputnik>


On Mon, 22 Jan 2018, David Feuer wrote:

> Word64 is an entirely different story, because it's not
> order-isomorphic to Int64. That means lots of operations will actually
> have to be implemented differently for it. Anyway, you should probably
> check out the generic-trie package for ways to compose things.

Thank you for the pointer! I see, TrieKey has a pair instance. 
Unfortunately it misses Word32.

From mail at joachim-breitner.de  Mon Jan 22 15:53:28 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 22 Jan 2018 10:53:28 -0500
Subject: generalized IntMap - IntegerMap or IntegralMap
In-Reply-To: <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
References: <alpine.DEB.2.20.1801220936250.5529@sputnik>
 <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
Message-ID: <1516636408.1033.4.camel@joachim-breitner.de>

Hi,

Am Montag, den 22.01.2018, 04:05 -0500 schrieb David Feuer:
> Jonathan S. has been working (on and off) on a wholesale replacement for IntMap.

what is the plan here? I am currently in the process of formally
verifying IntSet (and later IntMap), so I am curious about what is
going to change here.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180122/864035d1/attachment.sig>

From david.feuer at gmail.com  Mon Jan 22 15:58:47 2018
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 22 Jan 2018 10:58:47 -0500
Subject: generalized IntMap - IntegerMap or IntegralMap
In-Reply-To: <1516636408.1033.4.camel@joachim-breitner.de>
References: <alpine.DEB.2.20.1801220936250.5529@sputnik>
 <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
 <1516636408.1033.4.camel@joachim-breitner.de>
Message-ID: <CAMgWh9tPQQOq_-iv=UjpW50L+XWqOzWSbgKtwJKe0jR7XUUFjQ@mail.gmail.com>

I wish I knew. There are some loose ends that need to be tied up and
unfortunately I have no sense of whether that's happening.

On Jan 22, 2018 10:54 AM, "Joachim Breitner" <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, den 22.01.2018, 04:05 -0500 schrieb David Feuer:
> > Jonathan S. has been working (on and off) on a wholesale replacement for
> IntMap.
>
> what is the plan here? I am currently in the process of formally
> verifying IntSet (and later IntMap), so I am curious about what is
> going to change here.
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20180122/8ed64226/attachment.html>

From ollie at ocharles.org.uk  Mon Jan 22 18:38:09 2018
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Mon, 22 Jan 2018 18:38:09 +0000
Subject: generalized IntMap - IntegerMap or IntegralMap
In-Reply-To: <CAMgWh9tPQQOq_-iv=UjpW50L+XWqOzWSbgKtwJKe0jR7XUUFjQ@mail.gmail.com>
References: <alpine.DEB.2.20.1801220936250.5529@sputnik>
 <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
 <1516636408.1033.4.camel@joachim-breitner.de>
 <CAMgWh9tPQQOq_-iv=UjpW50L+XWqOzWSbgKtwJKe0jR7XUUFjQ@mail.gmail.com>
Message-ID: <CAGRp5Rk0nCKnq8v4ZjjXM-Hb=A07Aj0DxQ-Lek33+4voY+PNtA@mail.gmail.com>

Would backpack be at all useful here? Seems you want to parameterise the
map by choice of numeric type.

On 22 Jan 2018 3:59 pm, "David Feuer" <david.feuer at gmail.com> wrote:

> I wish I knew. There are some loose ends that need to be tied up and
> unfortunately I have no sense of whether that's happening.
>
> On Jan 22, 2018 10:54 AM, "Joachim Breitner" <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Montag, den 22.01.2018, 04:05 -0500 schrieb David Feuer:
>> > Jonathan S. has been working (on and off) on a wholesale replacement
>> for IntMap.
>>
>> what is the plan here? I am currently in the process of formally
>> verifying IntSet (and later IntMap), so I am curious about what is
>> going to change here.
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> 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/20180122/ce4b9001/attachment.html>

From david.feuer at gmail.com  Mon Jan 22 18:42:22 2018
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 22 Jan 2018 13:42:22 -0500
Subject: Fwd: Re: generalized IntMap - IntegerMap or IntegralMap
In-Reply-To: <CAMgWh9usFeCgMt3hE4MjQfVHjMyPiRnm25aDNWwWB=pVPqTFfg@mail.gmail.com>
References: <alpine.DEB.2.20.1801220936250.5529@sputnik>
 <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
 <1516636408.1033.4.camel@joachim-breitner.de>
 <CAMgWh9tPQQOq_-iv=UjpW50L+XWqOzWSbgKtwJKe0jR7XUUFjQ@mail.gmail.com>
 <CAGRp5Rk0nCKnq8v4ZjjXM-Hb=A07Aj0DxQ-Lek33+4voY+PNtA@mail.gmail.com>
 <CAMgWh9usFeCgMt3hE4MjQfVHjMyPiRnm25aDNWwWB=pVPqTFfg@mail.gmail.com>
Message-ID: <CAMgWh9s-3RCCTH-QccuNMmT=JywqZ77YrcVp1vKO6hAdBZr3rQ@mail.gmail.com>

---------- Forwarded message ----------
From: "David Feuer" <david.feuer at gmail.com>
Date: Jan 22, 2018 1:42 PM
Subject: Re: generalized IntMap - IntegerMap or IntegralMap
To: "Oliver Charles" <ollie at ocharles.org.uk>
Cc:

That would help, in theory. But backpack is a bleeding-edge experimental
GHC feature, and containers has a long history of striving for relative
portability. So for now we need to stick to CPP and whatever other
widely-available preprocessors we want.

On Jan 22, 2018 1:38 PM, "Oliver Charles" <ollie at ocharles.org.uk> wrote:

> Would backpack be at all useful here? Seems you want to parameterise the
> map by choice of numeric type.
>
> On 22 Jan 2018 3:59 pm, "David Feuer" <david.feuer at gmail.com> wrote:
>
>> I wish I knew. There are some loose ends that need to be tied up and
>> unfortunately I have no sense of whether that's happening.
>>
>> On Jan 22, 2018 10:54 AM, "Joachim Breitner" <mail at joachim-breitner.de>
>> wrote:
>>
>>> Hi,
>>>
>>> Am Montag, den 22.01.2018, 04:05 -0500 schrieb David Feuer:
>>> > Jonathan S. has been working (on and off) on a wholesale replacement
>>> for IntMap.
>>>
>>> what is the plan here? I am currently in the process of formally
>>> verifying IntSet (and later IntMap), so I am curious about what is
>>> going to change here.
>>>
>>> Cheers,
>>> Joachim
>>>
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>> _______________________________________________
>>> 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/20180122/b50aa440/attachment.html>

From gereeter+haskell.libraries at gmail.com  Mon Jan 22 19:38:13 2018
From: gereeter+haskell.libraries at gmail.com (Jonathan S)
Date: Mon, 22 Jan 2018 13:38:13 -0600
Subject: generalized IntMap - IntegerMap or IntegralMap
In-Reply-To: <CAMgWh9s-3RCCTH-QccuNMmT=JywqZ77YrcVp1vKO6hAdBZr3rQ@mail.gmail.com>
References: <alpine.DEB.2.20.1801220936250.5529@sputnik>
 <CAMgWh9t8rzYnWteb6s=pCcCZnqdS1gMKY1aAD+Sm19N_16L-4w@mail.gmail.com>
 <1516636408.1033.4.camel@joachim-breitner.de>
 <CAMgWh9tPQQOq_-iv=UjpW50L+XWqOzWSbgKtwJKe0jR7XUUFjQ@mail.gmail.com>
 <CAGRp5Rk0nCKnq8v4ZjjXM-Hb=A07Aj0DxQ-Lek33+4voY+PNtA@mail.gmail.com>
 <CAMgWh9usFeCgMt3hE4MjQfVHjMyPiRnm25aDNWwWB=pVPqTFfg@mail.gmail.com>
 <CAMgWh9s-3RCCTH-QccuNMmT=JywqZ77YrcVp1vKO6hAdBZr3rQ@mail.gmail.com>
Message-ID: <CALKmN4_2CUeBoT2LV=_wWgiMYQ5giK_yyjBwfw1_rBtjAYg6aQ@mail.gmail.com>

> Jonathan S. has been working (on and off) on a wholesale replacement for IntMap.

For context, this is me.

> what is the plan here? I am currently in the process of formally
> verifying IntSet (and later IntMap), so I am curious about what is
> going to change here.

The algorithm is related in that the shape of the tree for a given set
of keys is the same as the shape of a Patricia tree. However, the way
everything is encoded and where keys and values are stored is
completely different. The best description of the algorithm currently
is at https://github.com/gereeter/bounded-intmap/blob/master/README.md
.The description is in terms of a WordMap, since the logic is easier
to follow with unsigned integers and it was something I personally
wanted. https://www.schoolofhaskell.com/user/edwardk/revisiting-matrix-multiplication/part-4
is also a useful resource, which describes an unoptimized version of
the structure.

> I wish I knew. There are some loose ends that need to be tied up and unfortunately I have no sense of whether that's happening.

On the implementation from, working on and off is quite accurate. I'm
working on it whenever I have the time, energy, and interest, which
unfortunately hasn't been that often. That said, the implementation is
almost done. If my benchmarks are correct (and I'm not entirely sure
they are, but they are somewhat believeable), the new implementation
is basically universally faster, and the only function left
unimplemented is mergeA (I think). Most of the remaining work is in
documentation, and I guess that could theoretically done at least
partially in a second pass and PR if it is easier and people want the
changes merged.

> Er... what am I thinking? Of course it's order-isomorphic. The isomorphism just isn't a coercion, so it's not free.

I'm completely confident that at least my IntMap implementation works
unmodified for both signed and unsigned integers, even though they
don't have a free order isomorphism. I originally implemented IntMap
(in the standalone bounded-intmap repository) by just casting to Word
and fiddling with the order afterwards, and similarly you could pass
everything in and out with the order isomorphism, but it turns out to
be unnecessary - the difference in order can only switch the two
children of the topmost node, and since comparison is used when
determining which branch to take, the navigation procedure is also
flipped consistently at the topmost node when using signed integers.
You could take the implementation in haskell/containers#60 and make it
generic on the key type (requiring Ord and Bits), and I'm completely
confident that it work correctly in all (2's complement) cases,
regardless of the signedness or the bitwidth.

> Would backpack be at all useful here? Seems you want to parameterise the map by choice of numeric type.

The only use I see for Backpack here is in unboxing the integer type.
IntMap gets a fairly large portion of its efficiency from having
unboxed keys (see, e.g.,
https://www.twanvl.nl/blog/haskell/benchmarking-unpacked-containers),
and GHC currently can't unbox generic parameters. If I understand the
Backpack work correctly, each instantiation of IntegerMap would be
distinct, so GHC would have no problem unboxing the keys.

On Mon, Jan 22, 2018 at 12:42 PM, David Feuer <david.feuer at gmail.com> wrote:
> ---------- Forwarded message ----------
> From: "David Feuer" <david.feuer at gmail.com>
> Date: Jan 22, 2018 1:42 PM
> Subject: Re: generalized IntMap - IntegerMap or IntegralMap
> To: "Oliver Charles" <ollie at ocharles.org.uk>
> Cc:
>
> That would help, in theory. But backpack is a bleeding-edge experimental GHC
> feature, and containers has a long history of striving for relative
> portability. So for now we need to stick to CPP and whatever other
> widely-available preprocessors we want.
>
> On Jan 22, 2018 1:38 PM, "Oliver Charles" <ollie at ocharles.org.uk> wrote:
>>
>> Would backpack be at all useful here? Seems you want to parameterise the
>> map by choice of numeric type.
>>
>> On 22 Jan 2018 3:59 pm, "David Feuer" <david.feuer at gmail.com> wrote:
>>>
>>> I wish I knew. There are some loose ends that need to be tied up and
>>> unfortunately I have no sense of whether that's happening.
>>>
>>> On Jan 22, 2018 10:54 AM, "Joachim Breitner" <mail at joachim-breitner.de>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Am Montag, den 22.01.2018, 04:05 -0500 schrieb David Feuer:
>>>> > Jonathan S. has been working (on and off) on a wholesale replacement
>>>> > for IntMap.
>>>>
>>>> what is the plan here? I am currently in the process of formally
>>>> verifying IntSet (and later IntMap), so I am curious about what is
>>>> going to change here.
>>>>
>>>> Cheers,
>>>> Joachim
>>>>
>>>> --
>>>> Joachim Breitner
>>>>   mail at joachim-breitner.de
>>>>   http://www.joachim-breitner.de/
>>>>
>>>> _______________________________________________
>>>> 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
>

From matt at m-renaud.com  Wed Jan 24 02:14:39 2018
From: matt at m-renaud.com (Matt Renaud)
Date: Tue, 23 Jan 2018 18:14:39 -0800
Subject: Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
Message-ID: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>

*What*

*====*

Rename unordered-container's Data.HashMap.lookupDefault
<https://hackage.haskell.org/package/unordered-containers-0.2.8.0/docs/Data-HashMap-Strict.html#v:lookupDefault>
to
findWithDefault.

findWithDefault :: (Eq k, Hashable k) => v -> k -> HashMap k v -> v

Note: There are no functionality changes, this is purely a rename.


*Why*
*===*

This aligns the Data.HashMap API with containers' Data.Map.findWithDefault
<https://hackage.haskell.org/package/containers-0.5.11.0/docs/Data-Map-Strict.html#v:findWithDefault>
.

Data.Map.findWithDefault :: Ord k => a -> k -> Map k a -> a

The map APIs provided by the two packages are *almost* drop in replacement
compatible if you aren't using any of the implementation specific functions
(like ordering based functions from Data.Map), this change brings us one
step closer.

API consistency reduces the cognitive overhead when learning a new package.
Having to learn different function names for the same functionality
depending on which "map" implementation you're using is a poor developer
experience.

We chose the containers' name findWithDefault over unordered-containers'
lookupDefault for two reasons:

   1. Existing lookupX functions returns a Maybe value, while findX
   functions return a non-wrapped value.
   2. The containers package ships with GHC and is a "core" package.


*Pros:*
*-----*

- Consistent API between different "map" implementations (Data.Map,
Data.IntMap, Data.HashMap). This makes switching implementations an import
change.
- Naming matches other similar functions (lookupX return Maybe-wrapped
values)

*Cons:*
*-----*

- API change requires users to update their code
  + unordered-containers has A LOT of users: 358815 total (13325 in the
last 30 days)


*How*
*===*

https://github.com/tibbe/unordered-containers/pull/176/commits/152f8818ee13dacb370e49b904edc4c1a4c8f87b

*Code Changes:*
*-------------*

- Rename the function in Data.HashMap.Base (and expose it from Strict and
Lazy modules)
- Make lookupDefault an INLINE alias of findWithDefault
- Add DEPRECATION notice to lookupDefault
- Bump unordered-containers version to 0.2.9.0


*Migration - Option 1:*

*---------------------*

*- *Announce on Haskell communication channels (haskell-cafe@,
haskell-community@, #haskell on Twitter, Reddit thread, etc.)
- Users of unordered-containers >= 0.2.9.0 receive warning about deprecated
function
- Code can be updated by find and replace: s/lookupDefault/findWithDefault/
- lookupDefault with deprecation notice remains for 1 year (subject to
change)
- after 1 year the lookupDefault function is removed, unordered-containers
version bumped to 0.3.0.0 (major version bump due to breaking change)

*Migration - Option 2:*

*---------------------*

- Announce on Haskell communication channels (haskell-cafe@,
haskell-community@, #haskell on Twitter, Reddit thread, etc.)
- Users of unordered-containers >= 0.2.9.0 receive warning about deprecated
function
- Code can be updated by find and replace: s/lookupDefault/findWithDefault/
- lookupDefault function is never removed


*Discussion: *
*===========*

I would like to get some comments on this proposal. In particular:
- Is the small API churn worth the increase in consistency?
- Should migration option 1 (completely remove the old function) or 2 (keep
old function indefinitely) be taken? We can punt on this and go with option
2 to start and revisit later if desired.

I hope a decision about the proposal can be reached by 2018-02-09. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180123/d592b00a/attachment.html>

From ivan.miljenovic at gmail.com  Wed Jan 24 02:59:11 2018
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Wed, 24 Jan 2018 13:59:11 +1100
Subject: Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
In-Reply-To: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
References: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
Message-ID: <CA+u6gbzWioybfWjwDLzH7mE9gpi7Av8eQUKP8xhHAN7bC+wV4g@mail.gmail.com>

On 24 January 2018 at 13:14, Matt Renaud <matt at m-renaud.com> wrote:
> What
> ====
>
> Rename unordered-container's Data.HashMap.lookupDefault to findWithDefault.
>
> findWithDefault :: (Eq k, Hashable k) => v -> k -> HashMap k v -> v
>
> Note: There are no functionality changes, this is purely a rename.
>
>
> Why
> ===
>
> This aligns the Data.HashMap API with containers' Data.Map.findWithDefault.
>
> Data.Map.findWithDefault :: Ord k => a -> k -> Map k a -> a
>
> The map APIs provided by the two packages are almost drop in replacement
> compatible if you aren't using any of the implementation specific functions
> (like ordering based functions from Data.Map), this change brings us one
> step closer.
>
> API consistency reduces the cognitive overhead when learning a new package.
> Having to learn different function names for the same functionality
> depending on which "map" implementation you're using is a poor developer
> experience.
>
> We chose the containers' name findWithDefault over unordered-containers'
> lookupDefault for two reasons:
>
> Existing lookupX functions returns a Maybe value, while findX functions
> return a non-wrapped value.
> The containers package ships with GHC and is a "core" package.
>
>
> Pros:
> -----
>
> - Consistent API between different "map" implementations (Data.Map,
> Data.IntMap, Data.HashMap). This makes switching implementations an import
> change.
> - Naming matches other similar functions (lookupX return Maybe-wrapped
> values)
>
> Cons:
> -----
>
> - API change requires users to update their code
>   + unordered-containers has A LOT of users: 358815 total (13325 in the last
> 30 days)
>
>
> How
> ===
>
> https://github.com/tibbe/unordered-containers/pull/176/commits/152f8818ee13dacb370e49b904edc4c1a4c8f87b
>
> Code Changes:
> -------------
>
> - Rename the function in Data.HashMap.Base (and expose it from Strict and
> Lazy modules)
> - Make lookupDefault an INLINE alias of findWithDefault
> - Add DEPRECATION notice to lookupDefault
> - Bump unordered-containers version to 0.2.9.0
>
>
> Migration - Option 1:
> ---------------------
>
> - Announce on Haskell communication channels (haskell-cafe@,
> haskell-community@, #haskell on Twitter, Reddit thread, etc.)
> - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated
> function
> - Code can be updated by find and replace: s/lookupDefault/findWithDefault/
> - lookupDefault with deprecation notice remains for 1 year (subject to
> change)
> - after 1 year the lookupDefault function is removed, unordered-containers
> version bumped to 0.3.0.0 (major version bump due to breaking change)
>
> Migration - Option 2:
> ---------------------
>
> - Announce on Haskell communication channels (haskell-cafe@,
> haskell-community@, #haskell on Twitter, Reddit thread, etc.)
> - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated
> function
> - Code can be updated by find and replace: s/lookupDefault/findWithDefault/
> - lookupDefault function is never removed
>
>
> Discussion:
> ===========
>
> I would like to get some comments on this proposal. In particular:
> - Is the small API churn worth the increase in consistency?
> - Should migration option 1 (completely remove the old function) or 2 (keep
> old function indefinitely) be taken? We can punt on this and go with option
> 2 to start and revisit later if desired.
>
> I hope a decision about the proposal can be reached by 2018-02-09. Thanks!

I prefer Option 1, but I think we need a release _without_ DEPRECATION
first, and then it can be added to lookupDefault (which currently
requires a major version bump per the PVP, though this might be
changing: https://github.com/haskell/pvp/issues/12 )

Whether this is worth it though is another story; until/unless we get
Backpack support on containers and unordered-containers (which also
requires adding a lot more functionality to the latter last I checked)
I think it's OK that they use different names.

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

From matt at m-renaud.com  Wed Jan 24 03:17:50 2018
From: matt at m-renaud.com (Matt Renaud)
Date: Tue, 23 Jan 2018 19:17:50 -0800
Subject: Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
In-Reply-To: <CA+u6gbzWioybfWjwDLzH7mE9gpi7Av8eQUKP8xhHAN7bC+wV4g@mail.gmail.com>
References: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
 <CA+u6gbzWioybfWjwDLzH7mE9gpi7Av8eQUKP8xhHAN7bC+wV4g@mail.gmail.com>
Message-ID: <CACxDEQG=w1n7DQvH1_q=XPfC0_0G2TTuCd1f62KDV=9jYM5Jag@mail.gmail.com>

Thanks for the input!

> I think we need a release _without_ DEPRECATION first...though this might
be changing

Either works for me. Personally I'd like it to be removed eventually but I
anticipate the timeline for that will be long, in which case having a minor
release that doesn't deprecate it to start doesn't seem like it would cause
any harm. Then we can wait until the PVP decision is worked out.

> until/unless we get Backpack support on containers and
unordered-containers

Yeah, this would make it a requirement that they share the same name, in
the meantime its unfortunate that they don't have the same name. Obviously
an extreme, but imagine if "fmap" was called something different by every
functor instance :P Since the migration for users is very straightforward
I'd argue the cost is pretty low to increase consistency.


On Tue, Jan 23, 2018 at 6:59 PM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> On 24 January 2018 at 13:14, Matt Renaud <matt at m-renaud.com> wrote:
> > What
> > ====
> >
> > Rename unordered-container's Data.HashMap.lookupDefault to
> findWithDefault.
> >
> > findWithDefault :: (Eq k, Hashable k) => v -> k -> HashMap k v -> v
> >
> > Note: There are no functionality changes, this is purely a rename.
> >
> >
> > Why
> > ===
> >
> > This aligns the Data.HashMap API with containers'
> Data.Map.findWithDefault.
> >
> > Data.Map.findWithDefault :: Ord k => a -> k -> Map k a -> a
> >
> > The map APIs provided by the two packages are almost drop in replacement
> > compatible if you aren't using any of the implementation specific
> functions
> > (like ordering based functions from Data.Map), this change brings us one
> > step closer.
> >
> > API consistency reduces the cognitive overhead when learning a new
> package.
> > Having to learn different function names for the same functionality
> > depending on which "map" implementation you're using is a poor developer
> > experience.
> >
> > We chose the containers' name findWithDefault over unordered-containers'
> > lookupDefault for two reasons:
> >
> > Existing lookupX functions returns a Maybe value, while findX functions
> > return a non-wrapped value.
> > The containers package ships with GHC and is a "core" package.
> >
> >
> > Pros:
> > -----
> >
> > - Consistent API between different "map" implementations (Data.Map,
> > Data.IntMap, Data.HashMap). This makes switching implementations an
> import
> > change.
> > - Naming matches other similar functions (lookupX return Maybe-wrapped
> > values)
> >
> > Cons:
> > -----
> >
> > - API change requires users to update their code
> >   + unordered-containers has A LOT of users: 358815 total (13325 in the
> last
> > 30 days)
> >
> >
> > How
> > ===
> >
> > https://github.com/tibbe/unordered-containers/pull/176/commits/
> 152f8818ee13dacb370e49b904edc4c1a4c8f87b
> >
> > Code Changes:
> > -------------
> >
> > - Rename the function in Data.HashMap.Base (and expose it from Strict and
> > Lazy modules)
> > - Make lookupDefault an INLINE alias of findWithDefault
> > - Add DEPRECATION notice to lookupDefault
> > - Bump unordered-containers version to 0.2.9.0
> >
> >
> > Migration - Option 1:
> > ---------------------
> >
> > - Announce on Haskell communication channels (haskell-cafe@,
> > haskell-community@, #haskell on Twitter, Reddit thread, etc.)
> > - Users of unordered-containers >= 0.2.9.0 receive warning about
> deprecated
> > function
> > - Code can be updated by find and replace: s/lookupDefault/
> findWithDefault/
> > - lookupDefault with deprecation notice remains for 1 year (subject to
> > change)
> > - after 1 year the lookupDefault function is removed,
> unordered-containers
> > version bumped to 0.3.0.0 (major version bump due to breaking change)
> >
> > Migration - Option 2:
> > ---------------------
> >
> > - Announce on Haskell communication channels (haskell-cafe@,
> > haskell-community@, #haskell on Twitter, Reddit thread, etc.)
> > - Users of unordered-containers >= 0.2.9.0 receive warning about
> deprecated
> > function
> > - Code can be updated by find and replace: s/lookupDefault/
> findWithDefault/
> > - lookupDefault function is never removed
> >
> >
> > Discussion:
> > ===========
> >
> > I would like to get some comments on this proposal. In particular:
> > - Is the small API churn worth the increase in consistency?
> > - Should migration option 1 (completely remove the old function) or 2
> (keep
> > old function indefinitely) be taken? We can punt on this and go with
> option
> > 2 to start and revisit later if desired.
> >
> > I hope a decision about the proposal can be reached by 2018-02-09.
> Thanks!
>
> I prefer Option 1, but I think we need a release _without_ DEPRECATION
> first, and then it can be added to lookupDefault (which currently
> requires a major version bump per the PVP, though this might be
> changing: https://github.com/haskell/pvp/issues/12 )
>
> Whether this is worth it though is another story; until/unless we get
> Backpack support on containers and unordered-containers (which also
> requires adding a lot more functionality to the latter last I checked)
> I think it's OK that they use different names.
>
> --
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com
> http://IvanMiljenovic.wordpress.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180123/cca4a157/attachment-0001.html>

From lemming at henning-thielemann.de  Wed Jan 24 07:11:33 2018
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 24 Jan 2018 08:11:33 +0100 (CET)
Subject: Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
In-Reply-To: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
References: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1801240808450.4373@sputnik>


On Tue, 23 Jan 2018, Matt Renaud wrote:

> Cons:
> -----
> 
> - API change requires users to update their code
>   + unordered-containers has A LOT of users: 358815 total (13325 in the last 30 days)

A better measure are certainly the reverse package dependencies:
    https://www.stackage.org/package/unordered-containers

There are almost 1000 packages that import unordered-containers, still 
quite a lot!

> Migration - Option 1:
> ---------------------
> 
> - Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit
> thread, etc.)
> - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function
> - Code can be updated by find and replace: s/lookupDefault/findWithDefault/
> - lookupDefault with deprecation notice remains for 1 year (subject to change)
> - after 1 year the lookupDefault function is removed, unordered-containers version bumped to 0.3.0.0 (major
> version bump due to breaking change)

I'd say 1 year is too short. There is no need to remove the function 
quickly. I'd vote for adding a deprecation warning soon, but then keep the 
function until the next larger API overhaul or say, for five years or a 
decade.

From andreas.abel at ifi.lmu.de  Wed Jan 24 14:25:49 2018
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Wed, 24 Jan 2018 15:25:49 +0100
Subject: Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
In-Reply-To: <alpine.DEB.2.20.1801240808450.4373@sputnik>
References: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
 <alpine.DEB.2.20.1801240808450.4373@sputnik>
Message-ID: <f9dbcb71-4456-3e16-9474-81be5794dfa8@ifi.lmu.de>

 > I'd say 1 year is too short. There is no need to remove the function
 > quickly. I'd vote for adding a deprecation warning soon, but then keep
 > the function until the next larger API overhaul or say, for five years
 > or a decade.

+1.

Yes.

On 24.01.2018 08:11, Henning Thielemann wrote:
> 
> On Tue, 23 Jan 2018, Matt Renaud wrote:
> 
>> Cons:
>> -----
>>
>> - API change requires users to update their code
>>   + unordered-containers has A LOT of users: 358815 total (13325 in 
>> the last 30 days)
> 
> A better measure are certainly the reverse package dependencies:
>     https://www.stackage.org/package/unordered-containers
> 
> There are almost 1000 packages that import unordered-containers, still 
> quite a lot!
> 
>> Migration - Option 1:
>> ---------------------
>>
>> - Announce on Haskell communication channels (haskell-cafe@, 
>> haskell-community@, #haskell on Twitter, Reddit
>> thread, etc.)
>> - Users of unordered-containers >= 0.2.9.0 receive warning about 
>> deprecated function
>> - Code can be updated by find and replace: 
>> s/lookupDefault/findWithDefault/
>> - lookupDefault with deprecation notice remains for 1 year (subject to 
>> change)
>> - after 1 year the lookupDefault function is removed, 
>> unordered-containers version bumped to 0.3.0.0 (major
>> version bump due to breaking change)
> 
> I'd say 1 year is too short. There is no need to remove the function 
> quickly. I'd vote for adding a deprecation warning soon, but then keep 
> the function until the next larger API overhaul or say, for five years 
> or a decade.
> 
> 
> _______________________________________________
> 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://www.cse.chalmers.se/~abela/

From matt at m-renaud.com  Wed Jan 24 15:59:49 2018
From: matt at m-renaud.com (Matt Renaud)
Date: Wed, 24 Jan 2018 07:59:49 -0800
Subject: Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
In-Reply-To: <f9dbcb71-4456-3e16-9474-81be5794dfa8@ifi.lmu.de>
References: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
 <alpine.DEB.2.20.1801240808450.4373@sputnik>
 <f9dbcb71-4456-3e16-9474-81be5794dfa8@ifi.lmu.de>
Message-ID: <CACxDEQGW3o8w5ipNJmES0YVSPHx0XiUedLDPVg=++w_hdZNcHg@mail.gmail.com>

> keep the function until the next larger API overhaul or say, for five
years or a decade.

That sounds good to me, I wasn't sure how long is reasonable to wait after
deprecating an API before removing it.

On Wed, Jan 24, 2018 at 6:25 AM, Andreas Abel <andreas.abel at ifi.lmu.de>
wrote:

> > I'd say 1 year is too short. There is no need to remove the function
> > quickly. I'd vote for adding a deprecation warning soon, but then keep
> > the function until the next larger API overhaul or say, for five years
> > or a decade.
>
> +1.
>
> Yes.
>
>
> On 24.01.2018 08:11, Henning Thielemann wrote:
>
>>
>> On Tue, 23 Jan 2018, Matt Renaud wrote:
>>
>> Cons:
>>> -----
>>>
>>> - API change requires users to update their code
>>>   + unordered-containers has A LOT of users: 358815 total (13325 in the
>>> last 30 days)
>>>
>>
>> A better measure are certainly the reverse package dependencies:
>>     https://www.stackage.org/package/unordered-containers
>>
>> There are almost 1000 packages that import unordered-containers, still
>> quite a lot!
>>
>> Migration - Option 1:
>>> ---------------------
>>>
>>> - Announce on Haskell communication channels (haskell-cafe@,
>>> haskell-community@, #haskell on Twitter, Reddit
>>> thread, etc.)
>>> - Users of unordered-containers >= 0.2.9.0 receive warning about
>>> deprecated function
>>> - Code can be updated by find and replace: s/lookupDefault/findWithDefaul
>>> t/
>>> - lookupDefault with deprecation notice remains for 1 year (subject to
>>> change)
>>> - after 1 year the lookupDefault function is removed,
>>> unordered-containers version bumped to 0.3.0.0 (major
>>> version bump due to breaking change)
>>>
>>
>> I'd say 1 year is too short. There is no need to remove the function
>> quickly. I'd vote for adding a deprecation warning soon, but then keep the
>> function until the next larger API overhaul or say, for five years or a
>> decade.
>>
>>
>> _______________________________________________
>> 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://www.cse.chalmers.se/~abela/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180124/957230c2/attachment.html>

From amindfv at gmail.com  Wed Jan 24 23:25:49 2018
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Wed, 24 Jan 2018 18:25:49 -0500
Subject: Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
In-Reply-To: <f9dbcb71-4456-3e16-9474-81be5794dfa8@ifi.lmu.de>
References: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
 <alpine.DEB.2.20.1801240808450.4373@sputnik>
 <f9dbcb71-4456-3e16-9474-81be5794dfa8@ifi.lmu.de>
Message-ID: <70557B92-B275-4617-9EA1-536BF472E889@gmail.com>

Doesn't quickly adding a deprecation warning break building any of those 1000+ packages with -Werror?

I'd support adding the new function, but am very reluctant to force any quick changes.

Tom


> El 24 ene 2018, a las 09:25, Andreas Abel <andreas.abel at ifi.lmu.de> escribió:
> 
> > I'd say 1 year is too short. There is no need to remove the function
> > quickly. I'd vote for adding a deprecation warning soon, but then keep
> > the function until the next larger API overhaul or say, for five years
> > or a decade.
> 
> +1.
> 
> Yes.
> 
>> On 24.01.2018 08:11, Henning Thielemann wrote:
>>> On Tue, 23 Jan 2018, Matt Renaud wrote:
>>> Cons:
>>> -----
>>> 
>>> - API change requires users to update their code
>>>   + unordered-containers has A LOT of users: 358815 total (13325 in the last 30 days)
>> A better measure are certainly the reverse package dependencies:
>>    https://www.stackage.org/package/unordered-containers
>> There are almost 1000 packages that import unordered-containers, still quite a lot!
>>> Migration - Option 1:
>>> ---------------------
>>> 
>>> - Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit
>>> thread, etc.)
>>> - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function
>>> - Code can be updated by find and replace: s/lookupDefault/findWithDefault/
>>> - lookupDefault with deprecation notice remains for 1 year (subject to change)
>>> - after 1 year the lookupDefault function is removed, unordered-containers version bumped to 0.3.0.0 (major
>>> version bump due to breaking change)
>> I'd say 1 year is too short. There is no need to remove the function quickly. I'd vote for adding a deprecation warning soon, but then keep the function until the next larger API overhaul or say, for five years or a decade.
>> _______________________________________________
>> 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://www.cse.chalmers.se/~abela/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From matt at m-renaud.com  Wed Jan 24 23:59:44 2018
From: matt at m-renaud.com (Matt Renaud)
Date: Wed, 24 Jan 2018 15:59:44 -0800
Subject: Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
In-Reply-To: <70557B92-B275-4617-9EA1-536BF472E889@gmail.com>
References: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
 <alpine.DEB.2.20.1801240808450.4373@sputnik>
 <f9dbcb71-4456-3e16-9474-81be5794dfa8@ifi.lmu.de>
 <70557B92-B275-4617-9EA1-536BF472E889@gmail.com>
Message-ID: <CACxDEQHBqq_1wuiv3-dV4s6=BaE+7j4t52Cz98CL4J4EO5RAuw@mail.gmail.com>

> Doesn't quickly adding a deprecation warning break building any of those
1000+ packages with -Werror?

It appears that https://github.com/haskell/pvp/issues/12 is close to being
resolved[1], and as hvr mentioned Hackage already prevents packages with
-Werror from being uploaded, so this shouldn't be an issue for packages
already uploaded. But yes, if someone is using unordered-containers and
building locally with -Werror then the build would fail.

That being said, if the plan is to deprecate it then I don't think there's
a better way than marking it DEPRECATED. We could go with a "soft"
deprecation--remove function comments and replace with "This function is
deprecated, use findWithDefault" and make some announcements--but I doubt
many people would act on that so it would just be kicking the can down the
road.

> I'd support adding the new function, but am very reluctant to force any
quick changes.

Glad to hear! It would be nice if there was a way of getting information
about how often this particular function was used so we could get a better
estimate of how many packages would truly be affected. And I completely
agreed that we should do everything we can to not break people's builds,
but hopefully not at the expense of improving APIs.

[1] https://github.com/haskell/pvp/pull/18

On Wed, Jan 24, 2018 at 3:25 PM, <amindfv at gmail.com> wrote:

> Doesn't quickly adding a deprecation warning break building any of those
> 1000+ packages with -Werror?
>
> I'd support adding the new function, but am very reluctant to force any
> quick changes.
>
> Tom
>
>
> > El 24 ene 2018, a las 09:25, Andreas Abel <andreas.abel at ifi.lmu.de>
> escribió:
> >
> > > I'd say 1 year is too short. There is no need to remove the function
> > > quickly. I'd vote for adding a deprecation warning soon, but then keep
> > > the function until the next larger API overhaul or say, for five years
> > > or a decade.
> >
> > +1.
> >
> > Yes.
> >
> >> On 24.01.2018 08:11, Henning Thielemann wrote:
> >>> On Tue, 23 Jan 2018, Matt Renaud wrote:
> >>> Cons:
> >>> -----
> >>>
> >>> - API change requires users to update their code
> >>>   + unordered-containers has A LOT of users: 358815 total (13325 in
> the last 30 days)
> >> A better measure are certainly the reverse package dependencies:
> >>    https://www.stackage.org/package/unordered-containers
> >> There are almost 1000 packages that import unordered-containers, still
> quite a lot!
> >>> Migration - Option 1:
> >>> ---------------------
> >>>
> >>> - Announce on Haskell communication channels (haskell-cafe@,
> haskell-community@, #haskell on Twitter, Reddit
> >>> thread, etc.)
> >>> - Users of unordered-containers >= 0.2.9.0 receive warning about
> deprecated function
> >>> - Code can be updated by find and replace: s/lookupDefault/
> findWithDefault/
> >>> - lookupDefault with deprecation notice remains for 1 year (subject to
> change)
> >>> - after 1 year the lookupDefault function is removed,
> unordered-containers version bumped to 0.3.0.0 (major
> >>> version bump due to breaking change)
> >> I'd say 1 year is too short. There is no need to remove the function
> quickly. I'd vote for adding a deprecation warning soon, but then keep the
> function until the next larger API overhaul or say, for five years or a
> decade.
> >> _______________________________________________
> >> 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://www.cse.chalmers.se/~abela/
> > _______________________________________________
> > 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/20180124/76bafe73/attachment-0001.html>

From david.feuer at gmail.com  Thu Jan 25 00:27:50 2018
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 24 Jan 2018 19:27:50 -0500
Subject: Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
In-Reply-To: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
References: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
Message-ID: <CAMgWh9sWZTrzWxHUcULQF+=666pzD69riy3EV5p2RJGNteCRzA@mail.gmail.com>

I'm wondering if we should ultimately get rid of that function altogether,
from both packages. From an API design standpoint, it's kind of silly,
because

    findWithDefault d k m =
       fromMaybe d (lookup k m)

At present, there's a slight performance penalty to doing it that way. I
wonder if we can squash that now that GHC has unboxed sums.

    lookup# :: ... => k -> m a -> (# (# #) | a #)
    lookup k m = case lookup# k m of
      (# _ | #) -> Nothing
      (# | a #) -> Just a

Now case-of-case will get rid of the extra Maybe.


On Jan 23, 2018 9:15 PM, "Matt Renaud" <matt at m-renaud.com> wrote:

*What*

*====*

Rename unordered-container's Data.HashMap.lookupDefault
<https://hackage.haskell.org/package/unordered-containers-0.2.8.0/docs/Data-HashMap-Strict.html#v:lookupDefault>
to
findWithDefault.

findWithDefault :: (Eq k, Hashable k) => v -> k -> HashMap k v -> v

Note: There are no functionality changes, this is purely a rename.


*Why*
*===*

This aligns the Data.HashMap API with containers' Data.Map.findWithDefault
<https://hackage.haskell.org/package/containers-0.5.11.0/docs/Data-Map-Strict.html#v:findWithDefault>
.

Data.Map.findWithDefault :: Ord k => a -> k -> Map k a -> a

The map APIs provided by the two packages are *almost* drop in replacement
compatible if you aren't using any of the implementation specific functions
(like ordering based functions from Data.Map), this change brings us one
step closer.

API consistency reduces the cognitive overhead when learning a new package.
Having to learn different function names for the same functionality
depending on which "map" implementation you're using is a poor developer
experience.

We chose the containers' name findWithDefault over unordered-containers'
lookupDefault for two reasons:

   1. Existing lookupX functions returns a Maybe value, while findX
   functions return a non-wrapped value.
   2. The containers package ships with GHC and is a "core" package.


*Pros:*
*-----*

- Consistent API between different "map" implementations (Data.Map,
Data.IntMap, Data.HashMap). This makes switching implementations an import
change.
- Naming matches other similar functions (lookupX return Maybe-wrapped
values)

*Cons:*
*-----*

- API change requires users to update their code
  + unordered-containers has A LOT of users: 358815 total (13325 in the
last 30 days)


*How*
*===*

https://github.com/tibbe/unordered-containers/pull/176/commits/
152f8818ee13dacb370e49b904edc4c1a4c8f87b

*Code Changes:*
*-------------*

- Rename the function in Data.HashMap.Base (and expose it from Strict and
Lazy modules)
- Make lookupDefault an INLINE alias of findWithDefault
- Add DEPRECATION notice to lookupDefault
- Bump unordered-containers version to 0.2.9.0


*Migration - Option 1:*

*---------------------*

*- *Announce on Haskell communication channels (haskell-cafe@,
haskell-community@, #haskell on Twitter, Reddit thread, etc.)
- Users of unordered-containers >= 0.2.9.0 receive warning about deprecated
function
- Code can be updated by find and replace: s/lookupDefault/findWithDefault/
- lookupDefault with deprecation notice remains for 1 year (subject to
change)
- after 1 year the lookupDefault function is removed, unordered-containers
version bumped to 0.3.0.0 (major version bump due to breaking change)

*Migration - Option 2:*

*---------------------*

- Announce on Haskell communication channels (haskell-cafe@,
haskell-community@, #haskell on Twitter, Reddit thread, etc.)
- Users of unordered-containers >= 0.2.9.0 receive warning about deprecated
function
- Code can be updated by find and replace: s/lookupDefault/findWithDefault/
- lookupDefault function is never removed


*Discussion: *
*===========*

I would like to get some comments on this proposal. In particular:
- Is the small API churn worth the increase in consistency?
- Should migration option 1 (completely remove the old function) or 2 (keep
old function indefinitely) be taken? We can punt on this and go with option
2 to start and revisit later if desired.

I hope a decision about the proposal can be reached by 2018-02-09. Thanks!





_______________________________________________
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/20180124/1a5e58d9/attachment.html>

From andrew.lelechenko at gmail.com  Sat Jan 27 21:30:47 2018
From: andrew.lelechenko at gmail.com (andrew.lelechenko at gmail.com)
Date: Sat, 27 Jan 2018 21:30:47 +0000
Subject: Taking over maintainership of exact-pi
In-Reply-To: <CACruqwQc3e38Q6qYGrgZDLnrD4oM-b7Th92r9Nv1NycFbs44bA@mail.gmail.com>
References: <2A8272FA-F807-4C4E-84C8-E6139A41DBDF@gmail.com>
 <CACruqwQc3e38Q6qYGrgZDLnrD4oM-b7Th92r9Nv1NycFbs44bA@mail.gmail.com>
Message-ID: <CC0D314E-6B32-4B8A-A206-4E3891D7F21C@gmail.com>

Hi Douglas,

How is it going?

Since you are really busy (a new baby is a big deal, congratulations) to do these changes, I’d be glad to apply them, if you are happy to add me (username Bodigrim) as a maintainer at http://hackage.haskell.org/package/exact-pi/maintainers Feel free to kick me out afterwards. 

Best regards,
Andrew

> 20 янв. 2018 г., в 19:18, Douglas McClean <douglas.mcclean at gmail.com> написал(а):
> 
> Sorry everyone, new baby. Will review PR by end of weekend.
> 
>> On Jan 20, 2018 1:45 PM, "Andrew Lelechenko" <andrew.lelechenko at gmail.com> wrote:
>> I would like to take over `exact-pi` package (https://hackage.haskell.org/package/exact-pi).
>> Unfortunately, the package became incompatible with upcoming GHC 8.4 and needs an upgrade. The relevant pull request (https://github.com/dmcclean/exact-pi/pull/5), prepared by @konn, has been open for a month without response. I also tried to reach its maintainer Douglas McClean (cced) by email, but have not heard back.
>> 
>> I am so interested in upgrading `exact-pi`, because it is a dependency of my package `arithmoi`.
>> 
>> —
>> Best regards,
>> Andrew
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180127/f3cf91b1/attachment.html>

From merijn at inconsistent.nl  Sun Jan 28 11:26:22 2018
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Sun, 28 Jan 2018 12:26:22 +0100
Subject: Crazy suggestion for dealing with the naming disaster that is
 ByteString
Message-ID: <77C64EAE-2824-4AFC-8BD0-E502DDFA57FD@inconsistent.nl>

Ok, so every so often I've seen people bring up that we really should've called ByteString type Bytes to avoid a whole lot of newbie confusion, but we can't change it now, because it'd break everything.

But would it really break everything? What's to stop us from creating a new package "bytes" which is just a copy of the bytestring source with ByteString renamed to Bytes, then turning the bytestring package into a shim that re-exports all of the bytes package with an added type alias "type ByteString = Bytes".

Anything depending on bytestring right now should just compile as is. Sure, we'd probably be stuck with bytestring as shim package for the next 10 years or so while the ecosystem slowly transitions to "bytes", but maintaining a shim package like that should be near zero work and we'd avoid being stuck with this terribly misleading name forever.

Cheers,
Merijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180128/3d6dca44/attachment.sig>

From cma at bitemyapp.com  Sun Jan 28 13:51:04 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Sun, 28 Jan 2018 07:51:04 -0600
Subject: Crazy suggestion for dealing with the naming disaster that is
 ByteString
In-Reply-To: <77C64EAE-2824-4AFC-8BD0-E502DDFA57FD@inconsistent.nl>
References: <77C64EAE-2824-4AFC-8BD0-E502DDFA57FD@inconsistent.nl>
Message-ID: <1609AFFE-79B5-4649-8959-282EAC569658@bitemyapp.com>

I’d love this as I am getting tired of explaining “it’s a string of bytes, not a string-as-in-text.”

> On Jan 28, 2018, at 5:26 AM, Merijn Verstraaten <merijn at inconsistent.nl> wrote:
> 
> Ok, so every so often I've seen people bring up that we really should've called ByteString type Bytes to avoid a whole lot of newbie confusion, but we can't change it now, because it'd break everything.
> 
> But would it really break everything? What's to stop us from creating a new package "bytes" which is just a copy of the bytestring source with ByteString renamed to Bytes, then turning the bytestring package into a shim that re-exports all of the bytes package with an added type alias "type ByteString = Bytes".
> 
> Anything depending on bytestring right now should just compile as is. Sure, we'd probably be stuck with bytestring as shim package for the next 10 years or so while the ecosystem slowly transitions to "bytes", but maintaining a shim package like that should be near zero work and we'd avoid being stuck with this terribly misleading name forever.
> 
> Cheers,
> Merijn
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From lanablack at amok.cc  Sun Jan 28 15:12:50 2018
From: lanablack at amok.cc (Lana Black)
Date: Sun, 28 Jan 2018 15:12:50 +0000
Subject: Crazy suggestion for dealing with the naming disaster that is
 ByteString
In-Reply-To: <1609AFFE-79B5-4649-8959-282EAC569658@bitemyapp.com>
References: <77C64EAE-2824-4AFC-8BD0-E502DDFA57FD@inconsistent.nl>
 <1609AFFE-79B5-4649-8959-282EAC569658@bitemyapp.com>
Message-ID: <f4c29af0-e575-de4a-1361-99f1cdacbfda@amok.cc>

On 28/01/18 13:51, Christopher Allen wrote:
> I’d love this as I am getting tired of explaining “it’s a string of bytes, not a string-as-in-text.”
> 

B-b-but bytestring is a string-as-in-text too among other things. 
Otherwise we wouldn't have `instance IsString ByteString' or 
Data.ByteString.Char8 module.

I like the idea, but is it worth the hassle? Perhaps, as a start, 
someone could make "bytes" as a shim package with `type Bytes = 
ByteString' and all related functions re-exported, just to see how it 
goes. If the adoption rate turns out to be significant, bytes and 
bytestring packages could be swapped.

From lanablack at amok.cc  Sun Jan 28 15:24:04 2018
From: lanablack at amok.cc (Lana Black)
Date: Sun, 28 Jan 2018 15:24:04 +0000
Subject: Crazy suggestion for dealing with the naming disaster that is
 ByteString
In-Reply-To: <77C64EAE-2824-4AFC-8BD0-E502DDFA57FD@inconsistent.nl>
References: <77C64EAE-2824-4AFC-8BD0-E502DDFA57FD@inconsistent.nl>
Message-ID: <c792a46c-c89b-5da1-2fec-9386636e9b0f@amok.cc>

On 28/01/18 11:26, Merijn Verstraaten wrote:
> Ok, so every so often I've seen people bring up that we really should've called ByteString type Bytes to avoid a whole lot of newbie confusion, but we can't change it now, because it'd break everything.
> 
> But would it really break everything? What's to stop us from creating a new package "bytes" which is just a copy of the bytestring source with ByteString renamed to Bytes, then turning the bytestring package into a shim that re-exports all of the bytes package with an added type alias "type ByteString = Bytes".
> 
> Anything depending on bytestring right now should just compile as is. Sure, we'd probably be stuck with bytestring as shim package for the next 10 years or so while the ecosystem slowly transitions to "bytes", but maintaining a shim package like that should be near zero work and we'd avoid being stuck with this terribly misleading name forever.
> 

Just to add, there are two problems with this proposal. First, there 
already is a package named 'bytes' [1]. Second, renaming the type and 
adding a type alias will break all the instances for ByteString in other 
packages, because Haskell forbids instance declaration for type aliases 
unless TypeSynonymInstances extension is enabled.

[1]: http://hackage.haskell.org/package/bytes


From alois.cochard at gmail.com  Sun Jan 28 15:54:37 2018
From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=)
Date: Sun, 28 Jan 2018 16:54:37 +0100
Subject: Crazy suggestion for dealing with the naming disaster that is
 ByteString
In-Reply-To: <77C64EAE-2824-4AFC-8BD0-E502DDFA57FD@inconsistent.nl>
References: <77C64EAE-2824-4AFC-8BD0-E502DDFA57FD@inconsistent.nl>
Message-ID: <CAJHA+wpdc5BX59i_W-2gVicb1amic=mHsL1Vkbh-CmgzM0JTZQ@mail.gmail.com>

Hi,

Why do you think ByteString should be named Bytes?

Maybe I missed it but I don't see any motivation for the rename. I don't
see what is wrong with the current name.

Thanks

On 28 Jan 2018 12:27, "Merijn Verstraaten" <merijn at inconsistent.nl> wrote:

> Ok, so every so often I've seen people bring up that we really should've
> called ByteString type Bytes to avoid a whole lot of newbie confusion, but
> we can't change it now, because it'd break everything.
>
> But would it really break everything? What's to stop us from creating a
> new package "bytes" which is just a copy of the bytestring source with
> ByteString renamed to Bytes, then turning the bytestring package into a
> shim that re-exports all of the bytes package with an added type alias
> "type ByteString = Bytes".
>
> Anything depending on bytestring right now should just compile as is.
> Sure, we'd probably be stuck with bytestring as shim package for the next
> 10 years or so while the ecosystem slowly transitions to "bytes", but
> maintaining a shim package like that should be near zero work and we'd
> avoid being stuck with this terribly misleading name forever.
>
> Cheers,
> Merijn
>
> _______________________________________________
> 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/20180128/4ea9693f/attachment.html>

From mblazevic at stilo.com  Mon Jan 29 17:03:57 2018
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Mon, 29 Jan 2018 12:03:57 -0500
Subject: Name of 1-Tuple Data Type
In-Reply-To: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
References: <CABNC7eMQuNHF2r7ho502h3NG+W7Qv2nfdPQS-oZv8JfYgkVPXw@mail.gmail.com>
Message-ID: <d7d1e701-815a-1e86-0f2e-63b81217a0ee@stilo.com>

On 2018-01-17 06:46 PM, Andrew Martin wrote:
> Required background information: 
> https://ghc.haskell.org/trac/ghc/ticket/14673
+1 for Only, because it's short and already in use. It's also used by my 
own libraries 
(https://hackage.haskell.org/package/rank2classes-1.0.1/docs/Rank2.html#t:Only), 
so I wouldn't need to rename it. Selfish I know.


From matt at m-renaud.com  Tue Jan 30 02:09:55 2018
From: matt at m-renaud.com (Matt Renaud)
Date: Mon, 29 Jan 2018 18:09:55 -0800
Subject: Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
In-Reply-To: <CAMgWh9sWZTrzWxHUcULQF+=666pzD69riy3EV5p2RJGNteCRzA@mail.gmail.com>
References: <CACxDEQHOE0iDgWs4w168kX2KvyLJ1tDaSfSkXobKZZ4jq+cZbA@mail.gmail.com>
 <CAMgWh9sWZTrzWxHUcULQF+=666pzD69riy3EV5p2RJGNteCRzA@mail.gmail.com>
Message-ID: <CACxDEQEgVTMm0YZMi5+W-E0df1YVue_Wt4wdAENJ5e2MFBx5Yg@mail.gmail.com>

> I'm wondering if we should ultimately get rid of that function
altogether, from both packages

I'm on the fence about this one since its such a common operation, I
personally would be a little surprised if it wasn't part of the API. You're
right that it's not /that/ much code to write, but I imagine everyone will
end up writing their own findWithDefault in their codebase, I may be wrong
though.


On Wed, Jan 24, 2018 at 4:27 PM, David Feuer <david.feuer at gmail.com> wrote:

> I'm wondering if we should ultimately get rid of that function altogether,
> from both packages. From an API design standpoint, it's kind of silly,
> because
>
>     findWithDefault d k m =
>        fromMaybe d (lookup k m)
>
> At present, there's a slight performance penalty to doing it that way. I
> wonder if we can squash that now that GHC has unboxed sums.
>
>     lookup# :: ... => k -> m a -> (# (# #) | a #)
>     lookup k m = case lookup# k m of
>       (# _ | #) -> Nothing
>       (# | a #) -> Just a
>
> Now case-of-case will get rid of the extra Maybe.
>
>
> On Jan 23, 2018 9:15 PM, "Matt Renaud" <matt at m-renaud.com> wrote:
>
> *What*
>
> *====*
>
> Rename unordered-container's Data.HashMap.lookupDefault
> <https://hackage.haskell.org/package/unordered-containers-0.2.8.0/docs/Data-HashMap-Strict.html#v:lookupDefault> to
> findWithDefault.
>
> findWithDefault :: (Eq k, Hashable k) => v -> k -> HashMap k v -> v
>
> Note: There are no functionality changes, this is purely a rename.
>
>
> *Why*
> *===*
>
> This aligns the Data.HashMap API with containers' Data.Map.findWithDefault
> <https://hackage.haskell.org/package/containers-0.5.11.0/docs/Data-Map-Strict.html#v:findWithDefault>
> .
>
> Data.Map.findWithDefault :: Ord k => a -> k -> Map k a -> a
>
> The map APIs provided by the two packages are *almost* drop in
> replacement compatible if you aren't using any of the implementation
> specific functions (like ordering based functions from Data.Map), this
> change brings us one step closer.
>
> API consistency reduces the cognitive overhead when learning a new
> package. Having to learn different function names for the same
> functionality depending on which "map" implementation you're using is a
> poor developer experience.
>
> We chose the containers' name findWithDefault over unordered-containers'
> lookupDefault for two reasons:
>
>    1. Existing lookupX functions returns a Maybe value, while findX
>    functions return a non-wrapped value.
>    2. The containers package ships with GHC and is a "core" package.
>
>
> *Pros:*
> *-----*
>
> - Consistent API between different "map" implementations (Data.Map,
> Data.IntMap, Data.HashMap). This makes switching implementations an import
> change.
> - Naming matches other similar functions (lookupX return Maybe-wrapped
> values)
>
> *Cons:*
> *-----*
>
> - API change requires users to update their code
>   + unordered-containers has A LOT of users: 358815 total (13325 in the
> last 30 days)
>
>
> *How*
> *===*
>
> https://github.com/tibbe/unordered-containers/pull/176/commi
> ts/152f8818ee13dacb370e49b904edc4c1a4c8f87b
>
> *Code Changes:*
> *-------------*
>
> - Rename the function in Data.HashMap.Base (and expose it from Strict and
> Lazy modules)
> - Make lookupDefault an INLINE alias of findWithDefault
> - Add DEPRECATION notice to lookupDefault
> - Bump unordered-containers version to 0.2.9.0
>
>
> *Migration - Option 1:*
>
> *---------------------*
>
> *- *Announce on Haskell communication channels (haskell-cafe@,
> haskell-community@, #haskell on Twitter, Reddit thread, etc.)
> - Users of unordered-containers >= 0.2.9.0 receive warning about
> deprecated function
> - Code can be updated by find and replace: s/lookupDefault/findWithDefaul
> t/
> - lookupDefault with deprecation notice remains for 1 year (subject to
> change)
> - after 1 year the lookupDefault function is removed, unordered-containers
> version bumped to 0.3.0.0 (major version bump due to breaking change)
>
> *Migration - Option 2:*
>
> *---------------------*
>
> - Announce on Haskell communication channels (haskell-cafe@,
> haskell-community@, #haskell on Twitter, Reddit thread, etc.)
> - Users of unordered-containers >= 0.2.9.0 receive warning about
> deprecated function
> - Code can be updated by find and replace: s/lookupDefault/findWithDefaul
> t/
> - lookupDefault function is never removed
>
>
> *Discussion: *
> *===========*
>
> I would like to get some comments on this proposal. In particular:
> - Is the small API churn worth the increase in consistency?
> - Should migration option 1 (completely remove the old function) or 2
> (keep old function indefinitely) be taken? We can punt on this and go with
> option 2 to start and revisit later if desired.
>
> I hope a decision about the proposal can be reached by 2018-02-09. Thanks!
>
>
>
>
>
> _______________________________________________
> 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/20180129/345c8a7a/attachment.html>

From lysxia at gmail.com  Tue Jan 30 03:48:35 2018
From: lysxia at gmail.com (Li-yao Xia)
Date: Mon, 29 Jan 2018 22:48:35 -0500
Subject: Combinators for Show
Message-ID: <970f4452-cc3d-2f5f-2bcd-eece52ff24f7@gmail.com>

Hello libraries,

base contains a small combinator library for Read, but there doesn't 
seem to be a similar thing for Show. Offering a few more convenient 
helpers to avoid dealing with whitespace and especially precedence 
levels seems straightforward enough.

Is there an API somewhere that I missed? Has there been a 
proposal/discussion about this before? I'm ready to make one otherwise.

Li-yao

From ivan.miljenovic at gmail.com  Tue Jan 30 07:06:37 2018
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Tue, 30 Jan 2018 18:06:37 +1100
Subject: Combinators for Show
In-Reply-To: <970f4452-cc3d-2f5f-2bcd-eece52ff24f7@gmail.com>
References: <970f4452-cc3d-2f5f-2bcd-eece52ff24f7@gmail.com>
Message-ID: <CA+u6gbwTpa2BCJS1PB1kcJ3VyJL6u4tvVs5B_1xA5oTHsuYDug@mail.gmail.com>

On 30 January 2018 at 14:48, Li-yao Xia <lysxia at gmail.com> wrote:
> Hello libraries,
>
> base contains a small combinator library for Read, but there doesn't seem to
> be a similar thing for Show. Offering a few more convenient helpers to avoid
> dealing with whitespace and especially precedence levels seems
> straightforward enough.
>
> Is there an API somewhere that I missed? Has there been a
> proposal/discussion about this before? I'm ready to make one otherwise.

Have you looked at the ShowS-based methods? They tend to be a bit more
combinator-y (though they don't cover whitespace).  For example,
here's the Show instance for Data.Graph.Inductive.Tree:

instance (Show a, Show b) => Show (Gr a b) where
  showsPrec d g = showParen (d > 10) $
                    showString "mkGraph "
                    . shows (labNodes g)
                    . showString " "
                    . shows (labEdges g)

>
> Li-yao
> _______________________________________________
> 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 lysxia at gmail.com  Tue Jan 30 13:04:50 2018
From: lysxia at gmail.com (Li-yao Xia)
Date: Tue, 30 Jan 2018 08:04:50 -0500
Subject: Combinators for Show
In-Reply-To: <CA+u6gbwTpa2BCJS1PB1kcJ3VyJL6u4tvVs5B_1xA5oTHsuYDug@mail.gmail.com>
References: <970f4452-cc3d-2f5f-2bcd-eece52ff24f7@gmail.com>
 <CA+u6gbwTpa2BCJS1PB1kcJ3VyJL6u4tvVs5B_1xA5oTHsuYDug@mail.gmail.com>
Message-ID: <10eda21a-f855-912e-2df2-2baee3345b01@gmail.com>

On 01/30/2018 02:06 AM, Ivan Lazar Miljenovic wrote:
> On 30 January 2018 at 14:48, Li-yao Xia <lysxia at gmail.com> wrote:
>> Hello libraries,
>>
>> base contains a small combinator library for Read, but there doesn't seem to
>> be a similar thing for Show. Offering a few more convenient helpers to avoid
>> dealing with whitespace and especially precedence levels seems
>> straightforward enough.
>>
>> Is there an API somewhere that I missed? Has there been a
>> proposal/discussion about this before? I'm ready to make one otherwise.
> 
> Have you looked at the ShowS-based methods? They tend to be a bit more
> combinator-y (though they don't cover whitespace).  For example,
> here's the Show instance for Data.Graph.Inductive.Tree:
> 
> instance (Show a, Show b) => Show (Gr a b) where
>    showsPrec d g = showParen (d > 10) $
>                      showString "mkGraph "
>                      . shows (labNodes g)
>                      . showString " "
>                      . shows (labEdges g)


In fact, I meant that this API seems suboptimal. As you mentioned, we 
have to deal explicitly with spacing ("mkGraph ") and also precedence 
levels. It's not much but the UX could be streamlined further by hiding 
those details. (And now that I look at Text.Read again, we also have to 
deal with precedence there.)

Flip showsPrec,

     precShows :: a -> Int -> ShowS,

Hide its result type,

     type Doc = Int -> ShowS

Give a combinator for constructors,

     showCon :: String -> Doc
     showCon con _ = showString con

and one for function application,

     showApp :: Doc -> Doc -> Doc
     showApp f x d =
       showParen (d > appPrec)
         (f appPrec . showSpace . x  (appPrec + 1))
       where
         appPrec = 10

     infixl 8 `showApp`

An instance would thus look like

     ...
       precShows g =
         showCon "mkGraph"
           `showApp` precShows (labNodes g)
           `showApp` precShows (labEdges g)

There are also combinators for infix constructors and records to be 
written. These would cover the overwhelming majority of use cases where 
we must handwrite Show [citation needed].

What do you think of that? Doesn't that look better?

Li-yao

From oleg.grenrus at iki.fi  Tue Jan 30 13:29:00 2018
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Tue, 30 Jan 2018 15:29:00 +0200
Subject: Combinators for Show
In-Reply-To: <10eda21a-f855-912e-2df2-2baee3345b01@gmail.com>
References: <970f4452-cc3d-2f5f-2bcd-eece52ff24f7@gmail.com>
 <CA+u6gbwTpa2BCJS1PB1kcJ3VyJL6u4tvVs5B_1xA5oTHsuYDug@mail.gmail.com>
 <10eda21a-f855-912e-2df2-2baee3345b01@gmail.com>
Message-ID: <49630b8a-fec0-76e6-8998-80c35a0cf148@iki.fi>

We have `showsBinaryWith` [1]

    showsPrec d graph = showBinaryWith showsPrec showsPrec
        "mkGraph" d (labNodes graph) (labEdges g)

Unfortunately we don't have `showsBinary` to do:

    showsPrec d graph = showsBinary "mkGraph" d (labNodes graph)
(labEdges g)

Neither we have `showsTrinaryWith` or higher variants (I needed
`Trinary` myself, though once)

Cheers. Oleg

- [1]
https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Functor-Classes.html#v:showsBinaryWith


On 30.01.2018 15:04, Li-yao Xia wrote:
> On 01/30/2018 02:06 AM, Ivan Lazar Miljenovic wrote:
>> On 30 January 2018 at 14:48, Li-yao Xia <lysxia at gmail.com> wrote:
>>> Hello libraries,
>>>
>>> base contains a small combinator library for Read, but there doesn't
>>> seem to
>>> be a similar thing for Show. Offering a few more convenient helpers
>>> to avoid
>>> dealing with whitespace and especially precedence levels seems
>>> straightforward enough.
>>>
>>> Is there an API somewhere that I missed? Has there been a
>>> proposal/discussion about this before? I'm ready to make one otherwise.
>>
>> Have you looked at the ShowS-based methods? They tend to be a bit more
>> combinator-y (though they don't cover whitespace).  For example,
>> here's the Show instance for Data.Graph.Inductive.Tree:
>>
>> instance (Show a, Show b) => Show (Gr a b) where
>>    showsPrec d g = showParen (d > 10) $
>>                      showString "mkGraph "
>>                      . shows (labNodes g)
>>                      . showString " "
>>                      . shows (labEdges g)
>
>
> In fact, I meant that this API seems suboptimal. As you mentioned, we
> have to deal explicitly with spacing ("mkGraph ") and also precedence
> levels. It's not much but the UX could be streamlined further by
> hiding those details. (And now that I look at Text.Read again, we also
> have to deal with precedence there.)
>
> Flip showsPrec,
>
>     precShows :: a -> Int -> ShowS,
>
> Hide its result type,
>
>     type Doc = Int -> ShowS
>
> Give a combinator for constructors,
>
>     showCon :: String -> Doc
>     showCon con _ = showString con
>
> and one for function application,
>
>     showApp :: Doc -> Doc -> Doc
>     showApp f x d =
>       showParen (d > appPrec)
>         (f appPrec . showSpace . x  (appPrec + 1))
>       where
>         appPrec = 10
>
>     infixl 8 `showApp`
>
> An instance would thus look like
>
>     ...
>       precShows g =
>         showCon "mkGraph"
>           `showApp` precShows (labNodes g)
>           `showApp` precShows (labEdges g)
>
> There are also combinators for infix constructors and records to be
> written. These would cover the overwhelming majority of use cases
> where we must handwrite Show [citation needed].
>
> What do you think of that? Doesn't that look better?
>
> Li-yao
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180130/57942059/attachment.sig>