From mark.lentczner at gmail.com  Fri Jul  3 22:58:18 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Fri, 3 Jul 2015 15:58:18 -0700
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2
In-Reply-To: <CAEs96n1EA2YW0KeFgyA88NPTi3Yv8SL-NbBzyz+6nmY9FB3mrQ@mail.gmail.com>
References: <CAEs96n1EA2YW0KeFgyA88NPTi3Yv8SL-NbBzyz+6nmY9FB3mrQ@mail.gmail.com>
Message-ID: <CAAOoiFZLVvO36=AB0jWSZO8h8gZLdw6oGCGq80rD6DmjzuQovw@mail.gmail.com>

In concert, Haskell Platform 7.10.2 RC2 is out (for OS X and Linux -
Windows on its way). You can find it here:

http://www.ozonehouse.com/mark/platform/


Only minor changes since RC1:

   - version bumps to hashable, HTTP, OpenGLRaw, and cabal-install
   - closed issues #160 (typography), #157 (add --hoogle flag), #151 (OS X
   installer issue)

sha256 sums:
326e933feb71acc0485c9fa63708505dd78322fbf009712286c5b65ee2374cdf
 ghc-7.10.1.20150630-x86_64-apple-darwin.tar.bz2
606d458a0809f64933bdf132af42979e4b44209900eea6649caf2927cd449835
 haskell-platform-7.10.1.20150630-src.tar.gz
4c25593e04d55e742b60f82c9d8fe2e03490efb6381792198de42789ee817300
 haskell-platform-7.10.1.20150630-x86_64-unknown-linux-deb7.tar.gz
1a08b041731a02004eeb21811b83ecca212cd8e2587fe97b472abf8789aef83e  Haskell
Platform 7.10.1.20150630 64bit-signed.pkg

?? Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150703/3d51ae1a/attachment.html>

From jwlato at gmail.com  Sat Jul  4 00:24:06 2015
From: jwlato at gmail.com (John Lato)
Date: Sat, 04 Jul 2015 00:24:06 +0000
Subject: Abstract FilePath Proposal
In-Reply-To: <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
 <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>
Message-ID: <CAJ727GgQ2kbV62ui1eed6De-ZGkV12-cLTGGwAcZVrqmf_SXUQ@mail.gmail.com>

In an ideal world, FilePath would be an abstract type. I think nearly
everyone can agree on that.

However, it seems every major ghc release includes some major breaking
changes. I've spent a lot of time fixing the fallout from them, and this
looks much more significant than any we've had in years.

In particular, I'm quite scared that people attempted to gauge the fallout
by building hackage, but it was too much work. Also consider that private
codebases are likely to be impacted significantly (at least the ones I've
seen will be).

I think it's likely this will cause a major break in the ecosystem, with
most packages only supporting old or new style FilePath.

I guess my point is, I don't think this proposal should go ahead unless
there's significant buy-in from the community (not merely silence or a
small majority in favor). I'm not doing much Haskell these days so I'm
pretty neutral on it.

John L.

On Tue, Jun 30, 2015, 2:25 AM Neil Mitchell <ndmitchell at gmail.com> wrote:

> Hi David,
>
> > One tiny amendment to a comment(!) in the non-normative(!) code in Phase
> 3:
> >
> > data WindowsFilePath = WFP ByteArray# -- UTF16 data
> >
> > If a Windows file path is valid UTF-16 then it is displayed as such in
> the
> > GUI, but if not it's still a legal file path. It really is just wchar_t[]
> > data.
>
> Thanks for bringing this up. It's tricky - I think in practice:
>
> toFilePath x = WPF (encodeStringAsUTF16 x)
>
> But the data in WPF will be treated as UCS2 (aka wchar_t) when passing
> to the API calls, so it's really both. While on Windows NT it really
> was UCS2, but Win 7 it's always treated as UTF16 in the GUI, so that
> seems to be consistent with what people expect and ensures we don't
> throw away information when converting to/from FilePath. Given it
> seems you are quite knowledgeable in this area, please shout if that
> seems misguided!
>
> To all the people who are worried about breakage, I can guarantee this
> will cause breakage. It's a sad fact, and certainly the main negative
> to this proposal. I was on the fence initially when hvr suggested this
> change to me, but was convinced by performance and correctness.
> Whether the Haskell community as a whole thinks that makes it worth it
> is why it's a proposal. If anything, I'm concerned by the lack of
> people saying -1, please don't break my code...
>
> Thanks, Neil
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150704/3983e857/attachment.html>

From strake888 at gmail.com  Sat Jul  4 01:22:19 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Fri, 3 Jul 2015 17:22:19 -0800
Subject: Abstract FilePath Proposal
In-Reply-To: <CAOrUaLYGtQzUA6Cm1WEeCZGKVVKi88yzKRm7zUY2R0E1UouGBA@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <1435392302.1459.9.camel@joachim-breitner.de>
 <CAOrUaLZUvHd+dfQLOSd=yG2szqsTj5-5WiFZpZBjrvA5ibj4Rg@mail.gmail.com>
 <CAKFCL4XwCHKu1bk=j_tmsd0GZd68CPrEh6eSPPrvVM8Jjz57Rw@mail.gmail.com>
 <CAErCyQ-19C2MCZG8N0ur0Y3pf5Ja23gAY=wu0nAa23MkU7x_7A@mail.gmail.com>
 <CAOrUaLYGtQzUA6Cm1WEeCZGKVVKi88yzKRm7zUY2R0E1UouGBA@mail.gmail.com>
Message-ID: <CAL3m8eCSAqwDiDEYdwuJWuGEbGY7oyp+EqyCmkc+NyXo88Bvfw@mail.gmail.com>

On 27/06/2015, Yitzchak Gale <gale at sefer.org> wrote:
> OK, based on what David and Brandon wrote, I guess
> that representing paths as bytestrings does make
> some low-level sense on all platforms.

Not quite: in 9p for example, each component is a byte string, and a
path is a list of components.

9p forbids null bytes in a component tho, so one could use it as a
separator in FilePath.

That said, this is an edge case and (file path ~ byte string) may be
good enough.

From carter.schonwald at gmail.com  Sat Jul  4 02:28:29 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 3 Jul 2015 22:28:29 -0400
Subject: Abstract FilePath Proposal
In-Reply-To: <CAJ727GgQ2kbV62ui1eed6De-ZGkV12-cLTGGwAcZVrqmf_SXUQ@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
 <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>
 <CAJ727GgQ2kbV62ui1eed6De-ZGkV12-cLTGGwAcZVrqmf_SXUQ@mail.gmail.com>
Message-ID: <CAHYVw0xLTwc9rNzScQ7injrcb1D1=UinRNtYT1yNC2s=zrR36Q@mail.gmail.com>

So this goes back to a valid question:
What fraction of currently build able hackage breaks with such an Api
change, and how complex will fixing those breaks.


This should be evaluated.  And to what extent can the appropriate
migrations be mechanically assisted.
Would some of this breakage be mitigated by changing ++ to be monoid or
semigroup merge?

On Friday, July 3, 2015, John Lato <jwlato at gmail.com> wrote:

> In an ideal world, FilePath would be an abstract type. I think nearly
> everyone can agree on that.
>
> However, it seems every major ghc release includes some major breaking
> changes. I've spent a lot of time fixing the fallout from them, and this
> looks much more significant than any we've had in years.
>
> In particular, I'm quite scared that people attempted to gauge the fallout
> by building hackage, but it was too much work. Also consider that private
> codebases are likely to be impacted significantly (at least the ones I've
> seen will be).
>
> I think it's likely this will cause a major break in the ecosystem, with
> most packages only supporting old or new style FilePath.
>
> I guess my point is, I don't think this proposal should go ahead unless
> there's significant buy-in from the community (not merely silence or a
> small majority in favor). I'm not doing much Haskell these days so I'm
> pretty neutral on it.
>
> John L.
>
> On Tue, Jun 30, 2015, 2:25 AM Neil Mitchell <ndmitchell at gmail.com
> <javascript:_e(%7B%7D,'cvml','ndmitchell at gmail.com');>> wrote:
>
>> Hi David,
>>
>> > One tiny amendment to a comment(!) in the non-normative(!) code in
>> Phase 3:
>> >
>> > data WindowsFilePath = WFP ByteArray# -- UTF16 data
>> >
>> > If a Windows file path is valid UTF-16 then it is displayed as such in
>> the
>> > GUI, but if not it's still a legal file path. It really is just
>> wchar_t[]
>> > data.
>>
>> Thanks for bringing this up. It's tricky - I think in practice:
>>
>> toFilePath x = WPF (encodeStringAsUTF16 x)
>>
>> But the data in WPF will be treated as UCS2 (aka wchar_t) when passing
>> to the API calls, so it's really both. While on Windows NT it really
>> was UCS2, but Win 7 it's always treated as UTF16 in the GUI, so that
>> seems to be consistent with what people expect and ensures we don't
>> throw away information when converting to/from FilePath. Given it
>> seems you are quite knowledgeable in this area, please shout if that
>> seems misguided!
>>
>> To all the people who are worried about breakage, I can guarantee this
>> will cause breakage. It's a sad fact, and certainly the main negative
>> to this proposal. I was on the fence initially when hvr suggested this
>> change to me, but was convinced by performance and correctness.
>> Whether the Haskell community as a whole thinks that makes it worth it
>> is why it's a proposal. If anything, I'm concerned by the lack of
>> people saying -1, please don't break my code...
>>
>> Thanks, Neil
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> <javascript:_e(%7B%7D,'cvml','ghc-devs at haskell.org');>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150703/8aa79eda/attachment.html>

From svenpanne at gmail.com  Sat Jul  4 19:26:31 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Sat, 4 Jul 2015 21:26:31 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <CAHYVw0xLTwc9rNzScQ7injrcb1D1=UinRNtYT1yNC2s=zrR36Q@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
 <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>
 <CAJ727GgQ2kbV62ui1eed6De-ZGkV12-cLTGGwAcZVrqmf_SXUQ@mail.gmail.com>
 <CAHYVw0xLTwc9rNzScQ7injrcb1D1=UinRNtYT1yNC2s=zrR36Q@mail.gmail.com>
Message-ID: <CANBN=mv4EZ=L5FHZdz2h9MvOrHL0VjC+Cht4730rkmDN1m0a7w@mail.gmail.com>

2015-07-04 4:28 GMT+02:00 Carter Schonwald <carter.schonwald at gmail.com>:

> [...] What fraction of currently build able hackage breaks with such an
> Api change, and how complex will fixing those breaks.  [...]
>

I think it is highly irrelevant how complex fixing the breakage is, it will
probably almost always be trivial, but that's not the point: Think e.g.
about a package which didn't really need any update for a few years, its
maintainer is inactive (nothing to recently, so that's OK), and which is a
transitive dependency of a number of other packages. This will effectively
mean lots of broken packages for weeks or even longer. Fixing breakage from
the AMP or FTP proposals was trivial, too, but nevertheless a bit painful.

This should be evaluated.  And to what extent can the appropriate
> migrations be mechanically assisted.
> Would some of this breakage be mitigated by changing ++ to be monoid or
> semigroup merge?
>

To me the fundamental question which should be answered before any detail
question is: Should we go on and continuously break minor things (i.e.
basically give up any stability guarantees) or should we collect a bunch of
changes first (leaving vital things untouched for that time) and release
all those changes together, in longer intervals? That's IMHO a tough
question which we somehow avoided to answer up to now. I would like to see
a broader discussion like this first, both approaches have their pros and
cons, and whatever we do, there should be some kind of consensus behind it.

Cheers,
   S.

P.S.: Just for the record: I'm leaning towards the
"lots-of-changes-after-a-longer-time" approach, otherwise I see a flood of
#ifdefs and tons of failing builds coming our way... :-P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150704/fc181304/attachment.html>

From allbery.b at gmail.com  Sat Jul  4 19:38:25 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 4 Jul 2015 15:38:25 -0400
Subject: Abstract FilePath Proposal
In-Reply-To: <CANBN=mv4EZ=L5FHZdz2h9MvOrHL0VjC+Cht4730rkmDN1m0a7w@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
 <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>
 <CAJ727GgQ2kbV62ui1eed6De-ZGkV12-cLTGGwAcZVrqmf_SXUQ@mail.gmail.com>
 <CAHYVw0xLTwc9rNzScQ7injrcb1D1=UinRNtYT1yNC2s=zrR36Q@mail.gmail.com>
 <CANBN=mv4EZ=L5FHZdz2h9MvOrHL0VjC+Cht4730rkmDN1m0a7w@mail.gmail.com>
Message-ID: <CAKFCL4XnFtoBUR6Xs6N4QX6ZjxQSt5yD1aNMe8Wzds7OPCg8xw@mail.gmail.com>

On Sat, Jul 4, 2015 at 3:26 PM, Sven Panne <svenpanne at gmail.com> wrote:

> To me the fundamental question which should be answered before any detail
> question is: Should we go on and continuously break minor things (i.e.
> basically give up any stability guarantees) or should we collect a bunch of
> changes first (leaving vital things untouched for that time) and release
> all those changes together, in longer intervals? That's IMHO a tough
> question which we somehow avoided to answer up to now. I would like to see
> a broader discussion like this first, both approaches have their pros and
> cons, and whatever we do, there should be some kind of consensus behind it.


I recall suggesting something along the lines of stable vs. research ghc
releases a few months back. This seems like it would fit in fairly well;
the problem is getting buy-in from certain parts of the ecosystem that seem
to prefer to build production-oriented packages from research/"unstable"
releases.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150704/0ab0a18c/attachment.html>

From amindfv at gmail.com  Sat Jul  4 20:48:22 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Sat, 4 Jul 2015 16:48:22 -0400
Subject: Abstract FilePath Proposal
In-Reply-To: <CANBN=mv4EZ=L5FHZdz2h9MvOrHL0VjC+Cht4730rkmDN1m0a7w@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
 <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>
 <CAJ727GgQ2kbV62ui1eed6De-ZGkV12-cLTGGwAcZVrqmf_SXUQ@mail.gmail.com>
 <CAHYVw0xLTwc9rNzScQ7injrcb1D1=UinRNtYT1yNC2s=zrR36Q@mail.gmail.com>
 <CANBN=mv4EZ=L5FHZdz2h9MvOrHL0VjC+Cht4730rkmDN1m0a7w@mail.gmail.com>
Message-ID: <B5D27E18-77A3-4DA0-A447-6907C3D4F620@gmail.com>

El Jul 4, 2015, a las 15:26, Sven Panne <svenpanne at gmail.com> escribi?:

> 2015-07-04 4:28 GMT+02:00 Carter Schonwald <carter.schonwald at gmail.com>:
>> [...] What fraction of currently build able hackage breaks with such an Api change, and how complex will fixing those breaks.  [...]
> 
> I think it is highly irrelevant how complex fixing the breakage is, it will probably almost always be trivial, but that's not the point: Think e.g. about a package which didn't really need any update for a few years, its maintainer is inactive (nothing to recently, so that's OK), and which is a transitive dependency of a number of other packages. This will effectively mean lots of broken packages for weeks or even longer. Fixing breakage from the AMP or FTP proposals was trivial, too, but nevertheless a bit painful. 
> 
>> This should be evaluated.  And to what extent can the appropriate migrations be mechanically assisted. 
>> Would some of this breakage be mitigated by changing ++ to be monoid or semigroup merge? 
> 
> To me the fundamental question which should be answered before any detail question is: Should we go on and continuously break minor things (i.e. basically give up any stability guarantees) or should we collect a bunch of changes first (leaving vital things untouched for that time) and release all those changes together, in longer intervals? That's IMHO a tough question which we somehow avoided to answer up to now.

I'd argue that Haskell and GHC's history clearly shows we've answered that question and that overalll we value frequent small breaking changes over giant change roadblocks like Perl's or Python's. Still +0 on the proposal though.

Tom


> I would like to see a broader discussion like this first, both approaches have their pros and cons, and whatever we do, there should be some kind of consensus behind it.
> 
> Cheers,
>    S.
> 
> P.S.: Just for the record: I'm leaning towards the "lots-of-changes-after-a-longer-time" approach, otherwise I see a flood of #ifdefs and tons of failing builds coming our way... :-P
> _______________________________________________
> 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/20150704/95774526/attachment.html>

From svenpanne at gmail.com  Sat Jul  4 21:16:53 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Sat, 4 Jul 2015 23:16:53 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <B5D27E18-77A3-4DA0-A447-6907C3D4F620@gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
 <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>
 <CAJ727GgQ2kbV62ui1eed6De-ZGkV12-cLTGGwAcZVrqmf_SXUQ@mail.gmail.com>
 <CAHYVw0xLTwc9rNzScQ7injrcb1D1=UinRNtYT1yNC2s=zrR36Q@mail.gmail.com>
 <CANBN=mv4EZ=L5FHZdz2h9MvOrHL0VjC+Cht4730rkmDN1m0a7w@mail.gmail.com>
 <B5D27E18-77A3-4DA0-A447-6907C3D4F620@gmail.com>
Message-ID: <CANBN=mss0+iHp1TbCh5Y9bybFf3Qc+1KHUc-fvazbVJrki-2MA@mail.gmail.com>

2015-07-04 22:48 GMT+02:00 <amindfv at gmail.com>:

> I'd argue that Haskell and GHC's history clearly shows we've answered that
> question and that overalll we value frequent small breaking changes over
> giant change roadblocks like Perl's or Python's. [...]
>

I'm not sure that "value" is the right word. My impression is more that
this somehow happened accidentally and was not the result of careful
planning or broad consensus. And even if in the past this might have been
the right thing, I consider today's state of affairs as something totally
different: In the past it was only GHC, small parts of the language or a
handful of packages (or even just a few modules, in the pre-package times).
Today every change resonates through thousands of packages on Hackage and
elsewhere. IMHO some approach similar to e.g. C++03 => C++11 => C++14 makes
more sense in world like this than a constantly fluctuating base, but
others might see this differently. My fear is that this will inevitably
lead to the necessity of having an autoconf-like feature detection
machinery to compile a package, and looking at a few packages, we are
already halfway there. :-/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150704/f4f87d9b/attachment.html>

From strake888 at gmail.com  Sun Jul  5 18:26:51 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Sun, 5 Jul 2015 10:26:51 -0800
Subject: Abstract FilePath Proposal
In-Reply-To: <CANBN=mv4EZ=L5FHZdz2h9MvOrHL0VjC+Cht4730rkmDN1m0a7w@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
 <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>
 <CAJ727GgQ2kbV62ui1eed6De-ZGkV12-cLTGGwAcZVrqmf_SXUQ@mail.gmail.com>
 <CAHYVw0xLTwc9rNzScQ7injrcb1D1=UinRNtYT1yNC2s=zrR36Q@mail.gmail.com>
 <CANBN=mv4EZ=L5FHZdz2h9MvOrHL0VjC+Cht4730rkmDN1m0a7w@mail.gmail.com>
Message-ID: <55997395.441a460a.382c6.ffff9900@mx.google.com>

On 04/07/2015 at 21:26:31 +0200, Sven Panne wrote:
> To me the fundamental question which should be answered before any detail
> question is: Should we go on and continuously break minor things (i.e.
> basically give up any stability guarantees) or should we collect a bunch of
> changes first (leaving vital things untouched for that time) and release
> all those changes together, in longer intervals? That's IMHO a tough
> question which we somehow avoided to answer up to now. I would like to see
> a broader discussion like this first, both approaches have their pros and
> cons, and whatever we do, there should be some kind of consensus behind it.

Potentially we ought to await Backpack [0], which should make such transitions easier.

[0] http://plv.mpi-sws.org/backpack/

From winterkoninkje at gmail.com  Sun Jul  5 20:14:41 2015
From: winterkoninkje at gmail.com (wren romano)
Date: Sun, 5 Jul 2015 16:14:41 -0400
Subject: Abstract FilePath Proposal
In-Reply-To: <CANBN=muK2=Ofv=hSCKA5GCHRUaaZG5ymgYZfbpqrbt3fWqJ4YA@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
 <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
 <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>
 <CANBN=ms=vnFOjfbP24h5Ta6th4qau3ZookzFAmPHtqhbi5dvoA@mail.gmail.com>
 <CAJ0eudpKPKxRuKVH0k13dnEcX=XsKHvrj7+PathY0xNVFN9MoQ@mail.gmail.com>
 <CANBN=muK2=Ofv=hSCKA5GCHRUaaZG5ymgYZfbpqrbt3fWqJ4YA@mail.gmail.com>
Message-ID: <CABUjdS4HCuRkkH+bqF=YvBdxOiLyOckZkoXuiCE4+UNcNZopAQ@mail.gmail.com>

On Sun, Jun 28, 2015 at 12:21 PM, Sven Panne <svenpanne at gmail.com> wrote:
> OK, then I misunderstood what you meant by "normalizing". But a question
> remains then: What is a use case for having equality modulo "normalise"? It
> throws together a few more paths which plain equality on strings would
> consider different, but it is still not semantic equality in the sense of
> "these 2 paths refer to the same dir/file". So unless there is a compelling
> use case (which I don't see), I don't see a point in always doing
> "normalise". Or do I miss something?

In my experience, the number one reason for (me to bother with)
normalizing paths is because I'm doing metaprogramming and want to
generate clean scripts. This includes both the IO and non-IO notions
of normalization. It's all about producing hygienic output, and it
would be nice to have all the OS-dependent things programmed away in a
library somewhere so I don't have to rewrite it.

IMO, normalization has nothing to do with equality. Then again, I
consider the notion of equality on file paths[1] to be as dubious as
the notion of equality on IEEE-754 floats.


[1] path *components* do have a well-formed notion of equality; it's
just that entire paths do not.

-- 
Live well,
~wren

From mark.lentczner at gmail.com  Tue Jul  7 05:26:27 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Mon, 6 Jul 2015 22:26:27 -0700
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2
In-Reply-To: <CAAOoiFZLVvO36=AB0jWSZO8h8gZLdw6oGCGq80rD6DmjzuQovw@mail.gmail.com>
References: <CAEs96n1EA2YW0KeFgyA88NPTi3Yv8SL-NbBzyz+6nmY9FB3mrQ@mail.gmail.com>
 <CAAOoiFZLVvO36=AB0jWSZO8h8gZLdw6oGCGq80rD6DmjzuQovw@mail.gmail.com>
Message-ID: <CAAOoiFZJZGaQQwtn6DF9EdP3CPHuVJwDQ0RbpE_Dh81L2Dbbzw@mail.gmail.com>

And now Windows RC2 for Haksell Platform is also here:

http://www.ozonehouse.com/mark/platform/


[1008] : sha256sum HaskellPlatform-7.10.1.20150630-x86_64-setup.exe
6157bbb50de63c1af068f83c4b7888f12b6f29d258bf33dbefb56dd6ea717021
 HaskellPlatform-7.10.1.20150630-x86_64-setup.exe?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150706/80e6755a/attachment.html>

From fumiexcel at gmail.com  Tue Jul  7 07:56:35 2015
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Tue, 7 Jul 2015 16:56:35 +0900
Subject: Generalizing replicateM?
Message-ID: <CAATCwU=82eamJF8fr5bGK=s4wa=Pa3Ufjtwr9wrYTqQCEDv+bQ@mail.gmail.com>

I noticed that traceM is generalized to use Applicative. Then, how about
replicateM/replicateM_?

I don't quite like confusing names, but is better than
needlessly restrictive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150707/1895a15f/attachment.html>

From svenpanne at gmail.com  Tue Jul  7 08:54:11 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Tue, 7 Jul 2015 10:54:11 +0200
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2
In-Reply-To: <CAAOoiFZJZGaQQwtn6DF9EdP3CPHuVJwDQ0RbpE_Dh81L2Dbbzw@mail.gmail.com>
References: <CAEs96n1EA2YW0KeFgyA88NPTi3Yv8SL-NbBzyz+6nmY9FB3mrQ@mail.gmail.com>
 <CAAOoiFZLVvO36=AB0jWSZO8h8gZLdw6oGCGq80rD6DmjzuQovw@mail.gmail.com>
 <CAAOoiFZJZGaQQwtn6DF9EdP3CPHuVJwDQ0RbpE_Dh81L2Dbbzw@mail.gmail.com>
Message-ID: <CANBN=mvxE7Dbyb+xvBA_FEf5MSQ=sEjUOb9+yAuWpDEUiokb6w@mail.gmail.com>

2015-07-07 7:26 GMT+02:00 Mark Lentczner <mark.lentczner at gmail.com>:

> And now Windows RC2 for Haksell Platform is also here:
>
> http://www.ozonehouse.com/mark/platform/
>
> [...]
>

I noticed 2 problems so far:

* The package cache is still always out of date (I thought there was a fix
for that):

----------------------------------------------------------------------
Sven at SCOTTY /d/Repositories/ObjectName (master)
$ ghc-pkg list
WARNING: cache is out of date: c:/Program Files/Haskell
Platform/7.10.2\lib\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
c:/Program Files/Haskell Platform/7.10.2\lib\package.conf.d:
    Cabal-1.22.4.0
    GLURaw-1.5.0.1
    GLUT-2.7.0.1
[...]
----------------------------------------------------------------------

* Something is missing/misconfigured for Haddock (note the funny non-local
path in the error message):

----------------------------------------------------------------------
Sven at SCOTTY /d/Repositories/ObjectName (master)
$ cabal sandbox init
Writing a default package environment file to
d:\Repositories\ObjectName\cabal.sandbox.config
Creating a new sandbox at D:\Repositories\ObjectName\.cabal-sandbox

Sven at SCOTTY /d/Repositories/ObjectName (master)
$ cabal configure
Resolving dependencies...
Configuring ObjectName-1.1.0.0...

Sven at SCOTTY /d/Repositories/ObjectName (master)
$ cabal haddock
Running Haddock for ObjectName-1.1.0.0...
Preprocessing library ObjectName-1.1.0.0...
Haddock coverage:
 100% (  3 /  3) in 'Data.ObjectName'
Haddock's resource directory
(G:\GitHub\haddock\.cabal-sandbox\x86_64-windows-ghc-7.10.1.20150630\haddock-api-2.16.1)
does not exist!
----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150707/211e22fb/attachment.html>

From thomasmiedema at gmail.com  Tue Jul  7 11:30:15 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Tue, 7 Jul 2015 13:30:15 +0200
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2
In-Reply-To: <CANBN=mvxE7Dbyb+xvBA_FEf5MSQ=sEjUOb9+yAuWpDEUiokb6w@mail.gmail.com>
References: <CAEs96n1EA2YW0KeFgyA88NPTi3Yv8SL-NbBzyz+6nmY9FB3mrQ@mail.gmail.com>
 <CAAOoiFZLVvO36=AB0jWSZO8h8gZLdw6oGCGq80rD6DmjzuQovw@mail.gmail.com>
 <CAAOoiFZJZGaQQwtn6DF9EdP3CPHuVJwDQ0RbpE_Dh81L2Dbbzw@mail.gmail.com>
 <CANBN=mvxE7Dbyb+xvBA_FEf5MSQ=sEjUOb9+yAuWpDEUiokb6w@mail.gmail.com>
Message-ID: <CAD3WKghP97K8bR+8WcD6GBwy6dD2zyYxXXP0GW72W9EYc3MSWg@mail.gmail.com>

On Tue, Jul 7, 2015 at 10:54 AM, Sven Panne <svenpanne at gmail.com> wrote:
>
> * The package cache is still always out of date (I thought there was a fix
> for that):
>

Please reopen https://ghc.haskell.org/trac/ghc/ticket/10205 with the output
of `which ghc-pkg` and `ghc-pkg list -v`.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150707/4ffa7afd/attachment.html>

From svenpanne at gmail.com  Tue Jul  7 11:42:26 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Tue, 7 Jul 2015 13:42:26 +0200
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 2
In-Reply-To: <CAD3WKghP97K8bR+8WcD6GBwy6dD2zyYxXXP0GW72W9EYc3MSWg@mail.gmail.com>
References: <CAEs96n1EA2YW0KeFgyA88NPTi3Yv8SL-NbBzyz+6nmY9FB3mrQ@mail.gmail.com>
 <CAAOoiFZLVvO36=AB0jWSZO8h8gZLdw6oGCGq80rD6DmjzuQovw@mail.gmail.com>
 <CAAOoiFZJZGaQQwtn6DF9EdP3CPHuVJwDQ0RbpE_Dh81L2Dbbzw@mail.gmail.com>
 <CANBN=mvxE7Dbyb+xvBA_FEf5MSQ=sEjUOb9+yAuWpDEUiokb6w@mail.gmail.com>
 <CAD3WKghP97K8bR+8WcD6GBwy6dD2zyYxXXP0GW72W9EYc3MSWg@mail.gmail.com>
Message-ID: <CANBN=mtB+8YcOAxh_q3mxX24znWQMN7D-=NguZRQ9H97HFacNQ@mail.gmail.com>

2015-07-07 13:30 GMT+02:00 Thomas Miedema <thomasmiedema at gmail.com>:

>
>
> On Tue, Jul 7, 2015 at 10:54 AM, Sven Panne <svenpanne at gmail.com> wrote:
>>
>> * The package cache is still always out of date (I thought there was a
>> fix for that):
>>
>
> Please reopen https://ghc.haskell.org/trac/ghc/ticket/10205 with the
> output of `which ghc-pkg` and `ghc-pkg list -v`.
>

Done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150707/e25d35c8/attachment.html>

From ryan.gl.scott at gmail.com  Tue Jul  7 14:14:40 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Tue, 7 Jul 2015 09:14:40 -0500
Subject: Generalizing replicateM?
Message-ID: <CADdQpRC2ScJEpQMLyRMH+CpRgPr0hmyK+wTKpD6BPRa1bT7oMA@mail.gmail.com>

It looks like M Farkas-Dyck submitted a patch to generalize filterM,
mapAndUnzipM, zipWithM, zipWithM_, replicateM, and replicateM_ to use
Applicative instead of Monad: https://ghc.haskell.org/trac/ghc/ticket/10168.

Also, +1 on the suggestion. Let's tie up the loose ends of the AMP now
that's it's official.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150707/fa06b20d/attachment.html>

From ekmett at gmail.com  Tue Jul  7 16:51:01 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 7 Jul 2015 12:51:01 -0400
Subject: Generalizing replicateM?
In-Reply-To: <CAATCwU=82eamJF8fr5bGK=s4wa=Pa3Ufjtwr9wrYTqQCEDv+bQ@mail.gmail.com>
References: <CAATCwU=82eamJF8fr5bGK=s4wa=Pa3Ufjtwr9wrYTqQCEDv+bQ@mail.gmail.com>
Message-ID: <CAJumaK_3OPbguALAhPeg4JHT1nb-FaiBdmsNpZV65Nak=0coag@mail.gmail.com>

+1 from me.

-Edward

On Tue, Jul 7, 2015 at 3:56 AM, Fumiaki Kinoshita <fumiexcel at gmail.com>
wrote:

> I noticed that traceM is generalized to use Applicative. Then, how about
> replicateM/replicateM_?
>
> I don't quite like confusing names, but is better than
> needlessly restrictive.
>
> _______________________________________________
> 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/20150707/b145b393/attachment.html>

From bart.massey at gmail.com  Tue Jul  7 16:58:09 2015
From: bart.massey at gmail.com (Bart Massey)
Date: Tue, 07 Jul 2015 16:58:09 +0000
Subject: Generalizing replicateM?
In-Reply-To: <CAJumaK_3OPbguALAhPeg4JHT1nb-FaiBdmsNpZV65Nak=0coag@mail.gmail.com>
References: <CAATCwU=82eamJF8fr5bGK=s4wa=Pa3Ufjtwr9wrYTqQCEDv+bQ@mail.gmail.com>
 <CAJumaK_3OPbguALAhPeg4JHT1nb-FaiBdmsNpZV65Nak=0coag@mail.gmail.com>
Message-ID: <CAA6gtpmYMym+S+oV5jghs8mEXD0G07LvA8_NECVc3Xc4DfoLwA@mail.gmail.com>

+1 for the Farkas-Dyck patch. Someone should check the performance of the
replacement filterM, though: those loops may have been there for a reason
that is still valid.

On Tue, Jul 7, 2015 at 9:51 AM Edward Kmett <ekmett at gmail.com> wrote:

> +1 from me.
>
> -Edward
>
> On Tue, Jul 7, 2015 at 3:56 AM, Fumiaki Kinoshita <fumiexcel at gmail.com>
> wrote:
>
>> I noticed that traceM is generalized to use Applicative. Then, how about
>> replicateM/replicateM_?
>>
>> I don't quite like confusing names, but is better than
>> needlessly restrictive.
>>
>> _______________________________________________
>> 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/20150707/f42b7818/attachment.html>

From omeragacan at gmail.com  Tue Jul  7 17:25:20 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Tue, 7 Jul 2015 13:25:20 -0400
Subject: Generalizing replicateM?
In-Reply-To: <CAA6gtpmYMym+S+oV5jghs8mEXD0G07LvA8_NECVc3Xc4DfoLwA@mail.gmail.com>
References: <CAATCwU=82eamJF8fr5bGK=s4wa=Pa3Ufjtwr9wrYTqQCEDv+bQ@mail.gmail.com>
 <CAJumaK_3OPbguALAhPeg4JHT1nb-FaiBdmsNpZV65Nak=0coag@mail.gmail.com>
 <CAA6gtpmYMym+S+oV5jghs8mEXD0G07LvA8_NECVc3Xc4DfoLwA@mail.gmail.com>
Message-ID: <CAMQQO3mNpqMvGoA+0R4Bdrj=q5jyfNgGFHz8mg0+KKGF-tFE_Q@mail.gmail.com>

(looking at the patch) Shouldn't we rename them to `filterA`,
`replicateA` etc. and move to Control.Applicative module? (like
`liftM` vs. `liftA`)

2015-07-07 12:58 GMT-04:00 Bart Massey <bart.massey at gmail.com>:
> +1 for the Farkas-Dyck patch. Someone should check the performance of the
> replacement filterM, though: those loops may have been there for a reason
> that is still valid.
>
> On Tue, Jul 7, 2015 at 9:51 AM Edward Kmett <ekmett at gmail.com> wrote:
>>
>> +1 from me.
>>
>> -Edward
>>
>> On Tue, Jul 7, 2015 at 3:56 AM, Fumiaki Kinoshita <fumiexcel at gmail.com>
>> wrote:
>>>
>>> I noticed that traceM is generalized to use Applicative. Then, how about
>>> replicateM/replicateM_?
>>>
>>> I don't quite like confusing names, but is better than needlessly
>>> restrictive.
>>>
>>> _______________________________________________
>>> 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 ekmett at gmail.com  Tue Jul  7 18:40:42 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 7 Jul 2015 14:40:42 -0400
Subject: Generalizing replicateM?
In-Reply-To: <CAMQQO3mNpqMvGoA+0R4Bdrj=q5jyfNgGFHz8mg0+KKGF-tFE_Q@mail.gmail.com>
References: <CAATCwU=82eamJF8fr5bGK=s4wa=Pa3Ufjtwr9wrYTqQCEDv+bQ@mail.gmail.com>
 <CAJumaK_3OPbguALAhPeg4JHT1nb-FaiBdmsNpZV65Nak=0coag@mail.gmail.com>
 <CAA6gtpmYMym+S+oV5jghs8mEXD0G07LvA8_NECVc3Xc4DfoLwA@mail.gmail.com>
 <CAMQQO3mNpqMvGoA+0R4Bdrj=q5jyfNgGFHz8mg0+KKGF-tFE_Q@mail.gmail.com>
Message-ID: <CAJumaK8Hcd8diADKYcOx6icDCZzkwaRfVW8pZ3HDea-sXqkuqw@mail.gmail.com>

We made a blanket call on a half-dozen earlier similar proposals a while
back to simply consider the M to be a more generalized suffix, as a
majority of the fooM combinators can be generalized in this way.

The alternative duplicates almost all of the APIs and provides no good
migration plan. In addition, moving them requires a rather annoying period
of code breakage, and fosters situations where users who want to have a
wide support window just can't use the new functionality or never realize
it is there.

Generalizing them in place, however, grants optimization improvements to
existing users.

liftM vs. liftA continues to exist because they actually serve a purpose as
a valid default definition for fmap in terms of return and (>>=) or pure
and (<*>) respectively.

liftMn vs. liftAn on the other hand, will continue to exist for historical
reasons, but we shouldn't seek to emulate that pattern. We may actually
eventually switch liftMn to just invoke liftAn if we can show it doesn't
introduce any problems, but as this hasn't yet been shown, we're doing
nothing there at the moment.

-Edward

On Tue, Jul 7, 2015 at 1:25 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
wrote:

> (looking at the patch) Shouldn't we rename them to `filterA`,
> `replicateA` etc. and move to Control.Applicative module? (like
> `liftM` vs. `liftA`)
>
> 2015-07-07 12:58 GMT-04:00 Bart Massey <bart.massey at gmail.com>:
> > +1 for the Farkas-Dyck patch. Someone should check the performance of the
> > replacement filterM, though: those loops may have been there for a reason
> > that is still valid.
> >
> > On Tue, Jul 7, 2015 at 9:51 AM Edward Kmett <ekmett at gmail.com> wrote:
> >>
> >> +1 from me.
> >>
> >> -Edward
> >>
> >> On Tue, Jul 7, 2015 at 3:56 AM, Fumiaki Kinoshita <fumiexcel at gmail.com>
> >> wrote:
> >>>
> >>> I noticed that traceM is generalized to use Applicative. Then, how
> about
> >>> replicateM/replicateM_?
> >>>
> >>> I don't quite like confusing names, but is better than needlessly
> >>> restrictive.
> >>>
> >>> _______________________________________________
> >>> Libraries mailing list
> >>> Libraries at haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>>
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150707/e04cde78/attachment.html>

From fumiexcel at gmail.com  Wed Jul  8 00:02:32 2015
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Wed, 8 Jul 2015 09:02:32 +0900
Subject: Generalizing replicateM?
In-Reply-To: <CADdQpRC2ScJEpQMLyRMH+CpRgPr0hmyK+wTKpD6BPRa1bT7oMA@mail.gmail.com>
References: <CADdQpRC2ScJEpQMLyRMH+CpRgPr0hmyK+wTKpD6BPRa1bT7oMA@mail.gmail.com>
Message-ID: <CAATCwUn5cn9vR+e56Qa0NezLr9HsnkrbDNWmyhg1R_nCJciwBg@mail.gmail.com>

Alas, that ticket has been left alone. We should review it!

2015-07-07 23:14 GMT+09:00 Ryan Scott <ryan.gl.scott at gmail.com>:

> It looks like M Farkas-Dyck submitted a patch to generalize filterM,
> mapAndUnzipM, zipWithM, zipWithM_, replicateM, and replicateM_ to use
> Applicative instead of Monad:
> https://ghc.haskell.org/trac/ghc/ticket/10168.
>
> Also, +1 on the suggestion. Let's tie up the loose ends of the AMP now
> that's it's official.
>
> _______________________________________________
> 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/20150708/a655c1d4/attachment-0001.html>

From strake888 at gmail.com  Wed Jul  8 15:36:41 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Wed, 8 Jul 2015 07:36:41 -0800
Subject: Generalizing replicateM?
In-Reply-To: <CAA6gtpmYMym+S+oV5jghs8mEXD0G07LvA8_NECVc3Xc4DfoLwA@mail.gmail.com>
References: <CAATCwU=82eamJF8fr5bGK=s4wa=Pa3Ufjtwr9wrYTqQCEDv+bQ@mail.gmail.com>
 <CAJumaK_3OPbguALAhPeg4JHT1nb-FaiBdmsNpZV65Nak=0coag@mail.gmail.com>
 <CAA6gtpmYMym+S+oV5jghs8mEXD0G07LvA8_NECVc3Xc4DfoLwA@mail.gmail.com>
Message-ID: <559d4030.6222460a.69abc.7aca@mx.google.com>

On 07/07/2015 at 16:58:09 +0000, Bart Massey wrote:
> +1 for the Farkas-Dyck patch. Someone should check the performance of the
> replacement filterM, though: those loops may have been there for a reason
> that is still valid.

What loops? It was and is a fold.

From mdorman at ironicdesign.com  Thu Jul  9 21:26:22 2015
From: mdorman at ironicdesign.com (Michael Alan Dorman)
Date: Thu, 09 Jul 2015 17:26:22 -0400
Subject: QuickCheck failures with new 'tar' release...
Message-ID: <877fq9vx8h.fsf@ironicdesign.com>

I'm not sure if there's a more appropriate venue to bring this up; the
package doesn't seem to have any sort of explicit issue tracker.

On the NixOS build servers, we're seeing across-the-board failures for
the 0.4.2.0 release of the 'tar' library, specifically, two properties
that were added in the latest release.

It looks to me like prop_lookup is fundamentally broken---it falls over
in the face of a lookup for 'a/b' in a list of entries that includes
'a/b/c/d', because while the library lookup function returns a match
including the remainder of the path as a result, the Data.List.lookup
that it's comparing against returns nothing.

I don't see a way for the test as it is constituted to work reliably.
I'm going to guess that prop_valid suffers from a similar issue.

Either way, it would be nice if they could either be corrected, or diked
out until that happens.

Mike.

From michael at snoyman.com  Thu Jul  9 21:27:39 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 09 Jul 2015 21:27:39 +0000
Subject: QuickCheck failures with new 'tar' release...
In-Reply-To: <877fq9vx8h.fsf@ironicdesign.com>
References: <877fq9vx8h.fsf@ironicdesign.com>
Message-ID: <CAKA2JgLtjUmz1o9pXTV1-q=0_oKH5BUnYR9rh32dcxSqVpK7_g@mail.gmail.com>

I ran into the same thing with Stackage and filed the issue here:

https://github.com/fpco/stackage/issues/666

Stackage is not accepting the new tar version due to these failures.

On Thu, Jul 9, 2015 at 2:26 PM Michael Alan Dorman <mdorman at ironicdesign.com>
wrote:

> I'm not sure if there's a more appropriate venue to bring this up; the
> package doesn't seem to have any sort of explicit issue tracker.
>
> On the NixOS build servers, we're seeing across-the-board failures for
> the 0.4.2.0 release of the 'tar' library, specifically, two properties
> that were added in the latest release.
>
> It looks to me like prop_lookup is fundamentally broken---it falls over
> in the face of a lookup for 'a/b' in a list of entries that includes
> 'a/b/c/d', because while the library lookup function returns a match
> including the remainder of the path as a result, the Data.List.lookup
> that it's comparing against returns nothing.
>
> I don't see a way for the test as it is constituted to work reliably.
> I'm going to guess that prop_valid suffers from a similar issue.
>
> Either way, it would be nice if they could either be corrected, or diked
> out until that happens.
>
> Mike.
> _______________________________________________
> 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/20150709/5d0b6d12/attachment.html>

From lemming at henning-thielemann.de  Fri Jul 10 17:25:46 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 10 Jul 2015 19:25:46 +0200 (CEST)
Subject: Abstract FilePath Proposal
In-Reply-To: <CAM8C2CBOQ9jJuD0A3b5tkTd=nDXK70ERybU=8LkH4+2RXbLZnQ@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAM8C2CBOQ9jJuD0A3b5tkTd=nDXK70ERybU=8LkH4+2RXbLZnQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1507101924270.32436@sputnik>



On Sat, 27 Jun 2015, David Fox wrote:

> ?I've had success with a slightly different "How":
> 
> Phase 1: Replace FilePath with a type class, with instances for the old 
> FilePath (i.e. String) and the new implementation.

There could be more instances for platform specific FilePath types, e.g. 
for creating Windows file paths on Unix.

From novadenizen at gmail.com  Sun Jul 12 06:54:50 2015
From: novadenizen at gmail.com (Ken Bateman)
Date: Sun, 12 Jul 2015 02:54:50 -0400
Subject: Using newtypes or any data with unboxed Vectors
Message-ID: <CACsFjbxDc7MGm6Ln9aWzj0dpWKTvMVGhktWAZqa=O9koi3wMLA@mail.gmail.com>

I think I've managed to come up with an easy, useful, and sound way for
mere mortals to use unboxed vectors with arbitrary datatypes, without using
template Haskell.

I had a need for this capability, googled about it, and I didn't find a
satisfying way to do it.  This technique seemed useful and simple enough to
go into the vector library, but there's so much stuff going on in there I'm
not ready to submit a patch.

A user just needs to create an UnboxEquivalent instance for their type, and
then they can work with what looks and acts like a vector of their type,
but is in fact backed by a newtype-wrapped unboxed vector of the equivalent
type.

newtype SmallPos = Pos Int
    deriving (Eq, Ord, Show)

smallPos :: Int -> SmallPos
smallPos x | x > 0 && x < 100 = Pos x
           | otherwise = error "bad SmallPos"

instance UnboxEquivalent SmallPos where
    type UnboxEquiv SmallPos = Word8
    toUnbox (Pos x) = fromIntegral x
    fromUnbox x = (Pos (fromIntegral x))

test1 :: EVector SmallPos
test1 = Data.Vector.Generic.fromList $ map smallPos [5..15]

UnboxEquivalent.hs is at http://lpaste.net/136381
Some really simple test code is at http://lpaste.net/136382

I haven't performance tested it, or stuck {-# INLINE #-} annotations in,
but I think everything should be optimizing away to nothing, except of
course for the toUnbox and fromUnbox calls.

What do you think?

-Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150712/e786b54a/attachment.html>

From mark.lentczner at gmail.com  Sun Jul 12 16:03:53 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sun, 12 Jul 2015 09:03:53 -0700
Subject: Improving the "Get Haskell Experience"
Message-ID: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>

*tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
shipping pre-built packages, so we banish cabal hell, and have a single
common way to 'get Haskell' that just works.*

At ICFP '14, there were several long group discussions of the state of
"getting Haskell", including Haskell Platform, Stackage, and other
approaches. Over the last year, there have been a few more public
discussions and evolution on the ideas, and other installer developments.
In particular, Stackage's LTS package sets are a direct development from
this work, and the release of stack has offered new options.

Today, drawing from all this good work and ideas from so many, we'd would
like to propose a concrete plan:

   - Haskell Platform becomes the standard way to get *GHC* and related
   tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a
   user-friendly, cross-platform installer that gives a standard way to "get
   Haskell" for most users.
   - Use the *stack* model for package installation:
   - The global db has only the GHC packages
      - There is a package db for each curated set, Haskell Platform
      becomes one such set
      - Projects each have their own package db, much like sandboxes.
   - Haskell Platform's installer will no longer include pre-built,
   pre-installed packages other than GHC's set. Instead, it is configured so
   that *stack* can be used to build and install, on as needed, the
   corresponding Haskell Platform release packages.

We think this plan solves many different community needs:

   - We have a clear way to "get Haskell" that works for a wide variety of
   use cases.
   - HP installer gets much smaller, and about as minimal as a working
   installation can get.
   - By leaving most packages out of the global database, users of
   cabal-install, will now have far fewer problems. Sandbox builds should now
   never give users "cabal hell" like warnings.
   - By building and installing the Platform packages into it's own package
   db, users get the benefit of building and installing these common packages
   only once per system, yet can easily bypass them for any given project if
   desired.
   - Since the Platform packages are now built and installed as needed,
   installing on smaller systems or servers without OpenGL will work.

To do this, we have a bit of work ahead of us: We need to settle on
installation layout for each OS (including getting msys into the Windows
installer); decide on the naming and versioning of the Platform package set
(is it just LTS? does it have a different life cycle? etc...); getting
*stack* ready such a distribution; and configuring (or updating)
*cabal-install* to support the three-layer package db scheme. We think we
can do this in short order.

We recognize this represents a significant change for the Platform, and
will require buy-in from the various parts, especially *ghc*, *cabal*, and
*stack*. We'd like to get your input.

- Michael & Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150712/89b27b4b/attachment.html>

From amindfv at gmail.com  Sun Jul 12 16:16:22 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Sun, 12 Jul 2015 12:16:22 -0400
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
Message-ID: <EA807597-BB2B-40D0-B6E3-BAE58759B7C8@gmail.com>

Just to be clear, we're talking about for the upcoming HP release? Isn't stack ~1 month old?

Tom


El Jul 12, 2015, a las 12:03, Mark Lentczner <mark.lentczner at gmail.com> escribi?:

> tl;dr: We'd like to incorporate stack into Haskell Platform, and stop shipping pre-built packages, so we banish cabal hell, and have a single common way to 'get Haskell' that just works.
> 
> At ICFP '14, there were several long group discussions of the state of "getting Haskell", including Haskell Platform, Stackage, and other approaches. Over the last year, there have been a few more public discussions and evolution on the ideas, and other installer developments. In particular, Stackage's LTS package sets are a direct development from this work, and the release of stack has offered new options.
> 
> Today, drawing from all this good work and ideas from so many, we'd would like to propose a concrete plan:
> Haskell Platform becomes the standard way to get GHC and related tools: alex, cabal, happy, hscolour, and stack. It's a user-friendly, cross-platform installer that gives a standard way to "get Haskell" for most users.
> Use the stack model for package installation:
> The global db has only the GHC packages
> There is a package db for each curated set, Haskell Platform becomes one such set
> Projects each have their own package db, much like sandboxes.
> Haskell Platform's installer will no longer include pre-built, pre-installed packages other than GHC's set. Instead, it is configured so that stack can be used to build and install, on as needed, the corresponding Haskell Platform release packages.
> We think this plan solves many different community needs:
> We have a clear way to "get Haskell" that works for a wide variety of use cases.
> HP installer gets much smaller, and about as minimal as a working installation can get.
> By leaving most packages out of the global database, users of cabal-install, will now have far fewer problems. Sandbox builds should now never give users "cabal hell" like warnings.
> By building and installing the Platform packages into it's own package db, users get the benefit of building and installing these common packages only once per system, yet can easily bypass them for any given project if desired.
> Since the Platform packages are now built and installed as needed, installing on smaller systems or servers without OpenGL will work.
> To do this, we have a bit of work ahead of us: We need to settle on installation layout for each OS (including getting msys into the Windows installer); decide on the naming and versioning of the Platform package set (is it just LTS? does it have a different life cycle? etc...); getting stack ready such a distribution; and configuring (or updating) cabal-install to support the three-layer package db scheme. We think we can do this in short order.
> 
> We recognize this represents a significant change for the Platform, and will require buy-in from the various parts, especially ghc, cabal, and stack. We'd like to get your input.
> 
> - Michael & Mark
> _______________________________________________
> 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/20150712/5d24bda5/attachment.html>

From gershomb at gmail.com  Sun Jul 12 16:19:19 2015
From: gershomb at gmail.com (Gershom B)
Date: Sun, 12 Jul 2015 12:19:19 -0400
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
Message-ID: <etPan.55a293c3.2cd6aab0.d112@mbp.local>

I?m ccing cabal-devel, as that list seems pertinent to this discussion too. In general I?m in favor of unifying efforts such as this.

For windows, I?d still like the _option_ to get prebuilt library binaries for the full platform db. The modularity means that they can be just downloaded in a separate folder now, rather than installed into e.g. the global db? If so, that?s a nice win. Here is my motivation ? I tried the minghc installer and it mainly worked, but it played terribly with cygwin, which I use pervasively. So I found myself in a situation where one set of paths worked with cygwin, and the other set of paths let me build the network library. I still have some anxieties about those sorts of issues, and being able to ?just download the binaries? would make me feel a bit safer about at least one workaround should things get too muddled up.

If we synchronize LTS and ?platform libs,? then I would like A) some way of distinguishing ?blessed platform libs? from ?other libs in LTS? (to solve the ?curation problem? which has always been a goal of the platform) and B) a standardized release schedule for LTS.

(And, of course, I assume this will _not_ be for the platform release upcoming, which is due very shortly, but we?ll have a longer lead time to integrate and shake out all the various issues and test, etc.)

?Gershom


On July 12, 2015 at 12:04:22 PM, Mark Lentczner (mark.lentczner at gmail.com) wrote:
> *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
> shipping pre-built packages, so we banish cabal hell, and have a single
> common way to 'get Haskell' that just works.*
>  
> At ICFP '14, there were several long group discussions of the state of
> "getting Haskell", including Haskell Platform, Stackage, and other
> approaches. Over the last year, there have been a few more public
> discussions and evolution on the ideas, and other installer developments.
> In particular, Stackage's LTS package sets are a direct development from
> this work, and the release of stack has offered new options.
>  
> Today, drawing from all this good work and ideas from so many, we'd would
> like to propose a concrete plan:
>  
> - Haskell Platform becomes the standard way to get *GHC* and related
> tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a
> user-friendly, cross-platform installer that gives a standard way to "get
> Haskell" for most users.
> - Use the *stack* model for package installation:
> - The global db has only the GHC packages
> - There is a package db for each curated set, Haskell Platform
> becomes one such set
> - Projects each have their own package db, much like sandboxes.
> - Haskell Platform's installer will no longer include pre-built,
> pre-installed packages other than GHC's set. Instead, it is configured so
> that *stack* can be used to build and install, on as needed, the
> corresponding Haskell Platform release packages.
>  
> We think this plan solves many different community needs:
>  
> - We have a clear way to "get Haskell" that works for a wide variety of
> use cases.
> - HP installer gets much smaller, and about as minimal as a working
> installation can get.
> - By leaving most packages out of the global database, users of
> cabal-install, will now have far fewer problems. Sandbox builds should now
> never give users "cabal hell" like warnings.
> - By building and installing the Platform packages into it's own package
> db, users get the benefit of building and installing these common packages
> only once per system, yet can easily bypass them for any given project if
> desired.
> - Since the Platform packages are now built and installed as needed,
> installing on smaller systems or servers without OpenGL will work.
>  
> To do this, we have a bit of work ahead of us: We need to settle on
> installation layout for each OS (including getting msys into the Windows
> installer); decide on the naming and versioning of the Platform package set
> (is it just LTS? does it have a different life cycle? etc...); getting
> *stack* ready such a distribution; and configuring (or updating)
> *cabal-install* to support the three-layer package db scheme. We think we
> can do this in short order.
>  
> We recognize this represents a significant change for the Platform, and
> will require buy-in from the various parts, especially *ghc*, *cabal*, and
> *stack*. We'd like to get your input.
>  
> - Michael & Mark
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>  


From mark.lentczner at gmail.com  Sun Jul 12 16:25:48 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sun, 12 Jul 2015 09:25:48 -0700
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <EA807597-BB2B-40D0-B6E3-BAE58759B7C8@gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <EA807597-BB2B-40D0-B6E3-BAE58759B7C8@gmail.com>
Message-ID: <CAAOoiFaDt8DbWOtaURA0_Xge7VPgaGStfJXqzCJ_oRvd53zrtw@mail.gmail.com>

No - we are not talking about the upcoming, 7.10.2 HP release. It would for
the next major release after that.

Yes, stack has only been out ~1 month, but it has already shown traction in
the community, and it has a clear working solution for managing "curated"
pacakge sets, like Haskell Platform.
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150712/37d52ae4/attachment.html>

From michael at snoyman.com  Sun Jul 12 16:26:57 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Sun, 12 Jul 2015 16:26:57 +0000
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <etPan.55a293c3.2cd6aab0.d112@mbp.local>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <etPan.55a293c3.2cd6aab0.d112@mbp.local>
Message-ID: <CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw@mail.gmail.com>

I'm +1 on nailing down an LTS release cycle, I've been pushing for it, and
planning that it would happen after the first few releases. I'm fine with
doing it starting with the next release if that's desired.

The cygwin/msys conflict is a problematic one. stack has more flexibility
addressing this than MinGHC did, since stack can control the PATH more
directly. What we do now is, by default, add msys to the beginning of the
PATH, and provide a command line option to not use msys at all. I believe
this combination has addressed the bug reports we've received in the past.

That's not to say I'm opposed to generating binary databases; I'm actually
in favor of having that option for all platforms at some point (there's an
open stack issue about it[1]). But it's a significant amount of work, and I
think if possible we should defer it until we've figured out initial
integration points.

[1] https://github.com/commercialhaskell/stack/issues/117

On Sun, Jul 12, 2015 at 9:20 AM Gershom B <gershomb at gmail.com> wrote:

> I?m ccing cabal-devel, as that list seems pertinent to this discussion
> too. In general I?m in favor of unifying efforts such as this.
>
> For windows, I?d still like the _option_ to get prebuilt library binaries
> for the full platform db. The modularity means that they can be just
> downloaded in a separate folder now, rather than installed into e.g. the
> global db? If so, that?s a nice win. Here is my motivation ? I tried the
> minghc installer and it mainly worked, but it played terribly with cygwin,
> which I use pervasively. So I found myself in a situation where one set of
> paths worked with cygwin, and the other set of paths let me build the
> network library. I still have some anxieties about those sorts of issues,
> and being able to ?just download the binaries? would make me feel a bit
> safer about at least one workaround should things get too muddled up.
>
> If we synchronize LTS and ?platform libs,? then I would like A) some way
> of distinguishing ?blessed platform libs? from ?other libs in LTS? (to
> solve the ?curation problem? which has always been a goal of the platform)
> and B) a standardized release schedule for LTS.
>
> (And, of course, I assume this will _not_ be for the platform release
> upcoming, which is due very shortly, but we?ll have a longer lead time to
> integrate and shake out all the various issues and test, etc.)
>
> ?Gershom
>
>
> On July 12, 2015 at 12:04:22 PM, Mark Lentczner (mark.lentczner at gmail.com)
> wrote:
> > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
> > shipping pre-built packages, so we banish cabal hell, and have a single
> > common way to 'get Haskell' that just works.*
> >
> > At ICFP '14, there were several long group discussions of the state of
> > "getting Haskell", including Haskell Platform, Stackage, and other
> > approaches. Over the last year, there have been a few more public
> > discussions and evolution on the ideas, and other installer developments.
> > In particular, Stackage's LTS package sets are a direct development from
> > this work, and the release of stack has offered new options.
> >
> > Today, drawing from all this good work and ideas from so many, we'd would
> > like to propose a concrete plan:
> >
> > - Haskell Platform becomes the standard way to get *GHC* and related
> > tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a
> > user-friendly, cross-platform installer that gives a standard way to "get
> > Haskell" for most users.
> > - Use the *stack* model for package installation:
> > - The global db has only the GHC packages
> > - There is a package db for each curated set, Haskell Platform
> > becomes one such set
> > - Projects each have their own package db, much like sandboxes.
> > - Haskell Platform's installer will no longer include pre-built,
> > pre-installed packages other than GHC's set. Instead, it is configured so
> > that *stack* can be used to build and install, on as needed, the
> > corresponding Haskell Platform release packages.
> >
> > We think this plan solves many different community needs:
> >
> > - We have a clear way to "get Haskell" that works for a wide variety of
> > use cases.
> > - HP installer gets much smaller, and about as minimal as a working
> > installation can get.
> > - By leaving most packages out of the global database, users of
> > cabal-install, will now have far fewer problems. Sandbox builds should
> now
> > never give users "cabal hell" like warnings.
> > - By building and installing the Platform packages into it's own package
> > db, users get the benefit of building and installing these common
> packages
> > only once per system, yet can easily bypass them for any given project if
> > desired.
> > - Since the Platform packages are now built and installed as needed,
> > installing on smaller systems or servers without OpenGL will work.
> >
> > To do this, we have a bit of work ahead of us: We need to settle on
> > installation layout for each OS (including getting msys into the Windows
> > installer); decide on the naming and versioning of the Platform package
> set
> > (is it just LTS? does it have a different life cycle? etc...); getting
> > *stack* ready such a distribution; and configuring (or updating)
> > *cabal-install* to support the three-layer package db scheme. We think we
> > can do this in short order.
> >
> > We recognize this represents a significant change for the Platform, and
> > will require buy-in from the various parts, especially *ghc*, *cabal*,
> and
> > *stack*. We'd like to get your input.
> >
> > - Michael & Mark
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150712/a81f3402/attachment.html>

From lemming at henning-thielemann.de  Sun Jul 12 16:40:46 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 12 Jul 2015 18:40:46 +0200 (CEST)
Subject: Using newtypes or any data with unboxed Vectors
In-Reply-To: <CACsFjbxDc7MGm6Ln9aWzj0dpWKTvMVGhktWAZqa=O9koi3wMLA@mail.gmail.com>
References: <CACsFjbxDc7MGm6Ln9aWzj0dpWKTvMVGhktWAZqa=O9koi3wMLA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1507121839310.7550@sputnik>



On Sun, 12 Jul 2015, Ken Bateman wrote:

> newtype SmallPos = Pos Int
> ? ? deriving (Eq, Ord, Show)
> 
> smallPos :: Int -> SmallPos
> smallPos x | x > 0 && x < 100 = Pos x
> ? ? ? ? ? ?| otherwise = error "bad SmallPos"
> 
> instance UnboxEquivalent SmallPos where
> ? ? type UnboxEquiv SmallPos = Word8
> ? ? toUnbox (Pos x) = fromIntegral x
> ? ? fromUnbox x = (Pos (fromIntegral x))


I assume that something like this is already possible with the Unbox type 
class, but currently I cannot see how. :-(

From danburton.email at gmail.com  Sun Jul 12 17:11:24 2015
From: danburton.email at gmail.com (Dan Burton)
Date: Sun, 12 Jul 2015 10:11:24 -0700
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw@mail.gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <etPan.55a293c3.2cd6aab0.d112@mbp.local>
 <CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw@mail.gmail.com>
Message-ID: <CALSygwfNjyxWFL0y4-_5aSyZZVQSeb5705MzZnaM4Q7GA2MLBg@mail.gmail.com>

Stack has the capability of downloading and installing GHC on demand, as
well as auto-updating itself. Both of these features, by default, occur in
subdirectories of the user's home directory. (Slightly different on Windows
but same idea.) Would the Platform install GHC to the stack location
directly, or install it system-wide as previously? (Stack can still make
use of GHC anywhere on your path.)

On Sunday, July 12, 2015, Michael Snoyman <michael at snoyman.com> wrote:

> I'm +1 on nailing down an LTS release cycle, I've been pushing for it, and
> planning that it would happen after the first few releases. I'm fine with
> doing it starting with the next release if that's desired.
>
> The cygwin/msys conflict is a problematic one. stack has more flexibility
> addressing this than MinGHC did, since stack can control the PATH more
> directly. What we do now is, by default, add msys to the beginning of the
> PATH, and provide a command line option to not use msys at all. I believe
> this combination has addressed the bug reports we've received in the past.
>
> That's not to say I'm opposed to generating binary databases; I'm actually
> in favor of having that option for all platforms at some point (there's an
> open stack issue about it[1]). But it's a significant amount of work, and I
> think if possible we should defer it until we've figured out initial
> integration points.
>
> [1] https://github.com/commercialhaskell/stack/issues/117
>
> On Sun, Jul 12, 2015 at 9:20 AM Gershom B <gershomb at gmail.com
> <javascript:_e(%7B%7D,'cvml','gershomb at gmail.com');>> wrote:
>
>> I?m ccing cabal-devel, as that list seems pertinent to this discussion
>> too. In general I?m in favor of unifying efforts such as this.
>>
>> For windows, I?d still like the _option_ to get prebuilt library binaries
>> for the full platform db. The modularity means that they can be just
>> downloaded in a separate folder now, rather than installed into e.g. the
>> global db? If so, that?s a nice win. Here is my motivation ? I tried the
>> minghc installer and it mainly worked, but it played terribly with cygwin,
>> which I use pervasively. So I found myself in a situation where one set of
>> paths worked with cygwin, and the other set of paths let me build the
>> network library. I still have some anxieties about those sorts of issues,
>> and being able to ?just download the binaries? would make me feel a bit
>> safer about at least one workaround should things get too muddled up.
>>
>> If we synchronize LTS and ?platform libs,? then I would like A) some way
>> of distinguishing ?blessed platform libs? from ?other libs in LTS? (to
>> solve the ?curation problem? which has always been a goal of the platform)
>> and B) a standardized release schedule for LTS.
>>
>> (And, of course, I assume this will _not_ be for the platform release
>> upcoming, which is due very shortly, but we?ll have a longer lead time to
>> integrate and shake out all the various issues and test, etc.)
>>
>> ?Gershom
>>
>>
>> On July 12, 2015 at 12:04:22 PM, Mark Lentczner (mark.lentczner at gmail.com
>> <javascript:_e(%7B%7D,'cvml','mark.lentczner at gmail.com');>) wrote:
>> > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
>> > shipping pre-built packages, so we banish cabal hell, and have a single
>> > common way to 'get Haskell' that just works.*
>> >
>> > At ICFP '14, there were several long group discussions of the state of
>> > "getting Haskell", including Haskell Platform, Stackage, and other
>> > approaches. Over the last year, there have been a few more public
>> > discussions and evolution on the ideas, and other installer
>> developments.
>> > In particular, Stackage's LTS package sets are a direct development from
>> > this work, and the release of stack has offered new options.
>> >
>> > Today, drawing from all this good work and ideas from so many, we'd
>> would
>> > like to propose a concrete plan:
>> >
>> > - Haskell Platform becomes the standard way to get *GHC* and related
>> > tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a
>> > user-friendly, cross-platform installer that gives a standard way to
>> "get
>> > Haskell" for most users.
>> > - Use the *stack* model for package installation:
>> > - The global db has only the GHC packages
>> > - There is a package db for each curated set, Haskell Platform
>> > becomes one such set
>> > - Projects each have their own package db, much like sandboxes.
>> > - Haskell Platform's installer will no longer include pre-built,
>> > pre-installed packages other than GHC's set. Instead, it is configured
>> so
>> > that *stack* can be used to build and install, on as needed, the
>> > corresponding Haskell Platform release packages.
>> >
>> > We think this plan solves many different community needs:
>> >
>> > - We have a clear way to "get Haskell" that works for a wide variety of
>> > use cases.
>> > - HP installer gets much smaller, and about as minimal as a working
>> > installation can get.
>> > - By leaving most packages out of the global database, users of
>> > cabal-install, will now have far fewer problems. Sandbox builds should
>> now
>> > never give users "cabal hell" like warnings.
>> > - By building and installing the Platform packages into it's own package
>> > db, users get the benefit of building and installing these common
>> packages
>> > only once per system, yet can easily bypass them for any given project
>> if
>> > desired.
>> > - Since the Platform packages are now built and installed as needed,
>> > installing on smaller systems or servers without OpenGL will work.
>> >
>> > To do this, we have a bit of work ahead of us: We need to settle on
>> > installation layout for each OS (including getting msys into the Windows
>> > installer); decide on the naming and versioning of the Platform package
>> set
>> > (is it just LTS? does it have a different life cycle? etc...); getting
>> > *stack* ready such a distribution; and configuring (or updating)
>> > *cabal-install* to support the three-layer package db scheme. We think
>> we
>> > can do this in short order.
>> >
>> > We recognize this represents a significant change for the Platform, and
>> > will require buy-in from the various parts, especially *ghc*, *cabal*,
>> and
>> > *stack*. We'd like to get your input.
>> >
>> > - Michael & Mark
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> <javascript:_e(%7B%7D,'cvml','Libraries at haskell.org');>
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> <javascript:_e(%7B%7D,'cvml','ghc-devs at haskell.org');>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "haskell-stack" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to haskell-stack+unsubscribe at googlegroups.com
> <javascript:_e(%7B%7D,'cvml','haskell-stack%2Bunsubscribe at googlegroups.com');>
> .
> To post to this group, send email to haskell-stack at googlegroups.com
> <javascript:_e(%7B%7D,'cvml','haskell-stack at googlegroups.com');>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/haskell-stack/CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw%40mail.gmail.com
> <https://groups.google.com/d/msgid/haskell-stack/CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
-- Dan Burton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150712/2d690729/attachment-0001.html>

From michael at snoyman.com  Sun Jul 12 17:13:37 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Sun, 12 Jul 2015 17:13:37 +0000
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <CALSygwfNjyxWFL0y4-_5aSyZZVQSeb5705MzZnaM4Q7GA2MLBg@mail.gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <etPan.55a293c3.2cd6aab0.d112@mbp.local>
 <CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw@mail.gmail.com>
 <CALSygwfNjyxWFL0y4-_5aSyZZVQSeb5705MzZnaM4Q7GA2MLBg@mail.gmail.com>
Message-ID: <CAKA2JgLS0w-tqTaSMRWezTCzR5FoHZ790wAoqSiyxPL1cq0tZg@mail.gmail.com>

I think it depends somewhat on operating system, since there are
permissions issues to be dealt with regarding user vs global installation.
In principle though: I think the HP installers would install to a
non-stack-specific location, and then stack would simply use that GHC based
on its inclusion in the PATH. (I'm also guessing this will tie in nicely
with Linux distro packages, which would likely want ghc to live in
/usr/bin).

On Sun, Jul 12, 2015 at 10:11 AM Dan Burton <danburton.email at gmail.com>
wrote:

> Stack has the capability of downloading and installing GHC on demand, as
> well as auto-updating itself. Both of these features, by default, occur in
> subdirectories of the user's home directory. (Slightly different on Windows
> but same idea.) Would the Platform install GHC to the stack location
> directly, or install it system-wide as previously? (Stack can still make
> use of GHC anywhere on your path.)
>
> On Sunday, July 12, 2015, Michael Snoyman <michael at snoyman.com> wrote:
>
>> I'm +1 on nailing down an LTS release cycle, I've been pushing for it,
>> and planning that it would happen after the first few releases. I'm fine
>> with doing it starting with the next release if that's desired.
>>
>> The cygwin/msys conflict is a problematic one. stack has more flexibility
>> addressing this than MinGHC did, since stack can control the PATH more
>> directly. What we do now is, by default, add msys to the beginning of the
>> PATH, and provide a command line option to not use msys at all. I believe
>> this combination has addressed the bug reports we've received in the past.
>>
>> That's not to say I'm opposed to generating binary databases; I'm
>> actually in favor of having that option for all platforms at some point
>> (there's an open stack issue about it[1]). But it's a significant amount of
>> work, and I think if possible we should defer it until we've figured out
>> initial integration points.
>>
>> [1] https://github.com/commercialhaskell/stack/issues/117
>>
>> On Sun, Jul 12, 2015 at 9:20 AM Gershom B <gershomb at gmail.com> wrote:
>>
>>> I?m ccing cabal-devel, as that list seems pertinent to this discussion
>>> too. In general I?m in favor of unifying efforts such as this.
>>>
>>> For windows, I?d still like the _option_ to get prebuilt library
>>> binaries for the full platform db. The modularity means that they can be
>>> just downloaded in a separate folder now, rather than installed into e.g.
>>> the global db? If so, that?s a nice win. Here is my motivation ? I tried
>>> the minghc installer and it mainly worked, but it played terribly with
>>> cygwin, which I use pervasively. So I found myself in a situation where one
>>> set of paths worked with cygwin, and the other set of paths let me build
>>> the network library. I still have some anxieties about those sorts of
>>> issues, and being able to ?just download the binaries? would make me feel a
>>> bit safer about at least one workaround should things get too muddled up.
>>>
>>> If we synchronize LTS and ?platform libs,? then I would like A) some way
>>> of distinguishing ?blessed platform libs? from ?other libs in LTS? (to
>>> solve the ?curation problem? which has always been a goal of the platform)
>>> and B) a standardized release schedule for LTS.
>>>
>>> (And, of course, I assume this will _not_ be for the platform release
>>> upcoming, which is due very shortly, but we?ll have a longer lead time to
>>> integrate and shake out all the various issues and test, etc.)
>>>
>>> ?Gershom
>>>
>>>
>>> On July 12, 2015 at 12:04:22 PM, Mark Lentczner (
>>> mark.lentczner at gmail.com) wrote:
>>> > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
>>> > shipping pre-built packages, so we banish cabal hell, and have a single
>>> > common way to 'get Haskell' that just works.*
>>> >
>>> > At ICFP '14, there were several long group discussions of the state of
>>> > "getting Haskell", including Haskell Platform, Stackage, and other
>>> > approaches. Over the last year, there have been a few more public
>>> > discussions and evolution on the ideas, and other installer
>>> developments.
>>> > In particular, Stackage's LTS package sets are a direct development
>>> from
>>> > this work, and the release of stack has offered new options.
>>> >
>>> > Today, drawing from all this good work and ideas from so many, we'd
>>> would
>>> > like to propose a concrete plan:
>>> >
>>> > - Haskell Platform becomes the standard way to get *GHC* and related
>>> > tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a
>>> > user-friendly, cross-platform installer that gives a standard way to
>>> "get
>>> > Haskell" for most users.
>>> > - Use the *stack* model for package installation:
>>> > - The global db has only the GHC packages
>>> > - There is a package db for each curated set, Haskell Platform
>>> > becomes one such set
>>> > - Projects each have their own package db, much like sandboxes.
>>> > - Haskell Platform's installer will no longer include pre-built,
>>> > pre-installed packages other than GHC's set. Instead, it is configured
>>> so
>>> > that *stack* can be used to build and install, on as needed, the
>>> > corresponding Haskell Platform release packages.
>>> >
>>> > We think this plan solves many different community needs:
>>> >
>>> > - We have a clear way to "get Haskell" that works for a wide variety of
>>> > use cases.
>>> > - HP installer gets much smaller, and about as minimal as a working
>>> > installation can get.
>>> > - By leaving most packages out of the global database, users of
>>> > cabal-install, will now have far fewer problems. Sandbox builds should
>>> now
>>> > never give users "cabal hell" like warnings.
>>> > - By building and installing the Platform packages into it's own
>>> package
>>> > db, users get the benefit of building and installing these common
>>> packages
>>> > only once per system, yet can easily bypass them for any given project
>>> if
>>> > desired.
>>> > - Since the Platform packages are now built and installed as needed,
>>> > installing on smaller systems or servers without OpenGL will work.
>>> >
>>> > To do this, we have a bit of work ahead of us: We need to settle on
>>> > installation layout for each OS (including getting msys into the
>>> Windows
>>> > installer); decide on the naming and versioning of the Platform
>>> package set
>>> > (is it just LTS? does it have a different life cycle? etc...); getting
>>> > *stack* ready such a distribution; and configuring (or updating)
>>> > *cabal-install* to support the three-layer package db scheme. We think
>>> we
>>> > can do this in short order.
>>> >
>>> > We recognize this represents a significant change for the Platform, and
>>> > will require buy-in from the various parts, especially *ghc*, *cabal*,
>>> and
>>> > *stack*. We'd like to get your input.
>>> >
>>> > - Michael & Mark
>>> > _______________________________________________
>>> > Libraries mailing list
>>> > Libraries at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>> >
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>  --
>>
> You received this message because you are subscribed to the Google Groups
>> "haskell-stack" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to haskell-stack+unsubscribe at googlegroups.com.
>> To post to this group, send email to haskell-stack at googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/haskell-stack/CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/haskell-stack/CAKA2JgKYuBMU5wtbjGV72dDKvSJePWbhoZeRCuJYR9SFoV8EDw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>
>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> -- Dan Burton
>
> --
> You received this message because you are subscribed to the Google Groups
> "haskell-stack" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to haskell-stack+unsubscribe at googlegroups.com.
> To post to this group, send email to haskell-stack at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/haskell-stack/CALSygwfNjyxWFL0y4-_5aSyZZVQSeb5705MzZnaM4Q7GA2MLBg%40mail.gmail.com
> <https://groups.google.com/d/msgid/haskell-stack/CALSygwfNjyxWFL0y4-_5aSyZZVQSeb5705MzZnaM4Q7GA2MLBg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150712/1ff86e34/attachment.html>

From amindfv at gmail.com  Sun Jul 12 19:07:42 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Sun, 12 Jul 2015 15:07:42 -0400
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <CAAOoiFaDt8DbWOtaURA0_Xge7VPgaGStfJXqzCJ_oRvd53zrtw@mail.gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <EA807597-BB2B-40D0-B6E3-BAE58759B7C8@gmail.com>
 <CAAOoiFaDt8DbWOtaURA0_Xge7VPgaGStfJXqzCJ_oRvd53zrtw@mail.gmail.com>
Message-ID: <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com>

The HP is a place for tools which have stabilized. A few reasons why I don't think stack is ready:

- stack has initial interest from the community, but so did ghc-dev and hsenv. It's still (imo) in proof of concept stage, and we don't know where its lessons will ultimately end up. In those other two cases, they ended up being folded into cabal, which is one likely scenario with stack.

- There are other solutions on the horizon! There's a GSOC project that will add nix-style package management to cabal. This should eliminate most (all?) the cabal hell we know and love, and that's why most stack users are trying it, no?

- The HP is for stable apis for users, too -- we provide tools that users won't have to unlearn or re-learn. Most languages don't have two package managers! We're clearly in an unstable state, which isn't when we should add to the HP.

If 9 months from now stack is clearly the right tool for the job (i.e. we're considering deprecating cabal), then I'd definitely consider supporting adding it to the HP but otherwise i'm strongly -1. (If it needs saying, I don't think stack is a bad tool).

tl;dr: The dust hasn't settled. Please don't add tools to the HP which we don't know will be in common use (in their current form) a year from now.

Tom


El Jul 12, 2015, a las 12:25, Mark Lentczner <mark.lentczner at gmail.com> escribi?:

> No - we are not talking about the upcoming, 7.10.2 HP release. It would for the next major release after that.
> 
> Yes, stack has only been out ~1 month, but it has already shown traction in the community, and it has a clear working solution for managing "curated" pacakge sets, like Haskell Platform.
> ?

From svenpanne at gmail.com  Sun Jul 12 19:08:07 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 12 Jul 2015 21:08:07 +0200
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
Message-ID: <CANBN=mtSJUJZaZtQjEJ5YxH85JYHsUqXGUy=TOjydAoBQzr-gA@mail.gmail.com>

2015-07-12 18:03 GMT+02:00 Mark Lentczner <mark.lentczner at gmail.com>:

>
>    - [...] Haskell Platform becomes the standard way to get *GHC* and
>    related tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. [...]
>
> What about haddock? I guess "GHC" implicitly means "haddock", too.

Apart from that +1, modulo some minor details which have already been
mentioned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150712/140d50b9/attachment-0001.html>

From greg at gregweber.info  Sun Jul 12 22:41:05 2015
From: greg at gregweber.info (Greg Weber)
Date: Sun, 12 Jul 2015 15:41:05 -0700
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <EA807597-BB2B-40D0-B6E3-BAE58759B7C8@gmail.com>
 <CAAOoiFaDt8DbWOtaURA0_Xge7VPgaGStfJXqzCJ_oRvd53zrtw@mail.gmail.com>
 <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com>
Message-ID: <CAKRanNC605RTO4kP+Bm0WiAr6c4-sj9DeHQv4xD8PhprwuDRzA@mail.gmail.com>

The main reason I am using stack is for its support for building a project
containing multiple packages. There aren't any other tools that make this a
first-class concept that is easy to use and not buggy.
In addition, stack has a first-class concept of curated package sets. All
of these are required to have smooth installs in real world projects, and
they aren't likely to appear in cabal-install in a short time frame.

On the other hand, stack already has good package distribution.
But providing both cabal-install and stack is the right choice that helps
keep the Haskell platform relevant and avoid new users having to go through
multiple installation steps.

On Sun, Jul 12, 2015 at 12:07 PM, <amindfv at gmail.com> wrote:

> The HP is a place for tools which have stabilized. A few reasons why I
> don't think stack is ready:
>
> - stack has initial interest from the community, but so did ghc-dev and
> hsenv. It's still (imo) in proof of concept stage, and we don't know where
> its lessons will ultimately end up. In those other two cases, they ended up
> being folded into cabal, which is one likely scenario with stack.
>
> - There are other solutions on the horizon! There's a GSOC project that
> will add nix-style package management to cabal. This should eliminate most
> (all?) the cabal hell we know and love, and that's why most stack users are
> trying it, no?
>
> - The HP is for stable apis for users, too -- we provide tools that users
> won't have to unlearn or re-learn. Most languages don't have two package
> managers! We're clearly in an unstable state, which isn't when we should
> add to the HP.
>
> If 9 months from now stack is clearly the right tool for the job (i.e.
> we're considering deprecating cabal), then I'd definitely consider
> supporting adding it to the HP but otherwise i'm strongly -1. (If it needs
> saying, I don't think stack is a bad tool).
>
> tl;dr: The dust hasn't settled. Please don't add tools to the HP which we
> don't know will be in common use (in their current form) a year from now.
>
> Tom
>
>
> El Jul 12, 2015, a las 12:25, Mark Lentczner <mark.lentczner at gmail.com>
> escribi?:
>
> > No - we are not talking about the upcoming, 7.10.2 HP release. It would
> for the next major release after that.
> >
> > Yes, stack has only been out ~1 month, but it has already shown traction
> in the community, and it has a clear working solution for managing
> "curated" pacakge sets, like Haskell Platform.
> > ?
> _______________________________________________
> 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/20150712/6f67a8d9/attachment.html>

From _deepfire at feelingofgreen.ru  Mon Jul 13 07:34:56 2015
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Mon, 13 Jul 2015 10:34:56 +0300
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <CAKRanNC605RTO4kP+Bm0WiAr6c4-sj9DeHQv4xD8PhprwuDRzA@mail.gmail.com>
 (sfid-20150713_025906_089807_74007A47) (Greg Weber's message of "Sun,
 12 Jul 2015 15:41:05 -0700")
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <EA807597-BB2B-40D0-B6E3-BAE58759B7C8@gmail.com>
 <CAAOoiFaDt8DbWOtaURA0_Xge7VPgaGStfJXqzCJ_oRvd53zrtw@mail.gmail.com>
 <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com>
 <CAKRanNC605RTO4kP+Bm0WiAr6c4-sj9DeHQv4xD8PhprwuDRzA@mail.gmail.com>
Message-ID: <878uakpl27.fsf@andromedae.feelingofgreen.ru>

Greg Weber <greg at gregweber.info> writes:
> The main reason I am using stack is for its support for building a project
> containing multiple packages. There aren't any other tools that make this a
> first-class concept that is easy to use and not buggy.
> In addition, stack has a first-class concept of curated package sets. All of these
> are required to have smooth installs in real world projects, and they aren't
> likely to appear in cabal-install in a short time frame.

The problem that I'm personally facing all too often, is exploratory
development, where the modus operandi is to try using versions/branches
that are not yet released on Hackage.

Things like this happen especially during GHC version transitions, where
ghc-new buildability of libraries/tools is often in flux, and so you
/have/ to chase the tail (or is it HEAD?).

As an example, the version of ghc-mod that works with 7.10 is still
unreleased on Cabal -- months passed, the prospects still indefinite.

But it also happens out of plain curiosity and willingness to try out
how new things could affect the way of problem expression.

For an example of that, let's take the 'nokinds' branch of GHC, where
Richard Eisenberg does research on formulating GHC with dependent types.

Another situation where these things matter especially is collaborative
development -- trying to help with bugs, for example.

All these things ring of the same, actually..

..where Hackage puts a mild barrier to sharing small contributions with
the world, Stack puts a wall.

Which is a good thing.

But also a bad one.

..and unless I'm wrong, and we're indeed moving to a world where people would
increasingly use Stack, this dichotomy is /bound/ to become more pressing.

Curiously, there's a technology to solve to both sides of the story -- Nix,
which was mentioned before, but I think its salient point applies especially
well to this dichotomy:

 1. use the existing curated releases, but also can
 2. override packages with a Github fork URL, commit id and the physical
    checkout hash -- and have everything pick it up in a transparent, fixpoint way.

Admittedly it's not been made as trivial to use -- there's more moving
parts to factor, and up until now there just wasn't any party seriously
interested in doing the user-facing parts.

..And so, I can't help but wonder.. what if the Stack authors would have
applied their expertise to provide the same user experience they
achieved..

..but with Nix as an underlying technology?

-- 
respectfully,
??????? ??????

From ivan.miljenovic at gmail.com  Mon Jul 13 08:07:10 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Mon, 13 Jul 2015 18:07:10 +1000
Subject: To all users of FGL
Message-ID: <CA+u6gbyTUANsRDXE5ZbiYg9=qxWt+wRdQ9CEUGg2S43n_0nGsw@mail.gmail.com>

As you may now, for the past few months I've been (finally!) cleaning
up FGL, adding tests, etc.

One of the issues that has arisen with this is that the behaviour of
the delLEdge [1] function is not well specified when dealing with
multiple edges.

Specifically, the documentation states that the purpose is to "Remove
*an* LEdge from the Graph." (emphasis added)... but the behaviour when
dealing with multiple edges is to remove *all* such edges from the
graph.

The current version on GitHub is to instead just delete a single such
labelled edge, with a new function "delAllLEdge" that replicates the
current behaviour.

Before releasing this change, however, I wanted to make sure that I
wouldn't break people's code if they rely upon this functionality; I
did try and search through GitHub to see who - if anyone - is using
this function, but primarily found various copies of fgl embedded into
other people's repositories.

As such, please check your code and let me know if this change in
behaviour might affect you (if this is the case, I might let delLEdge
keep the current behaviour and have a new function delete just one
edge).

[1]: http://hackage.haskell.org/package/fgl-5.5.1.0/docs/Data-Graph-Inductive-Graph.html#v:delLEdge

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

From duncan.coutts at googlemail.com  Mon Jul 13 12:12:32 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Mon, 13 Jul 2015 13:12:32 +0100
Subject: QuickCheck failures with new 'tar' release...
In-Reply-To: <877fq9vx8h.fsf@ironicdesign.com>
References: <877fq9vx8h.fsf@ironicdesign.com>
Message-ID: <1436789552.26857.445.camel@googlemail.com>

On Thu, 2015-07-09 at 17:26 -0400, Michael Alan Dorman wrote:
> I'm not sure if there's a more appropriate venue to bring this up; the
> package doesn't seem to have any sort of explicit issue tracker.
> 
> On the NixOS build servers, we're seeing across-the-board failures for
> the 0.4.2.0 release of the 'tar' library, specifically, two properties
> that were added in the latest release.
> 
> It looks to me like prop_lookup is fundamentally broken---it falls over
> in the face of a lookup for 'a/b' in a list of entries that includes
> 'a/b/c/d', because while the library lookup function returns a match
> including the remainder of the path as a result, the Data.List.lookup
> that it's comparing against returns nothing.
> 
> I don't see a way for the test as it is constituted to work reliably.
> I'm going to guess that prop_valid suffers from a similar issue.
> 
> Either way, it would be nice if they could either be corrected, or diked
> out until that happens.

Cheers, yes my mistake. I'll fix the test and do a minor release.

Duncan


From allbery.b at gmail.com  Mon Jul 13 12:49:58 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 13 Jul 2015 08:49:58 -0400
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <878uakpl27.fsf@andromedae.feelingofgreen.ru>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <EA807597-BB2B-40D0-B6E3-BAE58759B7C8@gmail.com>
 <CAAOoiFaDt8DbWOtaURA0_Xge7VPgaGStfJXqzCJ_oRvd53zrtw@mail.gmail.com>
 <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com>
 <CAKRanNC605RTO4kP+Bm0WiAr6c4-sj9DeHQv4xD8PhprwuDRzA@mail.gmail.com>
 <878uakpl27.fsf@andromedae.feelingofgreen.ru>
Message-ID: <CAKFCL4VM9cwzn+McO3Z6-yaiSKrUs2Q6=OdiJqS+e46-uX0NCw@mail.gmail.com>

On Mon, Jul 13, 2015 at 3:34 AM, Kosyrev Serge <_deepfire at feelingofgreen.ru>
wrote:

> ..And so, I can't help but wonder.. what if the Stack authors would have
> applied their expertise to provide the same user experience they
> achieved..
>
> ..but with Nix as an underlying technology?
>

Backpack (very roughly, a Nix-like Cabal package mechanism) is still in
development. Once it's out there, perhaps FPComplete will look into using
it with Stack?

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150713/3864e106/attachment.html>

From greg at gregweber.info  Mon Jul 13 13:34:58 2015
From: greg at gregweber.info (Greg Weber)
Date: Mon, 13 Jul 2015 06:34:58 -0700
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <878uakpl27.fsf@andromedae.feelingofgreen.ru>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <EA807597-BB2B-40D0-B6E3-BAE58759B7C8@gmail.com>
 <CAAOoiFaDt8DbWOtaURA0_Xge7VPgaGStfJXqzCJ_oRvd53zrtw@mail.gmail.com>
 <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com>
 <CAKRanNC605RTO4kP+Bm0WiAr6c4-sj9DeHQv4xD8PhprwuDRzA@mail.gmail.com>
 <878uakpl27.fsf@andromedae.feelingofgreen.ru>
Message-ID: <CAKRanNCDTQDGLBkeHvk8S17gXD4Y2K1yqRhNYTS-8O89RCjT9A@mail.gmail.com>

On Mon, Jul 13, 2015 at 12:34 AM, Kosyrev Serge <_deepfire at feelingofgreen.ru
> wrote:

> Greg Weber <greg at gregweber.info> writes:
> > The main reason I am using stack is for its support for building a
> project
> > containing multiple packages. There aren't any other tools that make
> this a
> > first-class concept that is easy to use and not buggy.
> > In addition, stack has a first-class concept of curated package sets.
> All of these
> > are required to have smooth installs in real world projects, and they
> aren't
> > likely to appear in cabal-install in a short time frame.
>
> The problem that I'm personally facing all too often, is exploratory
> development, where the modus operandi is to try using versions/branches
> that are not yet released on Hackage.
>
> Things like this happen especially during GHC version transitions, where
> ghc-new buildability of libraries/tools is often in flux, and so you
> /have/ to chase the tail (or is it HEAD?).
>
> As an example, the version of ghc-mod that works with 7.10 is still
> unreleased on Cabal -- months passed, the prospects still indefinite.
>
> But it also happens out of plain curiosity and willingness to try out
> how new things could affect the way of problem expression.
>
> For an example of that, let's take the 'nokinds' branch of GHC, where
> Richard Eisenberg does research on formulating GHC with dependent types.
>
> Another situation where these things matter especially is collaborative
> development -- trying to help with bugs, for example.
>
> All these things ring of the same, actually..
>
> ..where Hackage puts a mild barrier to sharing small contributions with
> the world, Stack puts a wall.
>

I think you are using the wrong terminology. You probably mean to compare
"stackage" with "Hackage".
But your replly is supposed to be about "stack", which has first-class
support for building packages that are not on Hackage as part of your
project, including fetching the package from github for you.
https://github.com/commercialhaskell/stack/wiki/stack.yaml#project-config


> Which is a good thing.
>
> But also a bad one.
>
> ..and unless I'm wrong, and we're indeed moving to a world where people
> would
> increasingly use Stack, this dichotomy is /bound/ to become more pressing.
>
> Curiously, there's a technology to solve to both sides of the story -- Nix,
> which was mentioned before, but I think its salient point applies
> especially
> well to this dichotomy:
>
>  1. use the existing curated releases, but also can
>  2. override packages with a Github fork URL, commit id and the physical
>     checkout hash -- and have everything pick it up in a transparent,
> fixpoint way.
>

Again, there is already support for this in stack. Give it a try.


> Admittedly it's not been made as trivial to use -- there's more moving
> parts to factor, and up until now there just wasn't any party seriously
> interested in doing the user-facing parts.
>
> ..And so, I can't help but wonder.. what if the Stack authors would have
> applied their expertise to provide the same user experience they
> achieved..
>
> ..but with Nix as an underlying technology?
>

Then stack would be forcing Windows users to use cygwin


>
> --
> respectfully,
> ??????? ??????
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150713/3ca78381/attachment.html>

From duncan.coutts at googlemail.com  Tue Jul 14 12:52:46 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue, 14 Jul 2015 13:52:46 +0100
Subject: Request for feedback on spec/proposal for distributing package
 collections via hackage
Message-ID: <1436878366.26857.532.camel@googlemail.com>

Hi folks,

I'd like to get feedback on a spec/proposal for distributing package
collections via hackage. This is currently somewhere beyond vapourware
but certainly not a fait accompli and hopefully it is at an appropriate
point to get feedback.

The basic idea is that package collections are:
      * useful (IMHO, one of the top two solutions to dependency hell,
        alongside nix-style package management); and
      * just as we distribute packages via hackage, we should also be
        able to easily distribute package collections.

One would then use them with tools like cabal and stack. Distributing
via hackage (both in the sense of the format/protocol and in the sense
of the central community hackage instance) seems natural, and allows
taking advantage of much of the infrastructure we have for packages
already like:
      * existing user accounts and management infrastructure on the
        hackage website
      * allowing anyone to host collections on their own servers, just
        as they can host their own package archives currently (either as
        static file sets or with smart servers)
      * low barrier for distribution, potentially encouraging more
        collections to be created potentially covering more use cases
      * security infrastructure (currently in alpha)
      * automatic mirroring (currently in alpha)

Two obvious examples are stackage-lts and stackage-nightly but if we
lower the barrier for distribution then there may well be many more. For
example, the existing Linux distros put a lot of effort into selecting
and maintain package collections, and some of these collections could be
distributed via hackage. In fast several Linux distributions already use
Hackage's "distro" feature to advertise which versions of packages are
provided by that distro. One can also imagine special-purpose
collections, and there's probably cases we've not thought of yet.

Package collections are different things from packages, not like "meta
packages" that one gets in some package systems. A package collection at
it's simplest is just a set of source package identifiers (ie
names-version pairs). Like packages, package collections have names and
versions and are immutable once distributed.

The intention is that users can configure their tool to use
collection(s), either by nailing down a specific collection version, or
by not specifying a version it would default to the latest version of
the named collection. (But the specific behaviour is up to the tool)

Use cases:

      * versioned collections. For some collections the policy by which
        it's defined naturally uses meaningful versions.
      * daily collections. These can have a date-form version number
        imposed on them.
      * "live" "rolling" collections. These could have a simple
        monotonic increasing version with no particular meaning
        attached. For such collections, clients might be configured to
        use the latest (by not specifying a version), but it's always
        possible to pick a specific revision.
      * special-purpose collections. Not necessarily collections aiming
        to cover a large number of common packages, but aiming to cover
        some application area, or related stack of packages (e.g. some
        of the web frameworks).
      * negative collections. Collections of packages you may
        specifically want to avoid (e.g. deprecated by their authors, or
        known-broken). Using such collections would rely on clients that
        can be configured to treat it negatively.

Specifics:

A package collection specifies a set of source package ids (id being
name-version pair). It also optionally specifies a (partial) flag
assignment for any package name.

The collection does not specify how tools should treat them. That is, a
collection does not specify if it should be treated as a strong or a
soft constraint, inclusive or exclusive, positive or negative. Such
things are completely up to the client's policy and configuration.
Similarly for flag assignments, collections do not specify whether tools
should interpret these as strong or soft constraints.

Syntax:

Package collection names and versions exactly follow those of package
names (but they live in a different namespace). For example,
"stackage-lts-2.9", or "deprecated-343" (the latter being a "rolling"
collection with a meaningless monotonically increasing version).

A collection distributed in the archive format is just a text file with
one entry per line, such as:

        foo-1.0
        foo-1.1
        bar >= 3 && < 4
        bar +this -that

So each line can be one of:
      * a simple package id
      * a package version range, using Cabal version range syntax
      * a package name with a flag assignment, + for on, - for off

The interpretation of the above is that:
      * both foo-1.0 and foo-1.1 are in the collection (ie union not
        intersection)
      * all versions of bar between 3 and 4 are in the collection
      * the package bar has flag 'this' as True, and flag 'that' as
        False

Of course for some collections the policy is that only one version of
any package is included, but this is a policy question and the format
itself does not impose this constraint.

Hackage archive format:

collection files live under a different prefix from package tarballs
(but are still considered part of the archive) and are named after the
collection id. The collection files are not compressed (but of course
http clients and servers can negotiate transport compression). The
collection files are not included in nor listed in the existing
00-index.tar.gz, but there's other json format metadata for a client to
enumerate the available collections and versions. And like with package
tarballs, a client that wants a specific collection version can
construct the url and fetch it directly.

Security:

The hackage security system that's currently in alpha testing can easily
be extended to cover collections, similarly to how it covers package
tarballs.

Misc notes:

There is no requirement that a hackage-format repo containing
collections be closed. That is, the collections may refer to packages
not in that archive. This could be useful for private hackage repos that
host a small number of private packages, but also host collections that
refer both to the private packages and public ones from the community
central hackage. The resolution of package names is done by the clients,
and some clients may be configured to union/overlay multiple repos.

On the other hand, for the central community hackage it may be sensible
to enforce a policy that the collections it distributes be closed (ie
refer only to packages distributed via hackage).

Questions:

Is this sufficiently flexible to fully cover the obvious use cases? Are
there any interesting use cases that are excluded?

Anything else?


Duncan


From ezyang at mit.edu  Tue Jul 14 19:02:12 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 14 Jul 2015 12:02:12 -0700
Subject: Request for feedback on spec/proposal for distributing package
 collections via hackage
In-Reply-To: <1436878366.26857.532.camel@googlemail.com>
References: <1436878366.26857.532.camel@googlemail.com>
Message-ID: <1436898968-sup-2927@sabre>

Hello Duncan,

In my eyes, this proposal looks like some sort of generalization of
Stackage; and one further use case is "special purpose" collection.  My
big question: how composable are these collections really?  I can't put
two collections with conflicting versions together (or can I? Do I
union?); and is there any point to having a collection without versions
in it? (If Cabal syntax is extended to support depending on collections
as well as packages, yes?)

The classic use-case for package collections is deployment settings, ala
Stack, or even Cargo lockfiles / Bundler Gemfile.lock (versioned
collections). In all these use-cases package collections are treated as
non-compositional things.  http://doc.crates.io/guide.html
http://bundler.io/v1.7/rationale.html#checking-your-code-into-version-control
Libraries (compositional) do NOT publish lockfiles: only executables
(non-compositional) DO.

Re the file format, it seems fine; suitable for the lockfile use-case
and the Stackage use-case.  Less sure about the unioning semantics.

Edward

Excerpts from Duncan Coutts's message of 2015-07-14 05:52:46 -0700:
> Hi folks,
> 
> I'd like to get feedback on a spec/proposal for distributing package
> collections via hackage. This is currently somewhere beyond vapourware
> but certainly not a fait accompli and hopefully it is at an appropriate
> point to get feedback.
> 
> The basic idea is that package collections are:
>       * useful (IMHO, one of the top two solutions to dependency hell,
>         alongside nix-style package management); and
>       * just as we distribute packages via hackage, we should also be
>         able to easily distribute package collections.
> 
> One would then use them with tools like cabal and stack. Distributing
> via hackage (both in the sense of the format/protocol and in the sense
> of the central community hackage instance) seems natural, and allows
> taking advantage of much of the infrastructure we have for packages
> already like:
>       * existing user accounts and management infrastructure on the
>         hackage website
>       * allowing anyone to host collections on their own servers, just
>         as they can host their own package archives currently (either as
>         static file sets or with smart servers)
>       * low barrier for distribution, potentially encouraging more
>         collections to be created potentially covering more use cases
>       * security infrastructure (currently in alpha)
>       * automatic mirroring (currently in alpha)
> 
> Two obvious examples are stackage-lts and stackage-nightly but if we
> lower the barrier for distribution then there may well be many more. For
> example, the existing Linux distros put a lot of effort into selecting
> and maintain package collections, and some of these collections could be
> distributed via hackage. In fast several Linux distributions already use
> Hackage's "distro" feature to advertise which versions of packages are
> provided by that distro. One can also imagine special-purpose
> collections, and there's probably cases we've not thought of yet.
> 
> Package collections are different things from packages, not like "meta
> packages" that one gets in some package systems. A package collection at
> it's simplest is just a set of source package identifiers (ie
> names-version pairs). Like packages, package collections have names and
> versions and are immutable once distributed.
> 
> The intention is that users can configure their tool to use
> collection(s), either by nailing down a specific collection version, or
> by not specifying a version it would default to the latest version of
> the named collection. (But the specific behaviour is up to the tool)
> 
> Use cases:
> 
>       * versioned collections. For some collections the policy by which
>         it's defined naturally uses meaningful versions.
>       * daily collections. These can have a date-form version number
>         imposed on them.
>       * "live" "rolling" collections. These could have a simple
>         monotonic increasing version with no particular meaning
>         attached. For such collections, clients might be configured to
>         use the latest (by not specifying a version), but it's always
>         possible to pick a specific revision.
>       * special-purpose collections. Not necessarily collections aiming
>         to cover a large number of common packages, but aiming to cover
>         some application area, or related stack of packages (e.g. some
>         of the web frameworks).
>       * negative collections. Collections of packages you may
>         specifically want to avoid (e.g. deprecated by their authors, or
>         known-broken). Using such collections would rely on clients that
>         can be configured to treat it negatively.
> 
> Specifics:
> 
> A package collection specifies a set of source package ids (id being
> name-version pair). It also optionally specifies a (partial) flag
> assignment for any package name.
> 
> The collection does not specify how tools should treat them. That is, a
> collection does not specify if it should be treated as a strong or a
> soft constraint, inclusive or exclusive, positive or negative. Such
> things are completely up to the client's policy and configuration.
> Similarly for flag assignments, collections do not specify whether tools
> should interpret these as strong or soft constraints.
> 
> Syntax:
> 
> Package collection names and versions exactly follow those of package
> names (but they live in a different namespace). For example,
> "stackage-lts-2.9", or "deprecated-343" (the latter being a "rolling"
> collection with a meaningless monotonically increasing version).
> 
> A collection distributed in the archive format is just a text file with
> one entry per line, such as:
> 
>         foo-1.0
>         foo-1.1
>         bar >= 3 && < 4
>         bar +this -that
> 
> So each line can be one of:
>       * a simple package id
>       * a package version range, using Cabal version range syntax
>       * a package name with a flag assignment, + for on, - for off
> 
> The interpretation of the above is that:
>       * both foo-1.0 and foo-1.1 are in the collection (ie union not
>         intersection)
>       * all versions of bar between 3 and 4 are in the collection
>       * the package bar has flag 'this' as True, and flag 'that' as
>         False
> 
> Of course for some collections the policy is that only one version of
> any package is included, but this is a policy question and the format
> itself does not impose this constraint.
> 
> Hackage archive format:
> 
> collection files live under a different prefix from package tarballs
> (but are still considered part of the archive) and are named after the
> collection id. The collection files are not compressed (but of course
> http clients and servers can negotiate transport compression). The
> collection files are not included in nor listed in the existing
> 00-index.tar.gz, but there's other json format metadata for a client to
> enumerate the available collections and versions. And like with package
> tarballs, a client that wants a specific collection version can
> construct the url and fetch it directly.
> 
> Security:
> 
> The hackage security system that's currently in alpha testing can easily
> be extended to cover collections, similarly to how it covers package
> tarballs.
> 
> Misc notes:
> 
> There is no requirement that a hackage-format repo containing
> collections be closed. That is, the collections may refer to packages
> not in that archive. This could be useful for private hackage repos that
> host a small number of private packages, but also host collections that
> refer both to the private packages and public ones from the community
> central hackage. The resolution of package names is done by the clients,
> and some clients may be configured to union/overlay multiple repos.
> 
> On the other hand, for the central community hackage it may be sensible
> to enforce a policy that the collections it distributes be closed (ie
> refer only to packages distributed via hackage).
> 
> Questions:
> 
> Is this sufficiently flexible to fully cover the obvious use cases? Are
> there any interesting use cases that are excluded?
> 
> Anything else?
> 
> 
> Duncan
> 

From duncan.coutts at googlemail.com  Tue Jul 14 19:48:18 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue, 14 Jul 2015 20:48:18 +0100
Subject: Request for feedback on spec/proposal for distributing package
 collections via hackage
In-Reply-To: <1436898968-sup-2927@sabre>
References: <1436878366.26857.532.camel@googlemail.com>
 <1436898968-sup-2927@sabre>
Message-ID: <1436903298.26857.563.camel@googlemail.com>

On Tue, 2015-07-14 at 12:02 -0700, Edward Z. Yang wrote:
> Hello Duncan,
> 
> In my eyes, this proposal looks like some sort of generalization of
> Stackage; and one further use case is "special purpose" collection.  My
> big question: how composable are these collections really?  I can't put
> two collections with conflicting versions together (or can I? Do I
> union?);

You're right that some use cases of collections only make sense if
clients can reasonably flexibly combine collections, e.g. set ops like
union, intersection and inversion or difference.

I think in principle taking collection unions or intersections makes
sense. For example, in stack, as I understand it, you can add a local
version of something that is also in the collection. This is of course a
union. So extending "narrow" collections by unioning them with extra
stuff makes sense. And suppose we had other "wide" collections that
didn't nail things down to just one version, then taking an intersection
with some other wide or narrow collection makes sense.

So in principle, these set-like operations make sense. The code we've
got in-progress for cabal-install allows exactly that. But none of that
is essential to make use of the general purpose collections like
stackage.

> and is there any point to having a collection without versions
> in it?

To be clear, every collection instance has a version. It's just that for
some of them -- live or rolling collections -- there is no particular
meaning to the version. So this thing about not specifying a version is
completely client side and doesn't affect the spec at all. It's just
worth pointing out as a use case.

As an example, we might have collections that are automagically defined
and updated based on some property of the packages. Those are unlikely
to have a meaningful version number.

> (If Cabal syntax is extended to support depending on collections
> as well as packages, yes?)

I don't think you're confused here, but just to clarify: packages do not
talk about collections. Tools like cabal/stack can be configured to use
collections.

And yes, where currently to configure cabal-install to use a collection
you have to explicitly list every member as a constraint in a
cabal.config file (see the cabal.config files distributed from the
stackage website), the extension in cabal-install is to support these
collections as a first class thing, by name-version or just name (and
with an expression language to combine them).

> The classic use-case for package collections is deployment settings, ala
> Stack, or even Cargo lockfiles / Bundler Gemfile.lock (versioned
> collections). In all these use-cases package collections are treated as
> non-compositional things.  http://doc.crates.io/guide.html
> http://bundler.io/v1.7/rationale.html#checking-your-code-into-version-control
> Libraries (compositional) do NOT publish lockfiles: only executables
> (non-compositional) DO.
> 
> Re the file format, it seems fine; suitable for the lockfile use-case
> and the Stackage use-case.  Less sure about the unioning semantics.

Right, collections and frozen settings are similar, and for the latter
composition doesn't make a lot of sense. We have the latter already of
course, in the form of "cabal freeze" cabal.config files, and similarly
for stack with .yml config files (which can be based off of pre-defined
collections). It's likely that cabal freeze will switch to use this
collection notation as it's somewhat more intentional (than the big sets
of raw constraints).

Duncan


From duncan.coutts at googlemail.com  Tue Jul 14 19:48:22 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue, 14 Jul 2015 20:48:22 +0100
Subject: Request for feedback on spec/proposal for distributing package
 collections via hackage
In-Reply-To: <1436878366.26857.532.camel@googlemail.com>
References: <1436878366.26857.532.camel@googlemail.com>
Message-ID: <1436903302.26857.564.camel@googlemail.com>

On Tue, 2015-07-14 at 13:52 +0100, Duncan Coutts wrote:

> Syntax:
> 
> Package collection names and versions exactly follow those of package
> names (but they live in a different namespace). For example,
> "stackage-lts-2.9", or "deprecated-343" (the latter being a "rolling"
> collection with a meaningless monotonically increasing version).
> 
> A collection distributed in the archive format is just a text file with
> one entry per line, such as:
> 
>         foo-1.0
>         foo-1.1
>         bar >= 3 && < 4
>         bar +this -that
> 
> So each line can be one of:
>       * a simple package id
>       * a package version range, using Cabal version range syntax
>       * a package name with a flag assignment, + for on, - for off

Oops, one thing I forgot to mention is another entry syntax:

        baz

That is, a package name with no version or range at all. This is
shorthand for the version range style with no version constraint (.cabal
files have a slightly odd syntax for that, "baz -any").

This is actually useful if you want to define a negative collection,
e.g. all the packages that are deprecated (as a whole, not just single
versions).

Duncan


From gershomb at gmail.com  Tue Jul 14 19:50:08 2015
From: gershomb at gmail.com (Gershom B)
Date: Tue, 14 Jul 2015 15:50:08 -0400
Subject: Request for feedback on spec/proposal for distributing package
 collections via hackage
In-Reply-To: <1436898968-sup-2927@sabre>
References: <1436878366.26857.532.camel@googlemail.com>
 <1436898968-sup-2927@sabre>
Message-ID: <CAM8RHpGUX_J7u_zvOAdOOSm3e-hRdqxY6vkLvopmKeZzfxmqdw@mail.gmail.com>

> and is there any point to having a collection without versions
in it? (If Cabal syntax is extended to support depending on collections
as well as packages, yes?)

So I think another use-case for collections, besides "version-locked",
is sets of "blessed" packages. So we might want a collection for
"verified compatible with windows 2008" or "platform packages" or
"works with nhc" to be collections.

And in those cases, specifying unique versions doesn't seem to make
much sense. And one could imagine taking intersections -- i.e.
"uhc-compatible _and_ in stackage LTS".

In general I like this proposal as very minimal in terms of just
providing and collecting data, and allowing that data to then be used
by clients in various ways.

--gershom


On Tue, Jul 14, 2015 at 3:02 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> Hello Duncan,
>
> In my eyes, this proposal looks like some sort of generalization of
> Stackage; and one further use case is "special purpose" collection.  My
> big question: how composable are these collections really?  I can't put
> two collections with conflicting versions together (or can I? Do I
> union?); and is there any point to having a collection without versions
> in it? (If Cabal syntax is extended to support depending on collections
> as well as packages, yes?)
>
> The classic use-case for package collections is deployment settings, ala
> Stack, or even Cargo lockfiles / Bundler Gemfile.lock (versioned
> collections). In all these use-cases package collections are treated as
> non-compositional things.  http://doc.crates.io/guide.html
> http://bundler.io/v1.7/rationale.html#checking-your-code-into-version-control
> Libraries (compositional) do NOT publish lockfiles: only executables
> (non-compositional) DO.
>
> Re the file format, it seems fine; suitable for the lockfile use-case
> and the Stackage use-case.  Less sure about the unioning semantics.
>
> Edward
>

From omeragacan at gmail.com  Wed Jul 15 15:56:23 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Wed, 15 Jul 2015 11:56:23 -0400
Subject: RFC for a change in EmptyDataDecls instance deriving
Message-ID: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>

# RFC for a change in EmptyDataDecls instance deriving

Hi all,

There were some requests about EmptyDataDecls instance deriving and recently I
made some progress towards implementing those. However as I implement things
people started suggesting different behaviors than what I've implemented etc.
In the end, we thought it'd be a good idea to ask libraries mailing list for
which behavior to implement.

# Summary

Haskell 2010 doesn't support data types without any constructors(aka. empty
data type)[1]. GHC supports it via EmptyDataDecls[2], but it fails to derive
instances:

    Decl.hs:3:18:
        Can't make a derived instance of ?Eq Z?:
          ?Z? must have at least one data constructor
          Possible fix: use a standalone deriving declaration instead
        In the data declaration for ?Z?

Using StandaloneDeriving works, and it generates methods that calls `error`:

    Derived instances:
      instance GHC.Classes.Eq Main.Z where
        (GHC.Classes.==) = GHC.Err.error "Void =="
        (GHC.Classes./=) a_aCf b_aCg
          = GHC.Classes.not ((GHC.Classes.==) a_aCf b_aCg)

Note that these methods fail in first applications. So `(==) a` is an error, it
doesn't need to be a fully saturated application.

Ticket 7401[3] asks for a change in default deriving mechanism. I submitted a
patch[4] that makes standard deriving work same as standalone deriving, for
empty data types. This is completely backwards-compatible change, since
previously deriving on empty data types wasn't working.(I also made some
improvements on error messages)

But then some people suggested that derived methods are not good, and we should
use empty pattern match in method bodies instead[5]. E.g. if we derive Eq for
an empty data type, generated instance should be:

    instance Eq X where
        a == b = case a of {}

See [5] for motivation.

So now we're also thinking about changing StandaloneDeriving for empty types
too, to use empty pattern match instead of `error`.

One thing to note is Data.Void.Void is doing completely different thing, it's
Eq is defined like this:

    instance Eq Void where
        _ == _ = True



So now that we have the story, my questions are:

1. What do you think is the right way to derive instances for empty data types?
   An `error` or pattern match on bottom argument(e.g. empty case)?

2. Do you think with EmptyDataDecls and StandaloneDeriving, `deriving(..)` and
   standalone deriving should derive same instances?

3. Should we change instances of Void on the way, for consistency? (Ord and Eq
   especially)



My answers:

1. Empty case. Users can always implement instances manually for always
   succeeding (==) etc.

2. Definitely. Current deriving mechanisms are already complex and it's hard to
   predict interactions between them(see [6]), I think we should do our best to
   keep them as simple as possible. Personally I'd hate it if standalone
   deriving and `deriving(...)` would implement different instances.

3. No opinion. May break some code? But making the change might be good for
   consistency?



If answers to (2) is yes, then we can just merge [4](which also improves error
messages), but if we want to change how we define instances too, then it'll
need some more work and I'll be working on that.

In any case, I think we should update the user manual to specify what will be
the derived instances. (as far as I can see currently it's not specified)


---

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011
[2]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html#nullary-types
[3]: https://ghc.haskell.org/trac/ghc/ticket/7401
[4]: https://phabricator.haskell.org/D978
[5]: https://ghc.haskell.org/trac/ghc/ticket/10577

[6]: https://ghc.haskell.org/trac/ghc/ticket/10598

From hesselink at gmail.com  Wed Jul 15 17:55:16 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Wed, 15 Jul 2015 19:55:16 +0200
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
Message-ID: <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>

1) I think an empty case is nicer than the current error calls, since
it gives the (hopefully more informative) error from the point where
the empty data type was generated, instead of a generic error from the
instance. I've used similar instance definitions here [1].

2) It makes sense to me to also allow non-standalone deriving, and if
that is allowed, it should be the same as standalone deriving. Doing
anything else would be very confusing.

3) I have no idea. What's the rationale behind returning True when
comparing two Voids?

Erik

[1] https://github.com/silkapp/rest/blob/60faa55887fbf7332dc7aa82a9505e2d92f7c316/rest-types/src/Rest/Types/Void.hs

On Wed, Jul 15, 2015 at 5:56 PM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
> # RFC for a change in EmptyDataDecls instance deriving
>
> Hi all,
>
> There were some requests about EmptyDataDecls instance deriving and recently I
> made some progress towards implementing those. However as I implement things
> people started suggesting different behaviors than what I've implemented etc.
> In the end, we thought it'd be a good idea to ask libraries mailing list for
> which behavior to implement.
>
> # Summary
>
> Haskell 2010 doesn't support data types without any constructors(aka. empty
> data type)[1]. GHC supports it via EmptyDataDecls[2], but it fails to derive
> instances:
>
>     Decl.hs:3:18:
>         Can't make a derived instance of ?Eq Z?:
>           ?Z? must have at least one data constructor
>           Possible fix: use a standalone deriving declaration instead
>         In the data declaration for ?Z?
>
> Using StandaloneDeriving works, and it generates methods that calls `error`:
>
>     Derived instances:
>       instance GHC.Classes.Eq Main.Z where
>         (GHC.Classes.==) = GHC.Err.error "Void =="
>         (GHC.Classes./=) a_aCf b_aCg
>           = GHC.Classes.not ((GHC.Classes.==) a_aCf b_aCg)
>
> Note that these methods fail in first applications. So `(==) a` is an error, it
> doesn't need to be a fully saturated application.
>
> Ticket 7401[3] asks for a change in default deriving mechanism. I submitted a
> patch[4] that makes standard deriving work same as standalone deriving, for
> empty data types. This is completely backwards-compatible change, since
> previously deriving on empty data types wasn't working.(I also made some
> improvements on error messages)
>
> But then some people suggested that derived methods are not good, and we should
> use empty pattern match in method bodies instead[5]. E.g. if we derive Eq for
> an empty data type, generated instance should be:
>
>     instance Eq X where
>         a == b = case a of {}
>
> See [5] for motivation.
>
> So now we're also thinking about changing StandaloneDeriving for empty types
> too, to use empty pattern match instead of `error`.
>
> One thing to note is Data.Void.Void is doing completely different thing, it's
> Eq is defined like this:
>
>     instance Eq Void where
>         _ == _ = True
>
>
>
> So now that we have the story, my questions are:
>
> 1. What do you think is the right way to derive instances for empty data types?
>    An `error` or pattern match on bottom argument(e.g. empty case)?
>
> 2. Do you think with EmptyDataDecls and StandaloneDeriving, `deriving(..)` and
>    standalone deriving should derive same instances?
>
> 3. Should we change instances of Void on the way, for consistency? (Ord and Eq
>    especially)
>
>
>
> My answers:
>
> 1. Empty case. Users can always implement instances manually for always
>    succeeding (==) etc.
>
> 2. Definitely. Current deriving mechanisms are already complex and it's hard to
>    predict interactions between them(see [6]), I think we should do our best to
>    keep them as simple as possible. Personally I'd hate it if standalone
>    deriving and `deriving(...)` would implement different instances.
>
> 3. No opinion. May break some code? But making the change might be good for
>    consistency?
>
>
>
> If answers to (2) is yes, then we can just merge [4](which also improves error
> messages), but if we want to change how we define instances too, then it'll
> need some more work and I'll be working on that.
>
> In any case, I think we should update the user manual to specify what will be
> the derived instances. (as far as I can see currently it's not specified)
>
>
> ---
>
> [1]: https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011
> [2]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html#nullary-types
> [3]: https://ghc.haskell.org/trac/ghc/ticket/7401
> [4]: https://phabricator.haskell.org/D978
> [5]: https://ghc.haskell.org/trac/ghc/ticket/10577
>
> [6]: https://ghc.haskell.org/trac/ghc/ticket/10598
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From roma at ro-che.info  Wed Jul 15 20:18:25 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Wed, 15 Jul 2015 23:18:25 +0300
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
Message-ID: <55A6C011.4060804@ro-che.info>

On 15/07/15 18:56, ?mer Sinan A?acan wrote:
> Haskell 2010 doesn't support data types without any constructors(aka. empty
> data type)[1].

Haskell 2010 does support data types without constructors:
https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-690004.2.1

> 1. What do you think is the right way to derive instances for empty data types?
>    An `error` or pattern match on bottom argument(e.g. empty case)?

The right question is whether the methods should be strict in the arguments of empty types.
The strict version can be implemented with an empty case (which is stylistically nicer),
or with error + seq/bang patterns; it doesn't matter.

I agree that the derived methods should be strict.

> 2. Do you think with EmptyDataDecls and StandaloneDeriving, `deriving(..)` and
>    standalone deriving should derive same instances?

Certainly.

> 3. Should we change instances of Void on the way, for consistency? (Ord and Eq
>    especially)

Yes.


-------------- 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/20150715/6c1a5d39/attachment.sig>

From svenpanne at gmail.com  Wed Jul 15 21:53:01 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 15 Jul 2015 23:53:01 +0200
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
Message-ID: <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>

2015-07-15 19:55 GMT+02:00 Erik Hesselink <hesselink at gmail.com>:

> [..] 3) I have no idea. What's the rationale behind returning True when
> comparing two Voids? [...]
>

Hmmm, what's the rationale of throwing an exception? I can imagine True,
False, throwing an exception etc., but I can't see a reason why one should
be "better" or "more natural" than the other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150715/22a3b5c8/attachment.html>

From david.feuer at gmail.com  Thu Jul 16 03:28:03 2015
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 15 Jul 2015 23:28:03 -0400
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
Message-ID: <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>

It's all a bit weird. I think the Proxy instance is lazy too. I would tend
to think that empty types shouldn't have these instances, and that if they
do that should be strict (empty case), but I can't prove that's the right
way.
On Jul 15, 2015 5:53 PM, "Sven Panne" <svenpanne at gmail.com> wrote:

> 2015-07-15 19:55 GMT+02:00 Erik Hesselink <hesselink at gmail.com>:
>
>> [..] 3) I have no idea. What's the rationale behind returning True when
>> comparing two Voids? [...]
>>
>
> Hmmm, what's the rationale of throwing an exception? I can imagine True,
> False, throwing an exception etc., but I can't see a reason why one should
> be "better" or "more natural" than the other.
>
> _______________________________________________
> 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/20150715/e810db32/attachment.html>

From hvr at gnu.org  Thu Jul 16 11:14:38 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Thu, 16 Jul 2015 13:14:38 +0200
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 (David Feuer's message of "Wed, 15 Jul 2015 23:28:03 -0400")
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
Message-ID: <878uag5p7l.fsf@gnu.org>

On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
> It's all a bit weird. I think the Proxy instance is lazy too. I would tend
> to think that empty types shouldn't have these instances, and that if they
> do that should be strict (empty case), but I can't prove that's the right
> way.

Btw, something similiar came up for deepseq, regarding NFData instances
for types only inhabited by ? (and the issue of H2010 forbidding
instance auto-derivation for constructor-less types was mentioned too):

 https://github.com/haskell/deepseq/pull/1#issuecomment-61914093

-- hvr

From ekmett at gmail.com  Thu Jul 16 12:29:50 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 16 Jul 2015 08:29:50 -0400
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <878uag5p7l.fsf@gnu.org>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 <878uag5p7l.fsf@gnu.org>
Message-ID: <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>

I'd caution against randomly changing Eq and Ord for Void to be less
defined in the ill-considered name of consistency.

We rather deliberately made them as "defined as possible" back in 2012
after a very long discussion in which the pendulum swung the other way
using a few examples where folks tied knots with fixed points to get
inhabitants of Void and it was less consistent to rule them out than it was
to define equality on _|_ to be True.

I'd challenge that nothing is gained by making these combinators strict in
their arguments.

-Edward

On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
> > It's all a bit weird. I think the Proxy instance is lazy too. I would
> tend
> > to think that empty types shouldn't have these instances, and that if
> they
> > do that should be strict (empty case), but I can't prove that's the right
> > way.
>
> Btw, something similiar came up for deepseq, regarding NFData instances
> for types only inhabited by ? (and the issue of H2010 forbidding
> instance auto-derivation for constructor-less types was mentioned too):
>
>  https://github.com/haskell/deepseq/pull/1#issuecomment-61914093
>
> -- hvr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150716/5f377b3b/attachment.html>

From ekmett at gmail.com  Thu Jul 16 12:36:11 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 16 Jul 2015 08:36:11 -0400
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 <878uag5p7l.fsf@gnu.org>
 <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
Message-ID: <CAJumaK8YwX4Qxk7Oc6BxWjO+hiqrXF1cCa6FAwUAr=4_sn8A9w@mail.gmail.com>

The Proxy instance for Eq and Ord is deliberately lazy for the same sort of
reason.

It is, simply, the maximally defined version of the function and, like it
or not, folks with good intentions but bad design sense often still pass
undefineds for Proxy arguments when they are used to older APIs that didn't
take proxies.

The lazy version of each of these when inlined can eliminate whole code
paths that would otherwise be compiled.

-Edward

On Thu, Jul 16, 2015 at 8:29 AM, Edward Kmett <ekmett at gmail.com> wrote:

> I'd caution against randomly changing Eq and Ord for Void to be less
> defined in the ill-considered name of consistency.
>
> We rather deliberately made them as "defined as possible" back in 2012
> after a very long discussion in which the pendulum swung the other way
> using a few examples where folks tied knots with fixed points to get
> inhabitants of Void and it was less consistent to rule them out than it was
> to define equality on _|_ to be True.
>
> I'd challenge that nothing is gained by making these combinators strict in
> their arguments.
>
> -Edward
>
> On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
>
>> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
>> > It's all a bit weird. I think the Proxy instance is lazy too. I would
>> tend
>> > to think that empty types shouldn't have these instances, and that if
>> they
>> > do that should be strict (empty case), but I can't prove that's the
>> right
>> > way.
>>
>> Btw, something similiar came up for deepseq, regarding NFData instances
>> for types only inhabited by ? (and the issue of H2010 forbidding
>> instance auto-derivation for constructor-less types was mentioned too):
>>
>>  https://github.com/haskell/deepseq/pull/1#issuecomment-61914093
>>
>> -- hvr
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150716/11079ca3/attachment.html>

From david.feuer at gmail.com  Thu Jul 16 13:10:04 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 16 Jul 2015 09:10:04 -0400
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 <878uag5p7l.fsf@gnu.org>
 <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
Message-ID: <CAMgWh9uxgUwKkUOebvdw-Lw-cHZZ=uaRqBP6YUb=j_NUo2LEAQ@mail.gmail.com>

I still don't understand why these instances exist, except maybe to write
(Proxy :: Proxy p)==(Proxy :: Proxy q) instead of the more usual [Proxy ::
Proxy p, Proxy :: Proxy q] to force p~q. I'll admit it looks pretty, but it
seems a bit silly. The Void instance doesn't even have this dubious benefit.

Why would one ever want to tie a knot in Void? That violates the entire
purpose of the type--communicating the idea that it's not supposed to be
inhabited (btw, I think there is a sensible argument for making Await in
machines strict in its request argument so that a SourceT is truly
incapable of awaiting; I don't know how that would affect efficiency
though).

The efficiency argument only makes sense if one accepts that the code in
question is sane to begin with. If someone writes disgusting code, I don't
care if it's compiled well.
On Jul 16, 2015 8:29 AM, "Edward Kmett" <ekmett at gmail.com> wrote:

> I'd caution against randomly changing Eq and Ord for Void to be less
> defined in the ill-considered name of consistency.
>
> We rather deliberately made them as "defined as possible" back in 2012
> after a very long discussion in which the pendulum swung the other way
> using a few examples where folks tied knots with fixed points to get
> inhabitants of Void and it was less consistent to rule them out than it was
> to define equality on _|_ to be True.
>
> I'd challenge that nothing is gained by making these combinators strict in
> their arguments.
>
> -Edward
>
> On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
>
>> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
>> > It's all a bit weird. I think the Proxy instance is lazy too. I would
>> tend
>> > to think that empty types shouldn't have these instances, and that if
>> they
>> > do that should be strict (empty case), but I can't prove that's the
>> right
>> > way.
>>
>> Btw, something similiar came up for deepseq, regarding NFData instances
>> for types only inhabited by ? (and the issue of H2010 forbidding
>> instance auto-derivation for constructor-less types was mentioned too):
>>
>>  https://github.com/haskell/deepseq/pull/1#issuecomment-61914093
>>
>> -- hvr
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150716/b4f68e32/attachment.html>

From hesselink at gmail.com  Thu Jul 16 13:10:34 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Thu, 16 Jul 2015 15:10:34 +0200
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 <878uag5p7l.fsf@gnu.org>
 <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
Message-ID: <CAPeieQH7ZH6K4DcVU9b+2RFjfbnjNEqjD--2xzBYhFnv2oNhrg@mail.gmail.com>

Do you have an example of things made possible by the version returning True?

Erik

On Thu, Jul 16, 2015 at 2:29 PM, Edward Kmett <ekmett at gmail.com> wrote:
> I'd caution against randomly changing Eq and Ord for Void to be less defined
> in the ill-considered name of consistency.
>
> We rather deliberately made them as "defined as possible" back in 2012 after
> a very long discussion in which the pendulum swung the other way using a few
> examples where folks tied knots with fixed points to get inhabitants of Void
> and it was less consistent to rule them out than it was to define equality
> on _|_ to be True.
>
> I'd challenge that nothing is gained by making these combinators strict in
> their arguments.
>
> -Edward
>
> On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:
>>
>> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
>> > It's all a bit weird. I think the Proxy instance is lazy too. I would
>> > tend
>> > to think that empty types shouldn't have these instances, and that if
>> > they
>> > do that should be strict (empty case), but I can't prove that's the
>> > right
>> > way.
>>
>> Btw, something similiar came up for deepseq, regarding NFData instances
>> for types only inhabited by ? (and the issue of H2010 forbidding
>> instance auto-derivation for constructor-less types was mentioned too):
>>
>>  https://github.com/haskell/deepseq/pull/1#issuecomment-61914093
>>
>> -- hvr
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

From hesselink at gmail.com  Thu Jul 16 13:11:39 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Thu, 16 Jul 2015 15:11:39 +0200
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAMgWh9uxgUwKkUOebvdw-Lw-cHZZ=uaRqBP6YUb=j_NUo2LEAQ@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 <878uag5p7l.fsf@gnu.org>
 <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
 <CAMgWh9uxgUwKkUOebvdw-Lw-cHZZ=uaRqBP6YUb=j_NUo2LEAQ@mail.gmail.com>
Message-ID: <CAPeieQEnzhcT5LZRR=Xydmp=qoHmHVf0JkV4ncPimTgV1ou6Dg@mail.gmail.com>

The Eq Void instance is very useful for structures with a type
parameter instantiated to Void. You might still want to compare these
for equality, but that needs an Eq instance for Void.

Erik

On Thu, Jul 16, 2015 at 3:10 PM, David Feuer <david.feuer at gmail.com> wrote:
> I still don't understand why these instances exist, except maybe to write
> (Proxy :: Proxy p)==(Proxy :: Proxy q) instead of the more usual [Proxy ::
> Proxy p, Proxy :: Proxy q] to force p~q. I'll admit it looks pretty, but it
> seems a bit silly. The Void instance doesn't even have this dubious benefit.
>
> Why would one ever want to tie a knot in Void? That violates the entire
> purpose of the type--communicating the idea that it's not supposed to be
> inhabited (btw, I think there is a sensible argument for making Await in
> machines strict in its request argument so that a SourceT is truly incapable
> of awaiting; I don't know how that would affect efficiency though).
>
> The efficiency argument only makes sense if one accepts that the code in
> question is sane to begin with. If someone writes disgusting code, I don't
> care if it's compiled well.
>
> On Jul 16, 2015 8:29 AM, "Edward Kmett" <ekmett at gmail.com> wrote:
>>
>> I'd caution against randomly changing Eq and Ord for Void to be less
>> defined in the ill-considered name of consistency.
>>
>> We rather deliberately made them as "defined as possible" back in 2012
>> after a very long discussion in which the pendulum swung the other way using
>> a few examples where folks tied knots with fixed points to get inhabitants
>> of Void and it was less consistent to rule them out than it was to define
>> equality on _|_ to be True.
>>
>> I'd challenge that nothing is gained by making these combinators strict in
>> their arguments.
>>
>> -Edward
>>
>> On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <hvr at gnu.org>
>> wrote:
>>>
>>> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
>>> > It's all a bit weird. I think the Proxy instance is lazy too. I would
>>> > tend
>>> > to think that empty types shouldn't have these instances, and that if
>>> > they
>>> > do that should be strict (empty case), but I can't prove that's the
>>> > right
>>> > way.
>>>
>>> Btw, something similiar came up for deepseq, regarding NFData instances
>>> for types only inhabited by ? (and the issue of H2010 forbidding
>>> instance auto-derivation for constructor-less types was mentioned too):
>>>
>>>  https://github.com/haskell/deepseq/pull/1#issuecomment-61914093
>>>
>>> -- hvr
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

From david.feuer at gmail.com  Thu Jul 16 13:30:51 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 16 Jul 2015 09:30:51 -0400
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAPeieQEnzhcT5LZRR=Xydmp=qoHmHVf0JkV4ncPimTgV1ou6Dg@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 <878uag5p7l.fsf@gnu.org>
 <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
 <CAMgWh9uxgUwKkUOebvdw-Lw-cHZZ=uaRqBP6YUb=j_NUo2LEAQ@mail.gmail.com>
 <CAPeieQEnzhcT5LZRR=Xydmp=qoHmHVf0JkV4ncPimTgV1ou6Dg@mail.gmail.com>
Message-ID: <CAMgWh9sRH_5jEg0G3pCMR=FLZEL9w=45Kcae2rfc3MNR--8nmQ@mail.gmail.com>

That makes sense.
On Jul 16, 2015 9:11 AM, "Erik Hesselink" <hesselink at gmail.com> wrote:

> The Eq Void instance is very useful for structures with a type
> parameter instantiated to Void. You might still want to compare these
> for equality, but that needs an Eq instance for Void.
>
> Erik
>
> On Thu, Jul 16, 2015 at 3:10 PM, David Feuer <david.feuer at gmail.com>
> wrote:
> > I still don't understand why these instances exist, except maybe to write
> > (Proxy :: Proxy p)==(Proxy :: Proxy q) instead of the more usual [Proxy
> ::
> > Proxy p, Proxy :: Proxy q] to force p~q. I'll admit it looks pretty, but
> it
> > seems a bit silly. The Void instance doesn't even have this dubious
> benefit.
> >
> > Why would one ever want to tie a knot in Void? That violates the entire
> > purpose of the type--communicating the idea that it's not supposed to be
> > inhabited (btw, I think there is a sensible argument for making Await in
> > machines strict in its request argument so that a SourceT is truly
> incapable
> > of awaiting; I don't know how that would affect efficiency though).
> >
> > The efficiency argument only makes sense if one accepts that the code in
> > question is sane to begin with. If someone writes disgusting code, I
> don't
> > care if it's compiled well.
> >
> > On Jul 16, 2015 8:29 AM, "Edward Kmett" <ekmett at gmail.com> wrote:
> >>
> >> I'd caution against randomly changing Eq and Ord for Void to be less
> >> defined in the ill-considered name of consistency.
> >>
> >> We rather deliberately made them as "defined as possible" back in 2012
> >> after a very long discussion in which the pendulum swung the other way
> using
> >> a few examples where folks tied knots with fixed points to get
> inhabitants
> >> of Void and it was less consistent to rule them out than it was to
> define
> >> equality on _|_ to be True.
> >>
> >> I'd challenge that nothing is gained by making these combinators strict
> in
> >> their arguments.
> >>
> >> -Edward
> >>
> >> On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <hvr at gnu.org>
> >> wrote:
> >>>
> >>> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
> >>> > It's all a bit weird. I think the Proxy instance is lazy too. I would
> >>> > tend
> >>> > to think that empty types shouldn't have these instances, and that if
> >>> > they
> >>> > do that should be strict (empty case), but I can't prove that's the
> >>> > right
> >>> > way.
> >>>
> >>> Btw, something similiar came up for deepseq, regarding NFData instances
> >>> for types only inhabited by ? (and the issue of H2010 forbidding
> >>> instance auto-derivation for constructor-less types was mentioned too):
> >>>
> >>>  https://github.com/haskell/deepseq/pull/1#issuecomment-61914093
> >>>
> >>> -- hvr
> >>
> >>
> >
> > _______________________________________________
> > 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/20150716/2fbb5759/attachment.html>

From ekmett at gmail.com  Thu Jul 16 16:32:37 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 16 Jul 2015 12:32:37 -0400
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAMgWh9uxgUwKkUOebvdw-Lw-cHZZ=uaRqBP6YUb=j_NUo2LEAQ@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 <878uag5p7l.fsf@gnu.org>
 <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
 <CAMgWh9uxgUwKkUOebvdw-Lw-cHZZ=uaRqBP6YUb=j_NUo2LEAQ@mail.gmail.com>
Message-ID: <CAJumaK_2GnMYyCOAbY6dGdkZeeALco=K6_bPbN4Ro+Bu58V2cA@mail.gmail.com>

The instances exist because people do things like

data Exp a
  = Var a
  | Lam (Exp (Maybe a)
  | App (Exp a) (Exp a)

and manipulate "Exp Void" to represent a closed term all the time.

Being able to compare two closed "Exp" terms for equality is quite valuable
and that goes away if you remove these instances!

-Edward

On Thu, Jul 16, 2015 at 9:10 AM, David Feuer <david.feuer at gmail.com> wrote:

> I still don't understand why these instances exist, except maybe to write
> (Proxy :: Proxy p)==(Proxy :: Proxy q) instead of the more usual [Proxy ::
> Proxy p, Proxy :: Proxy q] to force p~q. I'll admit it looks pretty, but it
> seems a bit silly. The Void instance doesn't even have this dubious benefit.
>
> Why would one ever want to tie a knot in Void? That violates the entire
> purpose of the type--communicating the idea that it's not supposed to be
> inhabited (btw, I think there is a sensible argument for making Await in
> machines strict in its request argument so that a SourceT is truly
> incapable of awaiting; I don't know how that would affect efficiency
> though).
>
> The efficiency argument only makes sense if one accepts that the code in
> question is sane to begin with. If someone writes disgusting code, I don't
> care if it's compiled well.
> On Jul 16, 2015 8:29 AM, "Edward Kmett" <ekmett at gmail.com> wrote:
>
>> I'd caution against randomly changing Eq and Ord for Void to be less
>> defined in the ill-considered name of consistency.
>>
>> We rather deliberately made them as "defined as possible" back in 2012
>> after a very long discussion in which the pendulum swung the other way
>> using a few examples where folks tied knots with fixed points to get
>> inhabitants of Void and it was less consistent to rule them out than it was
>> to define equality on _|_ to be True.
>>
>> I'd challenge that nothing is gained by making these combinators strict
>> in their arguments.
>>
>> -Edward
>>
>> On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <hvr at gnu.org>
>> wrote:
>>
>>> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
>>> > It's all a bit weird. I think the Proxy instance is lazy too. I would
>>> tend
>>> > to think that empty types shouldn't have these instances, and that if
>>> they
>>> > do that should be strict (empty case), but I can't prove that's the
>>> right
>>> > way.
>>>
>>> Btw, something similiar came up for deepseq, regarding NFData instances
>>> for types only inhabited by ? (and the issue of H2010 forbidding
>>> instance auto-derivation for constructor-less types was mentioned too):
>>>
>>>  https://github.com/haskell/deepseq/pull/1#issuecomment-61914093
>>>
>>> -- hvr
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150716/448d31ca/attachment.html>

From ekmett at gmail.com  Thu Jul 16 16:33:51 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 16 Jul 2015 12:33:51 -0400
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAPeieQH7ZH6K4DcVU9b+2RFjfbnjNEqjD--2xzBYhFnv2oNhrg@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 <878uag5p7l.fsf@gnu.org>
 <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
 <CAPeieQH7ZH6K4DcVU9b+2RFjfbnjNEqjD--2xzBYhFnv2oNhrg@mail.gmail.com>
Message-ID: <CAJumaK-AcYja5KW8pQ09ouwn69R0vc2YK1dXkLDqdjjDjW=4zA@mail.gmail.com>

Do you have an example of a thing made possible by making them more strict?
=)

-Edward

-Edward

On Thu, Jul 16, 2015 at 9:10 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> Do you have an example of things made possible by the version returning
> True?
>
> Erik
>
> On Thu, Jul 16, 2015 at 2:29 PM, Edward Kmett <ekmett at gmail.com> wrote:
> > I'd caution against randomly changing Eq and Ord for Void to be less
> defined
> > in the ill-considered name of consistency.
> >
> > We rather deliberately made them as "defined as possible" back in 2012
> after
> > a very long discussion in which the pendulum swung the other way using a
> few
> > examples where folks tied knots with fixed points to get inhabitants of
> Void
> > and it was less consistent to rule them out than it was to define
> equality
> > on _|_ to be True.
> >
> > I'd challenge that nothing is gained by making these combinators strict
> in
> > their arguments.
> >
> > -Edward
> >
> > On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
> >>
> >> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
> >> > It's all a bit weird. I think the Proxy instance is lazy too. I would
> >> > tend
> >> > to think that empty types shouldn't have these instances, and that if
> >> > they
> >> > do that should be strict (empty case), but I can't prove that's the
> >> > right
> >> > way.
> >>
> >> Btw, something similiar came up for deepseq, regarding NFData instances
> >> for types only inhabited by ? (and the issue of H2010 forbidding
> >> instance auto-derivation for constructor-less types was mentioned too):
> >>
> >>  https://github.com/haskell/deepseq/pull/1#issuecomment-61914093
> >>
> >> -- hvr
> >
> >
> >
> > _______________________________________________
> > 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/20150716/19c1e429/attachment.html>

From hesselink at gmail.com  Thu Jul 16 18:53:48 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Thu, 16 Jul 2015 20:53:48 +0200
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAJumaK-AcYja5KW8pQ09ouwn69R0vc2YK1dXkLDqdjjDjW=4zA@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 <878uag5p7l.fsf@gnu.org>
 <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
 <CAPeieQH7ZH6K4DcVU9b+2RFjfbnjNEqjD--2xzBYhFnv2oNhrg@mail.gmail.com>
 <CAJumaK-AcYja5KW8pQ09ouwn69R0vc2YK1dXkLDqdjjDjW=4zA@mail.gmail.com>
Message-ID: <CAPeieQFRAbyS6RxjMXvOqEypXRjh+=r3q2qdAnV7rsF4YL-Yfg@mail.gmail.com>

Well, things made *im*possible: you can't do silly things like use
Voids as keys in a map, or look for Voids in a list, as that will
expose the Voids for the lies that they are. But you're right, I doubt
this is a very common use case. I guess it just feels wrong to me to
consider 'let x = x in x' be equal to 'error "boo"'. It also fits with
all other functions on Void, which, when receiving an argument, use
something like 'absurd' on it to produce their answer. Which leads to
another oddity: given 'v :: Void', if 'v == v = True', what about
something like 'absurd v :: Int == absurd v'? That would be bottom,
which again, seems weird to me.

Note that I have no great arguments and no intention of breaking
anyone's code, quite the opposite. So I'd be very interested to see
if/how defining the Void Eq instance to return True can be benificial.

Erik

On Thu, Jul 16, 2015 at 6:33 PM, Edward Kmett <ekmett at gmail.com> wrote:
> Do you have an example of a thing made possible by making them more strict?
> =)
>
> -Edward
>
> -Edward
>
> On Thu, Jul 16, 2015 at 9:10 AM, Erik Hesselink <hesselink at gmail.com> wrote:
>>
>> Do you have an example of things made possible by the version returning
>> True?
>>
>> Erik
>>
>> On Thu, Jul 16, 2015 at 2:29 PM, Edward Kmett <ekmett at gmail.com> wrote:
>> > I'd caution against randomly changing Eq and Ord for Void to be less
>> > defined
>> > in the ill-considered name of consistency.
>> >
>> > We rather deliberately made them as "defined as possible" back in 2012
>> > after
>> > a very long discussion in which the pendulum swung the other way using a
>> > few
>> > examples where folks tied knots with fixed points to get inhabitants of
>> > Void
>> > and it was less consistent to rule them out than it was to define
>> > equality
>> > on _|_ to be True.
>> >
>> > I'd challenge that nothing is gained by making these combinators strict
>> > in
>> > their arguments.
>> >
>> > -Edward
>> >
>> > On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <hvr at gnu.org>
>> > wrote:
>> >>
>> >> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
>> >> > It's all a bit weird. I think the Proxy instance is lazy too. I would
>> >> > tend
>> >> > to think that empty types shouldn't have these instances, and that if
>> >> > they
>> >> > do that should be strict (empty case), but I can't prove that's the
>> >> > right
>> >> > way.
>> >>
>> >> Btw, something similiar came up for deepseq, regarding NFData instances
>> >> for types only inhabited by ? (and the issue of H2010 forbidding
>> >> instance auto-derivation for constructor-less types was mentioned too):
>> >>
>> >>  https://github.com/haskell/deepseq/pull/1#issuecomment-61914093
>> >>
>> >> -- hvr
>> >
>> >
>> >
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >
>
>

From ekmett at gmail.com  Thu Jul 16 19:12:42 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 16 Jul 2015 15:12:42 -0400
Subject: RFC for a change in EmptyDataDecls instance deriving
In-Reply-To: <CAPeieQFRAbyS6RxjMXvOqEypXRjh+=r3q2qdAnV7rsF4YL-Yfg@mail.gmail.com>
References: <CAMQQO3kj8VNRDHgyEx2zvYU310PPDGBVO5xQZtEVxkpeKVV8LQ@mail.gmail.com>
 <CAPeieQFXK0bFoSt178CE1f54YRPnfPEk5wni3872k9EcTbL2+g@mail.gmail.com>
 <CANBN=msAOMqO9+WJ+e546wZjH9cgObZVAy8Hb1V8RXA_do-JZA@mail.gmail.com>
 <CAMgWh9t=4081WgGPB=4LYWeESbn=Kk+S1AGCTDFxS5_5ncp=wQ@mail.gmail.com>
 <878uag5p7l.fsf@gnu.org>
 <CAJumaK9sBPJeTx0DzeK0O8iduG_1NiAqmWt62G9Pc0AAtqT27g@mail.gmail.com>
 <CAPeieQH7ZH6K4DcVU9b+2RFjfbnjNEqjD--2xzBYhFnv2oNhrg@mail.gmail.com>
 <CAJumaK-AcYja5KW8pQ09ouwn69R0vc2YK1dXkLDqdjjDjW=4zA@mail.gmail.com>
 <CAPeieQFRAbyS6RxjMXvOqEypXRjh+=r3q2qdAnV7rsF4YL-Yfg@mail.gmail.com>
Message-ID: <CAJumaK_4uROpMkKD8Gme7fok1xzbdp6HwbtFhSSgwGM_xAGRMA@mail.gmail.com>

Voids as a key in a map blow up for different reasons, namely that Data.Map
evaluates the key.

In any event my experience tends to run to the opposite direction, anything
that makes code less defined, forces results that don't need to be forced
or passes dictionaries that don't get used is something I tend to worry
about as it leads to code that is doing make-work.

Your attempt at using x == y => f x == f y is compelling on the surface but
falls apart when you push on it.

x == y = True implies f x == f y = _|_ for tons of things, absurd isn't
terribly special in this regard.

() == () = True
repeat () == repeat () = _|_

There is a distinction between definitional equality (=) and constructive,
testable, equality (==).

What we really want is x = y implies f x = f y, which holds here. even x ==
y implies f x = f y, holds here, just not x == y implies f x == f y.

-Edward

On Thu, Jul 16, 2015 at 2:53 PM, Erik Hesselink <hesselink at gmail.com> wrote:

> Well, things made *im*possible: you can't do silly things like use
> Voids as keys in a map, or look for Voids in a list, as that will
> expose the Voids for the lies that they are. But you're right, I doubt
> this is a very common use case. I guess it just feels wrong to me to
> consider 'let x = x in x' be equal to 'error "boo"'. It also fits with
> all other functions on Void, which, when receiving an argument, use
> something like 'absurd' on it to produce their answer. Which leads to
> another oddity: given 'v :: Void', if 'v == v = True', what about
> something like 'absurd v :: Int == absurd v'? That would be bottom,
> which again, seems weird to me.
>
> Note that I have no great arguments and no intention of breaking
> anyone's code, quite the opposite. So I'd be very interested to see
> if/how defining the Void Eq instance to return True can be benificial.
>
> Erik
>
> On Thu, Jul 16, 2015 at 6:33 PM, Edward Kmett <ekmett at gmail.com> wrote:
> > Do you have an example of a thing made possible by making them more
> strict?
> > =)
> >
> > -Edward
> >
> > -Edward
> >
> > On Thu, Jul 16, 2015 at 9:10 AM, Erik Hesselink <hesselink at gmail.com>
> wrote:
> >>
> >> Do you have an example of things made possible by the version returning
> >> True?
> >>
> >> Erik
> >>
> >> On Thu, Jul 16, 2015 at 2:29 PM, Edward Kmett <ekmett at gmail.com> wrote:
> >> > I'd caution against randomly changing Eq and Ord for Void to be less
> >> > defined
> >> > in the ill-considered name of consistency.
> >> >
> >> > We rather deliberately made them as "defined as possible" back in 2012
> >> > after
> >> > a very long discussion in which the pendulum swung the other way
> using a
> >> > few
> >> > examples where folks tied knots with fixed points to get inhabitants
> of
> >> > Void
> >> > and it was less consistent to rule them out than it was to define
> >> > equality
> >> > on _|_ to be True.
> >> >
> >> > I'd challenge that nothing is gained by making these combinators
> strict
> >> > in
> >> > their arguments.
> >> >
> >> > -Edward
> >> >
> >> > On Thu, Jul 16, 2015 at 7:14 AM, Herbert Valerio Riedel <hvr at gnu.org>
> >> > wrote:
> >> >>
> >> >> On 2015-07-16 at 05:28:03 +0200, David Feuer wrote:
> >> >> > It's all a bit weird. I think the Proxy instance is lazy too. I
> would
> >> >> > tend
> >> >> > to think that empty types shouldn't have these instances, and that
> if
> >> >> > they
> >> >> > do that should be strict (empty case), but I can't prove that's the
> >> >> > right
> >> >> > way.
> >> >>
> >> >> Btw, something similiar came up for deepseq, regarding NFData
> instances
> >> >> for types only inhabited by ? (and the issue of H2010 forbidding
> >> >> instance auto-derivation for constructor-less types was mentioned
> too):
> >> >>
> >> >>  https://github.com/haskell/deepseq/pull/1#issuecomment-61914093
> >> >>
> >> >> -- hvr
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > 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/20150716/4a05fb1e/attachment.html>

From ekmett at gmail.com  Fri Jul 17 15:37:09 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 17 Jul 2015 11:37:09 -0400
Subject: Proposal: instance Alternative ZipList
Message-ID: <CAJumaK_DOtYKetnuF5hZJs-EO9tGhYUY5aar0Vo8_OQ-kvh-9g@mail.gmail.com>

The ZipList data type admits one legal Alternative instance

instance Alternative ZipList where
   pure = ZipList []
   ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)

The legality of this instance was first noted in
http://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/ppdp2015.pdf

I propose adding this instance, which acts like a generalized version of
the Alternative for Maybe, choosing with a left bias.

Discussion Period: 2 weeks

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150717/1dcbd44d/attachment.html>

From ekmett at gmail.com  Fri Jul 17 18:15:37 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 17 Jul 2015 14:15:37 -0400
Subject: Proposal: instance Alternative ZipList
In-Reply-To: <CAJumaK_DOtYKetnuF5hZJs-EO9tGhYUY5aar0Vo8_OQ-kvh-9g@mail.gmail.com>
References: <CAJumaK_DOtYKetnuF5hZJs-EO9tGhYUY5aar0Vo8_OQ-kvh-9g@mail.gmail.com>
Message-ID: <CAJumaK_HJMASvUFkG=5oL-7b1SR=SPTC34wgcAUNk6bnkDTgxQ@mail.gmail.com>

Er.. I obviously meant

instance Alternative ZipList where
   empty = ZipList []
   ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)

sorry for any confusion.

On Fri, Jul 17, 2015 at 11:37 AM, Edward Kmett <ekmett at gmail.com> wrote:

> The ZipList data type admits one legal Alternative instance
>
> instance Alternative ZipList where
>    pure = ZipList []
>    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)
>
> The legality of this instance was first noted in
> http://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/ppdp2015.pdf
>
> I propose adding this instance, which acts like a generalized version of
> the Alternative for Maybe, choosing with a left bias.
>
> Discussion Period: 2 weeks
>
> -Edward
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150717/f3ebd555/attachment.html>

From danburton.email at gmail.com  Fri Jul 17 18:45:27 2015
From: danburton.email at gmail.com (Dan Burton)
Date: Fri, 17 Jul 2015 11:45:27 -0700
Subject: Proposal: instance Alternative ZipList
In-Reply-To: <CAJumaK_HJMASvUFkG=5oL-7b1SR=SPTC34wgcAUNk6bnkDTgxQ@mail.gmail.com>
References: <CAJumaK_DOtYKetnuF5hZJs-EO9tGhYUY5aar0Vo8_OQ-kvh-9g@mail.gmail.com>
 <CAJumaK_HJMASvUFkG=5oL-7b1SR=SPTC34wgcAUNk6bnkDTgxQ@mail.gmail.com>
Message-ID: <CALSygwfhkeZScksEJ-WxCm1b9nMrt1q13F2mofiLwme0HAHZZA@mail.gmail.com>

+1. It obeys laws. It feels zippy. LGTM.

On Friday, July 17, 2015, Edward Kmett <ekmett at gmail.com> wrote:

> Er.. I obviously meant
>
> instance Alternative ZipList where
>    empty = ZipList []
>    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)
>
> sorry for any confusion.
>
> On Fri, Jul 17, 2015 at 11:37 AM, Edward Kmett <ekmett at gmail.com
> <javascript:_e(%7B%7D,'cvml','ekmett at gmail.com');>> wrote:
>
>> The ZipList data type admits one legal Alternative instance
>>
>> instance Alternative ZipList where
>>    pure = ZipList []
>>    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)
>>
>> The legality of this instance was first noted in
>> http://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/ppdp2015.pdf
>>
>> I propose adding this instance, which acts like a generalized version of
>> the Alternative for Maybe, choosing with a left bias.
>>
>> Discussion Period: 2 weeks
>>
>> -Edward
>>
>
>

-- 
-- Dan Burton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150717/ac927ff7/attachment.html>

From david.feuer at gmail.com  Fri Jul 17 21:16:53 2015
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 17 Jul 2015 17:16:53 -0400
Subject: Proposal: instance Alternative ZipList
In-Reply-To: <CAJumaK_HJMASvUFkG=5oL-7b1SR=SPTC34wgcAUNk6bnkDTgxQ@mail.gmail.com>
References: <CAJumaK_DOtYKetnuF5hZJs-EO9tGhYUY5aar0Vo8_OQ-kvh-9g@mail.gmail.com>
 <CAJumaK_HJMASvUFkG=5oL-7b1SR=SPTC34wgcAUNk6bnkDTgxQ@mail.gmail.com>
Message-ID: <CAMgWh9seCFyXbseTSU8rhk5byGV8AiniZZZJd=SKSS5wA7+8cQ@mail.gmail.com>

The implementation could use some work. Something more like this, I think.

(<|>) = foldr (\x k ys -> x : k (drop 1 ys)) id

In pointless silliness, it's even

foldr ((. (. (maybe ([]) snd . uncons))) . (.) . (:)) id
On Jul 17, 2015 2:15 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

> Er.. I obviously meant
>
> instance Alternative ZipList where
>    empty = ZipList []
>    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)
>
> sorry for any confusion.
>
> On Fri, Jul 17, 2015 at 11:37 AM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> The ZipList data type admits one legal Alternative instance
>>
>> instance Alternative ZipList where
>>    pure = ZipList []
>>    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)
>>
>> The legality of this instance was first noted in
>> http://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/ppdp2015.pdf
>>
>> I propose adding this instance, which acts like a generalized version of
>> the Alternative for Maybe, choosing with a left bias.
>>
>> Discussion Period: 2 weeks
>>
>> -Edward
>>
>
>
> _______________________________________________
> 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/20150717/77e46ad8/attachment.html>

From ekmett at gmail.com  Fri Jul 17 21:18:38 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 17 Jul 2015 17:18:38 -0400
Subject: Proposal: instance Alternative ZipList
In-Reply-To: <CAMgWh9seCFyXbseTSU8rhk5byGV8AiniZZZJd=SKSS5wA7+8cQ@mail.gmail.com>
References: <CAJumaK_DOtYKetnuF5hZJs-EO9tGhYUY5aar0Vo8_OQ-kvh-9g@mail.gmail.com>
 <CAJumaK_HJMASvUFkG=5oL-7b1SR=SPTC34wgcAUNk6bnkDTgxQ@mail.gmail.com>
 <CAMgWh9seCFyXbseTSU8rhk5byGV8AiniZZZJd=SKSS5wA7+8cQ@mail.gmail.com>
Message-ID: <CAJumaK804pEUsstFyn6qyvw4cCwDxrve_YsZYkGPvwEejBwpag@mail.gmail.com>

I'm more than open to switching to a more efficient solution.

-Edward

On Fri, Jul 17, 2015 at 5:16 PM, David Feuer <david.feuer at gmail.com> wrote:

> The implementation could use some work. Something more like this, I think.
>
> (<|>) = foldr (\x k ys -> x : k (drop 1 ys)) id
>
> In pointless silliness, it's even
>
> foldr ((. (. (maybe ([]) snd . uncons))) . (.) . (:)) id
> On Jul 17, 2015 2:15 PM, "Edward Kmett" <ekmett at gmail.com> wrote:
>
>> Er.. I obviously meant
>>
>> instance Alternative ZipList where
>>    empty = ZipList []
>>    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)
>>
>> sorry for any confusion.
>>
>> On Fri, Jul 17, 2015 at 11:37 AM, Edward Kmett <ekmett at gmail.com> wrote:
>>
>>> The ZipList data type admits one legal Alternative instance
>>>
>>> instance Alternative ZipList where
>>>    pure = ZipList []
>>>    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)
>>>
>>> The legality of this instance was first noted in
>>> http://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/ppdp2015.pdf
>>>
>>> I propose adding this instance, which acts like a generalized version of
>>> the Alternative for Maybe, choosing with a left bias.
>>>
>>> Discussion Period: 2 weeks
>>>
>>> -Edward
>>>
>>
>>
>> _______________________________________________
>> 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/20150717/460cb47d/attachment.html>

From chowells79 at gmail.com  Fri Jul 17 22:06:04 2015
From: chowells79 at gmail.com (Carl Howells)
Date: Fri, 17 Jul 2015 15:06:04 -0700
Subject: More general Generic and Data instances for Data.Proxy.Proxy?
Message-ID: <CAECnf4Dzv75exG1CsAq_5WxBUd6QFqKLWnAsVL=-PdZoULaPNA@mail.gmail.com>

At the moment, the following two instances are listed in the haddocks
for Data.Proxy.Proxy:

    Data t => Data (Proxy * t)
    Generic (Proxy * t)

Do those instances need to be that restrictive?  Would it be possible
to generalize those instances to these?

    Data (Proxy k t)
    Generic (Proxy k t)

I'm not 100% comfortable with either of those classes, so I'm not sure
if those instances work right, but it seems like they should in a
hand-wavy way.

-- 
Carl Howells

From emertens at gmail.com  Fri Jul 17 23:20:40 2015
From: emertens at gmail.com (Eric Mertens)
Date: Fri, 17 Jul 2015 23:20:40 +0000
Subject: More general Generic and Data instances for Data.Proxy.Proxy?
In-Reply-To: <CAECnf4Dzv75exG1CsAq_5WxBUd6QFqKLWnAsVL=-PdZoULaPNA@mail.gmail.com>
References: <CAECnf4Dzv75exG1CsAq_5WxBUd6QFqKLWnAsVL=-PdZoULaPNA@mail.gmail.com>
Message-ID: <CALya09015YPJ+QRJqLuFQPEthuoN1wFnSLHStkwbL9VSXeqcXQ@mail.gmail.com>

It appears that this is a simple matter of the PolyKinds extension not
being enabled in libraries/base/GHC/Generics.hs and presumably the reason
is the same for the Data instance.

It doesn't seem particularly controversial generalize those instances.

On Fri, Jul 17, 2015 at 3:06 PM Carl Howells <chowells79 at gmail.com> wrote:

> At the moment, the following two instances are listed in the haddocks
> for Data.Proxy.Proxy:
>
>     Data t => Data (Proxy * t)
>     Generic (Proxy * t)
>
> Do those instances need to be that restrictive?  Would it be possible
> to generalize those instances to these?
>
>     Data (Proxy k t)
>     Generic (Proxy k t)
>
> I'm not 100% comfortable with either of those classes, so I'm not sure
> if those instances work right, but it seems like they should in a
> hand-wavy way.
>
> --
> Carl Howells
> _______________________________________________
> 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/20150717/d153996c/attachment.html>

From ryan.gl.scott at gmail.com  Sat Jul 18 00:37:20 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Fri, 17 Jul 2015 19:37:20 -0500
Subject: More general Generic and Data instances for Data.Proxy.Proxy?
Message-ID: <CADdQpRC6jCBf-HL8O0YMBjXCYJHoC7aWGZjWOO+rD__Qsnww0w@mail.gmail.com>

Actually, Data.Data already has PolyKinds enabled, but the (Data t => Data
(Proxy t)) instance requires that the type parameter be of kind *, since
the Data typeclass has kind * -> Constraint.

On the other hand, switching on PolyKinds in GHC.Generics should provide a
polykinded Generic (Proxy t) instance (the corresponding instance in the
tagged library is already polykinded, in fact). If we enable PolyKinds in
GHC.Generics, we could also make Rep, Generic1, Rep1, V1, U1, Rec1, K1, M1,
(:+:), (:*:), and (:.:) polykinded.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150717/3689423f/attachment.html>

From chowells79 at gmail.com  Sat Jul 18 00:39:14 2015
From: chowells79 at gmail.com (Carl Howells)
Date: Fri, 17 Jul 2015 17:39:14 -0700
Subject: More general Generic and Data instances for Data.Proxy.Proxy?
In-Reply-To: <CADdQpRC6jCBf-HL8O0YMBjXCYJHoC7aWGZjWOO+rD__Qsnww0w@mail.gmail.com>
References: <CADdQpRC6jCBf-HL8O0YMBjXCYJHoC7aWGZjWOO+rD__Qsnww0w@mail.gmail.com>
Message-ID: <CAECnf4ArYWE0D_OK4tZZ-tSpNCsWxGCv_MpX_MtY+=OcHxJxcQ@mail.gmail.com>

Yes, but why does Proxy's Data instance depend on its type variable's
Data instance?  That seems unnecessary.

On Fri, Jul 17, 2015 at 5:37 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> Actually, Data.Data already has PolyKinds enabled, but the (Data t => Data
> (Proxy t)) instance requires that the type parameter be of kind *, since the
> Data typeclass has kind * -> Constraint.
>
> On the other hand, switching on PolyKinds in GHC.Generics should provide a
> polykinded Generic (Proxy t) instance (the corresponding instance in the
> tagged library is already polykinded, in fact). If we enable PolyKinds in
> GHC.Generics, we could also make Rep, Generic1, Rep1, V1, U1, Rec1, K1, M1,
> (:+:), (:*:), and (:.:) polykinded.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

From ryan.gl.scott at gmail.com  Sat Jul 18 00:58:27 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Fri, 17 Jul 2015 19:58:27 -0500
Subject: More general Generic and Data instances for Data.Proxy.Proxy?
Message-ID: <CADdQpRAmgjWb829v+zdp=rchH3N5v49E4ivDoVXe1rH9yG_hKA@mail.gmail.com>

It does seem unnecessary. The Data instance for Proxy is manually written
in Data.Data:

proxyConstr :: ConstrproxyConstr = mkConstr proxyDataType "Proxy" []
PrefixproxyDataType :: DataTypeproxyDataType = mkDataType
"Data.Proxy.Proxy" [proxyConstr]


instance (Data t) => Data (Proxy t) where  gfoldl _ z Proxy  = z Proxy
 toConstr Proxy  = proxyConstr  gunfold _ z c = case constrIndex c of
                  1 -> z Proxy                    _ -> error
"Data.Data.gunfold(Proxy)"  dataTypeOf _ = proxyDataType  dataCast1 f
= gcast1 f

If dataCast1 weren't defined to be gcast1, then that instance would
only require a Typeable t constraint, which would make it polykinded.
To be honest, I'm not sure why gcast1 requires a Data t constraint (I
don't use Data that often, so hopefully someone more knowledgeable
than me can answer this).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150717/af21658c/attachment.html>

From dreixel at gmail.com  Sat Jul 18 06:30:40 2015
From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=)
Date: Sat, 18 Jul 2015 07:30:40 +0100
Subject: More general Generic and Data instances for Data.Proxy.Proxy?
In-Reply-To: <CADdQpRAmgjWb829v+zdp=rchH3N5v49E4ivDoVXe1rH9yG_hKA@mail.gmail.com>
References: <CADdQpRAmgjWb829v+zdp=rchH3N5v49E4ivDoVXe1rH9yG_hKA@mail.gmail.com>
Message-ID: <CA+ZFbn_nEjQq5DiJ_0tVzjG=zoAJXSvkeh6sfZj3Kh7aa3dF7w@mail.gmail.com>

No time to go into details right now, unfortunately, but that is required
for the extension mechanism of ext/ext1 to work properly.

Cheers,
Pedro
On 18 Jul 2015 2:58 am, "Ryan Scott" <ryan.gl.scott at gmail.com> wrote:

> It does seem unnecessary. The Data instance for Proxy is manually written
> in Data.Data:
>
> proxyConstr :: ConstrproxyConstr = mkConstr proxyDataType "Proxy" [] PrefixproxyDataType :: DataTypeproxyDataType = mkDataType "Data.Proxy.Proxy" [proxyConstr]
>
>
> instance (Data t) => Data (Proxy t) where  gfoldl _ z Proxy  = z Proxy  toConstr Proxy  = proxyConstr  gunfold _ z c = case constrIndex c of                    1 -> z Proxy                    _ -> error "Data.Data.gunfold(Proxy)"  dataTypeOf _ = proxyDataType  dataCast1 f  = gcast1 f
>
> If dataCast1 weren't defined to be gcast1, then that instance would only require a Typeable t constraint, which would make it polykinded. To be honest, I'm not sure why gcast1 requires a Data t constraint (I don't use Data that often, so hopefully someone more knowledgeable than me can answer this).
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150718/838d839e/attachment.html>

From ekmett at gmail.com  Sat Jul 18 14:16:56 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 18 Jul 2015 10:16:56 -0400
Subject: More general Generic and Data instances for Data.Proxy.Proxy?
In-Reply-To: <CADdQpRAmgjWb829v+zdp=rchH3N5v49E4ivDoVXe1rH9yG_hKA@mail.gmail.com>
References: <CADdQpRAmgjWb829v+zdp=rchH3N5v49E4ivDoVXe1rH9yG_hKA@mail.gmail.com>
Message-ID: <CAJumaK8wnn40ULDiaCccxaeKYB0P=GMdDxHZrWsJdS95Jd=1dw@mail.gmail.com>

See Scrap more boilerplate: reflection, zips, and generalised casts by Ralf
L?mmel and Simon Peyton Jones
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.114.6907&rep=rep1&type=pdf>
for
why gcast1 and dataCast1 exist as they do.

On Fri, Jul 17, 2015 at 8:58 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> It does seem unnecessary. The Data instance for Proxy is manually written
> in Data.Data:
>
> proxyConstr :: ConstrproxyConstr = mkConstr proxyDataType "Proxy" [] PrefixproxyDataType :: DataTypeproxyDataType = mkDataType "Data.Proxy.Proxy" [proxyConstr]
>
>
> instance (Data t) => Data (Proxy t) where  gfoldl _ z Proxy  = z Proxy  toConstr Proxy  = proxyConstr  gunfold _ z c = case constrIndex c of                    1 -> z Proxy                    _ -> error "Data.Data.gunfold(Proxy)"  dataTypeOf _ = proxyDataType  dataCast1 f  = gcast1 f
>
> If dataCast1 weren't defined to be gcast1, then that instance would only require a Typeable t constraint, which would make it polykinded. To be honest, I'm not sure why gcast1 requires a Data t constraint (I don't use Data that often, so hopefully someone more knowledgeable than me can answer this).
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150718/0da39720/attachment.html>

From mark.lentczner at gmail.com  Sun Jul 19 11:46:57 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sun, 19 Jul 2015 07:46:57 -0400
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <CAKRanNCDTQDGLBkeHvk8S17gXD4Y2K1yqRhNYTS-8O89RCjT9A@mail.gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <EA807597-BB2B-40D0-B6E3-BAE58759B7C8@gmail.com>
 <CAAOoiFaDt8DbWOtaURA0_Xge7VPgaGStfJXqzCJ_oRvd53zrtw@mail.gmail.com>
 <71F7182C-A7DB-47A6-AA1B-940BDDE14F35@gmail.com>
 <CAKRanNC605RTO4kP+Bm0WiAr6c4-sj9DeHQv4xD8PhprwuDRzA@mail.gmail.com>
 <878uakpl27.fsf@andromedae.feelingofgreen.ru>
 <CAKRanNCDTQDGLBkeHvk8S17gXD4Y2K1yqRhNYTS-8O89RCjT9A@mail.gmail.com>
Message-ID: <CAAOoiFZG+Q32HHd88RoBf-4cp0-CpD+Bhx9j6s8D63rCic-CEg@mail.gmail.com>

 I'm glad to read the variety of response, and want to summarize and
respond to the most common points:

*stack is too new *& *having two package managers will confuse*
? It is indeed new, though it has arrived very well formed, and has gained
a lot of users in short order.  There are two reasons why I think we should
be including it (or rather, including the version a few months down the
road when we do the next major HP):

1) It's approach to package db organization is very good,
2) I would be better for all that stack were part of the suite of tools,
rather than an alternative suite.

Too be clear: I don't anticipate stack replacing cabal - different tasks
will need one or the other. But I would like to see them unified in package
db management.

*nix-like package management*
?  I'll be honest: I don't think nix-style package management is all that
useful. Enabling the package machinery to be able to support all those
different package builds is fine. But it seems the devil is in the user
experience of the tools that manage it. Until we see what use cases those
tools support, I really have no way to evaluate what extending package dbs
this way will add.

*possible change to cabal sandbox handling of the global db*
? Of course this will improve more complex builds for people who download
the HP - but does so by reducing the HP install to a minimal install. This
is fine, but I think what we proposed goes further.

*pre-built package binaries are good*
? Yes, especially on Windows, but I'd like to see a way that users can get
those binaries, easily, and securely, without bloating the HP download. At
present, users have to download 150MB ~ 230MB of installer - it is heavy!
If we can make it so that users only have to compile a package the first
time they use it in any project, for many this is ideal: you start minimal,
incur cost is only once on first use, and build exactly in your system
environment. If we augment this with a "binary repository" then we can let
users decide to trade the compile cost for the download cost.

- Mark

Sorry for slow, group response, I'm still on vacation!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150719/fe4e2ae9/attachment.html>

From byorgey at gmail.com  Mon Jul 20 14:37:02 2015
From: byorgey at gmail.com (Brent Yorgey)
Date: Mon, 20 Jul 2015 14:37:02 +0000
Subject: Proposal: instance Alternative ZipList
In-Reply-To: <CAJumaK804pEUsstFyn6qyvw4cCwDxrve_YsZYkGPvwEejBwpag@mail.gmail.com>
References: <CAJumaK_DOtYKetnuF5hZJs-EO9tGhYUY5aar0Vo8_OQ-kvh-9g@mail.gmail.com>
 <CAJumaK_HJMASvUFkG=5oL-7b1SR=SPTC34wgcAUNk6bnkDTgxQ@mail.gmail.com>
 <CAMgWh9seCFyXbseTSU8rhk5byGV8AiniZZZJd=SKSS5wA7+8cQ@mail.gmail.com>
 <CAJumaK804pEUsstFyn6qyvw4cCwDxrve_YsZYkGPvwEejBwpag@mail.gmail.com>
Message-ID: <CAH0njdvY21SVo6pkoBk0nD0UEJryb_2M0rycF6MAnN9ekUPiXA@mail.gmail.com>

+1 from me, regardless of implementation.

On 4:18pm, Fri, Jul 17, 2015 Edward Kmett <ekmett at gmail.com> wrote:

> I'm more than open to switching to a more efficient solution.
>
> -Edward
>
> On Fri, Jul 17, 2015 at 5:16 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
>> The implementation could use some work. Something more like this, I think.
>>
>> (<|>) = foldr (\x k ys -> x : k (drop 1 ys)) id
>>
>> In pointless silliness, it's even
>>
>> foldr ((. (. (maybe ([]) snd . uncons))) . (.) . (:)) id
>> On Jul 17, 2015 2:15 PM, "Edward Kmett" <ekmett at gmail.com> wrote:
>>
>>> Er.. I obviously meant
>>>
>>> instance Alternative ZipList where
>>>    empty = ZipList []
>>>    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)
>>>
>>> sorry for any confusion.
>>>
>>> On Fri, Jul 17, 2015 at 11:37 AM, Edward Kmett <ekmett at gmail.com> wrote:
>>>
>>>> The ZipList data type admits one legal Alternative instance
>>>>
>>>> instance Alternative ZipList where
>>>>    pure = ZipList []
>>>>    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)
>>>>
>>>> The legality of this instance was first noted in
>>>> http://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/ppdp2015.pdf
>>>>
>>>> I propose adding this instance, which acts like a generalized version
>>>> of the Alternative for Maybe, choosing with a left bias.
>>>>
>>>> Discussion Period: 2 weeks
>>>>
>>>> -Edward
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20150720/2b84549e/attachment.html>

From michael at snoyman.com  Mon Jul 20 15:01:41 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 20 Jul 2015 15:01:41 +0000
Subject: QuickCheck failures with new 'tar' release...
In-Reply-To: <1436789552.26857.445.camel@googlemail.com>
References: <877fq9vx8h.fsf@ironicdesign.com>
 <1436789552.26857.445.camel@googlemail.com>
Message-ID: <CAKA2Jg+q6ELj3GGe3+z+mBNtKuUwPXKX8G_hasTmF1sBbj17HA@mail.gmail.com>

Hi Duncan,

Could you ping the list when the minor release is ready, so that I can bump
the version used by Stackage?

Also, a Github issue tracker for this would certainly make it easier to
know what's happening :)

Michael

On Mon, Jul 13, 2015 at 5:12 AM Duncan Coutts <duncan.coutts at googlemail.com>
wrote:

> On Thu, 2015-07-09 at 17:26 -0400, Michael Alan Dorman wrote:
> > I'm not sure if there's a more appropriate venue to bring this up; the
> > package doesn't seem to have any sort of explicit issue tracker.
> >
> > On the NixOS build servers, we're seeing across-the-board failures for
> > the 0.4.2.0 release of the 'tar' library, specifically, two properties
> > that were added in the latest release.
> >
> > It looks to me like prop_lookup is fundamentally broken---it falls over
> > in the face of a lookup for 'a/b' in a list of entries that includes
> > 'a/b/c/d', because while the library lookup function returns a match
> > including the remainder of the path as a result, the Data.List.lookup
> > that it's comparing against returns nothing.
> >
> > I don't see a way for the test as it is constituted to work reliably.
> > I'm going to guess that prop_valid suffers from a similar issue.
> >
> > Either way, it would be nice if they could either be corrected, or diked
> > out until that happens.
>
> Cheers, yes my mistake. I'll fix the test and do a minor release.
>
> Duncan
>
> _______________________________________________
> 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/20150720/4d301569/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Wed Jul 22 10:06:51 2015
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Wed, 22 Jul 2015 11:06:51 +0100
Subject: =?UTF-8?B?4oCYdGVtcG9yYXJ54oCZIHRha2VvdmVy?=
Message-ID: <55AF6B3B.8010103@fuuzetsu.co.uk>

Hi,

I'm looking to take over the ?temporary? package. This is to address the
issue of any patches/fixes into ?temporary? not being merged in a timely
manner[1]. This caused Roman Cheplyaka to create a fork package,
?temporary-rc?. It's less than ideal to have some packages use temporary
and others use temporary-rc (PackageImports needed?) so this is in
attempt to bring back temporary as the one true package to use here and
let the fork fall into obscurity, preferably deprecated.

The main user of temporary-rc is the popular tasty package which is
Roman's. If me/him/us both/someone (reliable/available) can take over
temporary, he seems to be willing to go back to using that instead of
the fork[2].

CCing the current maintainer. I think until Monday (27th) is a fair
notice though I point out more time elapsed on [1] without a reply.

[1]: http://www.haskell.org/pipermail/libraries/2014-May/022958.html
[2]: https://github.com/feuerbach/temporary/issues/1

-- 
Mateusz K.

From ivan.miljenovic at gmail.com  Wed Jul 22 13:07:52 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Wed, 22 Jul 2015 23:07:52 +1000
Subject: ANNOUNCE: fgl-5.5.2.0 and fgl-arbitrary-0.2.0.0
Message-ID: <CA+u6gbwfaZE0b1aLqmSyQqe4zhe9tmqd43B_dEPZ2mf=wNRY5g@mail.gmail.com>

I'm pleased to announce that I've (finally!) just released version
5.5.2.0 of [fgl].  Major changes in this release include a test suite,
refactorings, code clean-ups and the following potentially breaking
changes (in that they were previously unspecified or incorrect):


    - `nodeRange` and `nodeRangeM` for the various graph data
      structures erroneously returned `(0,0)` for empty graphs (making
      them indistinguishable from graphs containing the single node
      `0`).  They now match the default implementation of throwing an
      error.

    - The behaviour of `delLEdge` when dealing with multiple edges was
      unspecified; it now deletes only a single edge and the new
      function `delAllLEdge` deletes all edges matching the one
      provided.

All changes can be found in the changelog.

[fgl]: https://hackage.haskell.org/package/fgl

Along with this I'm releasing version 0.2.0.0 of [fgl-arbitrary] (i.e.
the "I finally build against the version on Hackage" release).

[fgl-arbitrary]: https://hackage.haskell.org/package/fgl-arbitrary

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

From jeffbrown.the at gmail.com  Wed Jul 22 19:21:56 2015
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Wed, 22 Jul 2015 12:21:56 -0700
Subject: [Haskell-cafe] ANNOUNCE: fgl-5.5.2.0 and fgl-arbitrary-0.2.0.0
In-Reply-To: <CA+u6gbwfaZE0b1aLqmSyQqe4zhe9tmqd43B_dEPZ2mf=wNRY5g@mail.gmail.com>
References: <CA+u6gbwfaZE0b1aLqmSyQqe4zhe9tmqd43B_dEPZ2mf=wNRY5g@mail.gmail.com>
Message-ID: <CAEc4Ma1x8bySjwzk5HSbAC_FDUvgtMokQecJ92uJZE59mBzmsw@mail.gmail.com>

Thanks, Ivan! It looks exciting. Is there a demo file floating around
somewhere? Martin Erwig's old site [1] for FGL includes some demonstration
code, which builds on a file called "test.hs" [2]; I know the site is
obsolete but are those aspects of it still useful?

[1] https://web.engr.oregonstate.edu/~erwig/fgl/haskell/
[2] https://web.engr.oregonstate.edu/~erwig/fgl/haskell/test.hs

On Wed, Jul 22, 2015 at 6:07 AM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> I'm pleased to announce that I've (finally!) just released version
> 5.5.2.0 of [fgl].  Major changes in this release include a test suite,
> refactorings, code clean-ups and the following potentially breaking
> changes (in that they were previously unspecified or incorrect):
>
>
>     - `nodeRange` and `nodeRangeM` for the various graph data
>       structures erroneously returned `(0,0)` for empty graphs (making
>       them indistinguishable from graphs containing the single node
>       `0`).  They now match the default implementation of throwing an
>       error.
>
>     - The behaviour of `delLEdge` when dealing with multiple edges was
>       unspecified; it now deletes only a single edge and the new
>       function `delAllLEdge` deletes all edges matching the one
>       provided.
>
> All changes can be found in the changelog.
>
> [fgl]: https://hackage.haskell.org/package/fgl
>
> Along with this I'm releasing version 0.2.0.0 of [fgl-arbitrary] (i.e.
> the "I finally build against the version on Hackage" release).
>
> [fgl-arbitrary]: https://hackage.haskell.org/package/fgl-arbitrary
>
> --
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com
> http://IvanMiljenovic.wordpress.com
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150722/8160d01d/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Wed Jul 22 21:17:33 2015
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Wed, 22 Jul 2015 22:17:33 +0100
Subject: ANN: haddock-2.16.1
Message-ID: <55B0086D.8000801@fuuzetsu.co.uk>

Hi,

We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I
inline the changelog at the bottom. It should work fine with 7.10.x GHC
family. The packages are already on Hackage: haddock for the executable,
haddock-api for the guts and use from Haskell and haddock-library which
is the comment parser.

It should also be shipping with GHC 7.10.2.

I think two things are worth mentioning before:

* The pending mathjax PR[1] is going to be included in future release of
Haddock. As it is likely to break the interface file version, I am
putting it off a bit to bundle with other possibly interface-breaking
changes.

* Our GSOC student has successfully completed first part of his
project[2]. It involves native source code highlighting and perhaps more
excitingly, source hyperlinking: you should now be able to click on
identifiers to be taken to their definitions. This change is not in
2.16.1 as it is rather recent so we erred on the side of safety when
picking what to release with GHC 7.10.2. You can try it by building
current Haddock master, should work with 7.10.x family.

As usual, if you want to contribute, please do so on GitHub. We're also
on IRC under #haddock.

Thanks!

Changes in version 2.16.1

 * Don't default to type constructors for out-of-scope names (#253 and
   #375)

 * Fix Hoogle display of constructors (#361)

 * Fully qualify names in Hoogle instances output (#263)

 * Output method documentation in Hoogle backend (#259)

 * Don't print instance safety information in Hoogle (#168)

 * Expand response files in arguments (#285)

 * Build the main executable with -threaded (#399)

 * Use SrcSpan of declarations for inferred type sigs (#207)

 * Fix cross-module instance locations (#383)

 * Fix alignment of Source link for instances in Firefox (#384)

[1]: https://github.com/haskell/haddock/pull/397
[2]: https://github.com/haskell/haddock/pull/410

-- 
Mateusz K.

From matthewtpickering at gmail.com  Wed Jul 22 21:43:13 2015
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 22 Jul 2015 23:43:13 +0200
Subject: ANN: haddock-2.16.1
In-Reply-To: <55B0086D.8000801@fuuzetsu.co.uk>
References: <55B0086D.8000801@fuuzetsu.co.uk>
Message-ID: <CALuQ0m_8_Y=UgisboYNxqyJ652CqETRBTDyiT1T8MzDqYK-Njw@mail.gmail.com>

The curious can see an example of this new hyperlinked source here[1].

Great work ?ukasz and Mateusz!

[1]: https://hackage.haskell.org/package/ghc-exactprint-0.3/docs/src/Language.Haskell.GHC.ExactPrint.html

On Wed, Jul 22, 2015 at 11:17 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> Hi,
>
> We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I
> inline the changelog at the bottom. It should work fine with 7.10.x GHC
> family. The packages are already on Hackage: haddock for the executable,
> haddock-api for the guts and use from Haskell and haddock-library which
> is the comment parser.
>
> It should also be shipping with GHC 7.10.2.
>
> I think two things are worth mentioning before:
>
> * The pending mathjax PR[1] is going to be included in future release of
> Haddock. As it is likely to break the interface file version, I am
> putting it off a bit to bundle with other possibly interface-breaking
> changes.
>
> * Our GSOC student has successfully completed first part of his
> project[2]. It involves native source code highlighting and perhaps more
> excitingly, source hyperlinking: you should now be able to click on
> identifiers to be taken to their definitions. This change is not in
> 2.16.1 as it is rather recent so we erred on the side of safety when
> picking what to release with GHC 7.10.2. You can try it by building
> current Haddock master, should work with 7.10.x family.
>
> As usual, if you want to contribute, please do so on GitHub. We're also
> on IRC under #haddock.
>
> Thanks!
>
> Changes in version 2.16.1
>
>  * Don't default to type constructors for out-of-scope names (#253 and
>    #375)
>
>  * Fix Hoogle display of constructors (#361)
>
>  * Fully qualify names in Hoogle instances output (#263)
>
>  * Output method documentation in Hoogle backend (#259)
>
>  * Don't print instance safety information in Hoogle (#168)
>
>  * Expand response files in arguments (#285)
>
>  * Build the main executable with -threaded (#399)
>
>  * Use SrcSpan of declarations for inferred type sigs (#207)
>
>  * Fix cross-module instance locations (#383)
>
>  * Fix alignment of Source link for instances in Firefox (#384)
>
> [1]: https://github.com/haskell/haddock/pull/397
> [2]: https://github.com/haskell/haddock/pull/410
>
> --
> Mateusz K.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From ivan.miljenovic at gmail.com  Wed Jul 22 22:29:09 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Thu, 23 Jul 2015 08:29:09 +1000
Subject: [Haskell-cafe] ANNOUNCE: fgl-5.5.2.0 and fgl-arbitrary-0.2.0.0
In-Reply-To: <CAEc4Ma1x8bySjwzk5HSbAC_FDUvgtMokQecJ92uJZE59mBzmsw@mail.gmail.com>
References: <CA+u6gbwfaZE0b1aLqmSyQqe4zhe9tmqd43B_dEPZ2mf=wNRY5g@mail.gmail.com>
 <CAEc4Ma1x8bySjwzk5HSbAC_FDUvgtMokQecJ92uJZE59mBzmsw@mail.gmail.com>
Message-ID: <CA+u6gbw-P-FrYbxhV6mQ18=zs5in-D4ESiO_HSe8p-aBijrGMg@mail.gmail.com>

On 23 July 2015 at 05:21, Jeffrey Brown <jeffbrown.the at gmail.com> wrote:
> Thanks, Ivan! It looks exciting. Is there a demo file floating around
> somewhere? Martin Erwig's old site [1] for FGL includes some demonstration
> code, which builds on a file called "test.hs" [2]; I know the site is
> obsolete but are those aspects of it still useful?
>
> [1] https://web.engr.oregonstate.edu/~erwig/fgl/haskell/
> [2] https://web.engr.oregonstate.edu/~erwig/fgl/haskell/test.hs

Most of those should still be valid, yes.

There's also the Examples module in fgl.

>
> On Wed, Jul 22, 2015 at 6:07 AM, Ivan Lazar Miljenovic
> <ivan.miljenovic at gmail.com> wrote:
>>
>> I'm pleased to announce that I've (finally!) just released version
>> 5.5.2.0 of [fgl].  Major changes in this release include a test suite,
>> refactorings, code clean-ups and the following potentially breaking
>> changes (in that they were previously unspecified or incorrect):
>>
>>
>>     - `nodeRange` and `nodeRangeM` for the various graph data
>>       structures erroneously returned `(0,0)` for empty graphs (making
>>       them indistinguishable from graphs containing the single node
>>       `0`).  They now match the default implementation of throwing an
>>       error.
>>
>>     - The behaviour of `delLEdge` when dealing with multiple edges was
>>       unspecified; it now deletes only a single edge and the new
>>       function `delAllLEdge` deletes all edges matching the one
>>       provided.
>>
>> All changes can be found in the changelog.
>>
>> [fgl]: https://hackage.haskell.org/package/fgl
>>
>> Along with this I'm releasing version 0.2.0.0 of [fgl-arbitrary] (i.e.
>> the "I finally build against the version on Hackage" release).
>>
>> [fgl-arbitrary]: https://hackage.haskell.org/package/fgl-arbitrary
>>
>> --
>> Ivan Lazar Miljenovic
>> Ivan.Miljenovic at gmail.com
>> http://IvanMiljenovic.wordpress.com
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>



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

From tikhon at jelv.is  Wed Jul 22 23:02:47 2015
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Wed, 22 Jul 2015 16:02:47 -0700
Subject: [Haskell-cafe] ANNOUNCE: fgl-5.5.2.0 and fgl-arbitrary-0.2.0.0
In-Reply-To: <CA+u6gbw-P-FrYbxhV6mQ18=zs5in-D4ESiO_HSe8p-aBijrGMg@mail.gmail.com>
References: <CA+u6gbwfaZE0b1aLqmSyQqe4zhe9tmqd43B_dEPZ2mf=wNRY5g@mail.gmail.com>
 <CAEc4Ma1x8bySjwzk5HSbAC_FDUvgtMokQecJ92uJZE59mBzmsw@mail.gmail.com>
 <CA+u6gbw-P-FrYbxhV6mQ18=zs5in-D4ESiO_HSe8p-aBijrGMg@mail.gmail.com>
Message-ID: <CAJN5CVJwk+VxDvV0_jMefE8OGaE57vJPxvZjtJvTnM6a=n-0Hg@mail.gmail.com>

If you want more demonstration, I wrote a blog post[1] a while back that
builds up the code to draw a maze using fgl. It only uses the basic
features of the library, but I think it's a good overview of the ideas
involved.

The code is up on GitHub[2] and should still work, although it might be
annoying to build because the drawing code uses Cairo and Gtk.

[1]: http://jelv.is/blog/Generating-Mazes-with-Inductive-Graphs/
[2]: https://github.com/TikhonJelvis/inductive-mazes

On Wed, Jul 22, 2015 at 3:29 PM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> On 23 July 2015 at 05:21, Jeffrey Brown <jeffbrown.the at gmail.com> wrote:
> > Thanks, Ivan! It looks exciting. Is there a demo file floating around
> > somewhere? Martin Erwig's old site [1] for FGL includes some
> demonstration
> > code, which builds on a file called "test.hs" [2]; I know the site is
> > obsolete but are those aspects of it still useful?
> >
> > [1] https://web.engr.oregonstate.edu/~erwig/fgl/haskell/
> > [2] https://web.engr.oregonstate.edu/~erwig/fgl/haskell/test.hs
>
> Most of those should still be valid, yes.
>
> There's also the Examples module in fgl.
>
> >
> > On Wed, Jul 22, 2015 at 6:07 AM, Ivan Lazar Miljenovic
> > <ivan.miljenovic at gmail.com> wrote:
> >>
> >> I'm pleased to announce that I've (finally!) just released version
> >> 5.5.2.0 of [fgl].  Major changes in this release include a test suite,
> >> refactorings, code clean-ups and the following potentially breaking
> >> changes (in that they were previously unspecified or incorrect):
> >>
> >>
> >>     - `nodeRange` and `nodeRangeM` for the various graph data
> >>       structures erroneously returned `(0,0)` for empty graphs (making
> >>       them indistinguishable from graphs containing the single node
> >>       `0`).  They now match the default implementation of throwing an
> >>       error.
> >>
> >>     - The behaviour of `delLEdge` when dealing with multiple edges was
> >>       unspecified; it now deletes only a single edge and the new
> >>       function `delAllLEdge` deletes all edges matching the one
> >>       provided.
> >>
> >> All changes can be found in the changelog.
> >>
> >> [fgl]: https://hackage.haskell.org/package/fgl
> >>
> >> Along with this I'm releasing version 0.2.0.0 of [fgl-arbitrary] (i.e.
> >> the "I finally build against the version on Hackage" release).
> >>
> >> [fgl-arbitrary]: https://hackage.haskell.org/package/fgl-arbitrary
> >>
> >> --
> >> Ivan Lazar Miljenovic
> >> Ivan.Miljenovic at gmail.com
> >> http://IvanMiljenovic.wordpress.com
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> >
>
>
>
> --
> 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/20150722/6f2ef8c2/attachment-0001.html>

From hesselink at gmail.com  Thu Jul 23 09:05:56 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Thu, 23 Jul 2015 11:05:56 +0200
Subject: =?UTF-8?B?UmU6IOKAmHRlbXBvcmFyeeKAmSB0YWtlb3Zlcg==?=
In-Reply-To: <55AF6B3B.8010103@fuuzetsu.co.uk>
References: <55AF6B3B.8010103@fuuzetsu.co.uk>
Message-ID: <CAPeieQGhc-q3ioaA=CHuGekB2SfBxGRYTqtQkqkq70h+rCr5Ow@mail.gmail.com>

Hi Mateusz,

Sounds good. I don't think Max is active anymore [1] and many of his
other packages have been taken over in the past years. Also given that
Roman also stated his intention to take over the package more than a
year ago, I think it's no problem to transfer maintainership to you on
Monday (even though the normal term is at least 2-6 weeks). It also
seems that this is not blocking the move back to temporary, since
there's currently no difference between the two packages.

I've created an issue on the hackage trustee tracker [2] to track the takeover.

Regards,

Erik

[1] https://mail.haskell.org/pipermail/libraries/2015-April/025570.html
[2] https://github.com/haskell-infra/hackage-trustees/issues/43

On Wed, Jul 22, 2015 at 12:06 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> Hi,
>
> I'm looking to take over the ?temporary? package. This is to address the
> issue of any patches/fixes into ?temporary? not being merged in a timely
> manner[1]. This caused Roman Cheplyaka to create a fork package,
> ?temporary-rc?. It's less than ideal to have some packages use temporary
> and others use temporary-rc (PackageImports needed?) so this is in
> attempt to bring back temporary as the one true package to use here and
> let the fork fall into obscurity, preferably deprecated.
>
> The main user of temporary-rc is the popular tasty package which is
> Roman's. If me/him/us both/someone (reliable/available) can take over
> temporary, he seems to be willing to go back to using that instead of
> the fork[2].
>
> CCing the current maintainer. I think until Monday (27th) is a fair
> notice though I point out more time elapsed on [1] without a reply.
>
> [1]: http://www.haskell.org/pipermail/libraries/2014-May/022958.html
> [2]: https://github.com/feuerbach/temporary/issues/1
>
> --
> Mateusz K.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From michael at snoyman.com  Thu Jul 23 13:34:39 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 23 Jul 2015 13:34:39 +0000
Subject: 'temporary' takeover
In-Reply-To: <CAPeieQGhc-q3ioaA=CHuGekB2SfBxGRYTqtQkqkq70h+rCr5Ow@mail.gmail.com>
References: <55AF6B3B.8010103@fuuzetsu.co.uk>
 <CAPeieQGhc-q3ioaA=CHuGekB2SfBxGRYTqtQkqkq70h+rCr5Ow@mail.gmail.com>
Message-ID: <CAKA2JgJ6yfdwM3cqdRtmvMkJ2Op4aVz46a5NRBob-LWoo82Bgw@mail.gmail.com>

Big +1 from me.

On Thu, Jul 23, 2015 at 2:06 AM Erik Hesselink <hesselink at gmail.com> wrote:

> Hi Mateusz,
>
> Sounds good. I don't think Max is active anymore [1] and many of his
> other packages have been taken over in the past years. Also given that
> Roman also stated his intention to take over the package more than a
> year ago, I think it's no problem to transfer maintainership to you on
> Monday (even though the normal term is at least 2-6 weeks). It also
> seems that this is not blocking the move back to temporary, since
> there's currently no difference between the two packages.
>
> I've created an issue on the hackage trustee tracker [2] to track the
> takeover.
>
> Regards,
>
> Erik
>
> [1] https://mail.haskell.org/pipermail/libraries/2015-April/025570.html
> [2] https://github.com/haskell-infra/hackage-trustees/issues/43
>
> On Wed, Jul 22, 2015 at 12:06 PM, Mateusz Kowalczyk
> <fuuzetsu at fuuzetsu.co.uk> wrote:
> > Hi,
> >
> > I'm looking to take over the ?temporary? package. This is to address the
> > issue of any patches/fixes into ?temporary? not being merged in a timely
> > manner[1]. This caused Roman Cheplyaka to create a fork package,
> > ?temporary-rc?. It's less than ideal to have some packages use temporary
> > and others use temporary-rc (PackageImports needed?) so this is in
> > attempt to bring back temporary as the one true package to use here and
> > let the fork fall into obscurity, preferably deprecated.
> >
> > The main user of temporary-rc is the popular tasty package which is
> > Roman's. If me/him/us both/someone (reliable/available) can take over
> > temporary, he seems to be willing to go back to using that instead of
> > the fork[2].
> >
> > CCing the current maintainer. I think until Monday (27th) is a fair
> > notice though I point out more time elapsed on [1] without a reply.
> >
> > [1]: http://www.haskell.org/pipermail/libraries/2014-May/022958.html
> > [2]: https://github.com/feuerbach/temporary/issues/1
> >
> > --
> > Mateusz K.
> > _______________________________________________
> > 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/20150723/33240716/attachment.html>

From lemming at henning-thielemann.de  Thu Jul 23 13:36:30 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 23 Jul 2015 15:36:30 +0200 (CEST)
Subject: =?ISO-8859-7?Q?Re=3A_=A1temporary=A2_takeover?=
In-Reply-To: <55AF6B3B.8010103@fuuzetsu.co.uk>
References: <55AF6B3B.8010103@fuuzetsu.co.uk>
Message-ID: <alpine.DEB.2.02.1507231535450.7370@sputnik>


I vote for a permanent takeover instead.

Sorry, couldn't resist. :-)

From michael at snoyman.com  Thu Jul 23 13:42:52 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 23 Jul 2015 13:42:52 +0000
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <moq7q7$t5d$1@ger.gmane.org>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <moq7q7$t5d$1@ger.gmane.org>
Message-ID: <CAKA2JgJ_dJM17skitwCQk649F5dnLzdfFFESnzXWQ=bQ5CzfEQ@mail.gmail.com>

On Thu, Jul 23, 2015 at 1:15 AM Heinrich Apfelmus <apfelmus at quantentunnel.de>
wrote:

> Mark Lentczner wrote:
> > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
> > shipping pre-built packages, so we banish cabal hell, and have a single
> > common way to 'get Haskell' that just works.*
> >
> > [..]
> >
> > We think this plan solves many different community needs:
> >
> >    - We have a clear way to "get Haskell" that works for a wide variety
> of
> >    use cases.
> >    - HP installer gets much smaller, and about as minimal as a working
> >    installation can get.
> >    - By leaving most packages out of the global database, users of
> >    cabal-install, will now have far fewer problems. Sandbox builds
> should now
> >    never give users "cabal hell" like warnings.
> >    - By building and installing the Platform packages into it's own
> package
> >    db, users get the benefit of building and installing these common
> packages
> >    only once per system, yet can easily bypass them for any given
> project if
> >    desired.
> >    - Since the Platform packages are now built and installed as needed,
> >    installing on smaller systems or servers without OpenGL will work.
>
> Sounds great to me! Personally, I do not mind how the Haskell Platform
> achieves these goals; I will simply adapt to whatever tools the platform
> happens to install on my machine.
>
> Hopefully, they come with suitable documentation. For instance, one
> thing I don't understand about  stack  yet is in which location it
> "magically" installs GHC and packages, and how I can invoke `ghci` from
> these locations. Somehow, I was unable to understand this from the FAQ.
>
>
>
>
I think this FAQ entry should help[1] on the first question:

> Note that stack setup installs GHC into
~/.stack/programs/$platform/ghc-$version/ and not a global location.

For the second question: either `stack ghci` or `stack exec ghci` should
achieve what you're looking for. The former is a bit more experimental, and
does more intelligent stuff at the project level as far as loading up your
code. The latter simply runs the ghci command with appropriate PATH and
GHC_PACKAGE_PATH environment variables set.

[1]
https://github.com/commercialhaskell/stack/wiki/FAQ#i-already-have-ghc-installed-can-i-still-use-stack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150723/a6f73752/attachment.html>

From ryan.gl.scott at gmail.com  Thu Jul 23 16:16:39 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Thu, 23 Jul 2015 11:16:39 -0500
Subject: Proposal: instance MonadIO Q
Message-ID: <CADdQpRBFNWidvrgXHNmkwGFwc8M-opmSVqq6r=Ng6MMwk8WD6g@mail.gmail.com>

Template Haskell currently has runIO :: IO a -> Q a , which allows you
to run IO actions with a guarantee of IO effects' ordering in a single
splice (but not necessarily the order in which all the Q splices are
run). If runIO is indeed a monad morphism, then there is a law-abiding
MonadIO Q instance that could be added to transformers:

instance MonadIO Q where
  liftIO = runIO

This would be useful for dealing with monad transformer stacks with Q
as the base monad (for an example, see genifunctors
(https://github.com/danr/genifunctors/blob/4677bb57423b1b380ce9b50cc3d765a5c49a957a/Data/Generics/Genifunctors.hs#L47).
The only catch is that transformers would have to depend on
template-haskell. I think this would be okay since no quasiquotation
is involved, but I wanted to hear others' opinions.

Ryan

From andreas.abel at ifi.lmu.de  Thu Jul 23 16:37:01 2015
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Thu, 23 Jul 2015 18:37:01 +0200
Subject: 'temporary' takeover
In-Reply-To: <CAKA2JgJ6yfdwM3cqdRtmvMkJ2Op4aVz46a5NRBob-LWoo82Bgw@mail.gmail.com>
References: <55AF6B3B.8010103@fuuzetsu.co.uk>
 <CAPeieQGhc-q3ioaA=CHuGekB2SfBxGRYTqtQkqkq70h+rCr5Ow@mail.gmail.com>
 <CAKA2JgJ6yfdwM3cqdRtmvMkJ2Op4aVz46a5NRBob-LWoo82Bgw@mail.gmail.com>
Message-ID: <55B1182D.9020404@ifi.lmu.de>

+1.  I think adding trusted developers as co-maintainers for 
unmaintained packages should be a rather quick process.  After all, once 
something on hackage and others to depend on it, ownership has little 
value in comparision to the common good of the community...

On 23.07.2015 15:34, Michael Snoyman wrote:
> Big +1 from me.
>
> On Thu, Jul 23, 2015 at 2:06 AM Erik Hesselink <hesselink at gmail.com
> <mailto:hesselink at gmail.com>> wrote:
>
>     Hi Mateusz,
>
>     Sounds good. I don't think Max is active anymore [1] and many of his
>     other packages have been taken over in the past years. Also given that
>     Roman also stated his intention to take over the package more than a
>     year ago, I think it's no problem to transfer maintainership to you on
>     Monday (even though the normal term is at least 2-6 weeks). It also
>     seems that this is not blocking the move back to temporary, since
>     there's currently no difference between the two packages.
>
>     I've created an issue on the hackage trustee tracker [2] to track
>     the takeover.
>
>     Regards,
>
>     Erik
>
>     [1] https://mail.haskell.org/pipermail/libraries/2015-April/025570.html
>     [2] https://github.com/haskell-infra/hackage-trustees/issues/43
>
>     On Wed, Jul 22, 2015 at 12:06 PM, Mateusz Kowalczyk
>     <fuuzetsu at fuuzetsu.co.uk <mailto:fuuzetsu at fuuzetsu.co.uk>> wrote:
>      > Hi,
>      >
>      > I'm looking to take over the ?temporary? package. This is to
>     address the
>      > issue of any patches/fixes into ?temporary? not being merged in a
>     timely
>      > manner[1]. This caused Roman Cheplyaka to create a fork package,
>      > ?temporary-rc?. It's less than ideal to have some packages use
>     temporary
>      > and others use temporary-rc (PackageImports needed?) so this is in
>      > attempt to bring back temporary as the one true package to use
>     here and
>      > let the fork fall into obscurity, preferably deprecated.
>      >
>      > The main user of temporary-rc is the popular tasty package which is
>      > Roman's. If me/him/us both/someone (reliable/available) can take over
>      > temporary, he seems to be willing to go back to using that instead of
>      > the fork[2].
>      >
>      > CCing the current maintainer. I think until Monday (27th) is a fair
>      > notice though I point out more time elapsed on [1] without a reply.
>      >
>      > [1]: http://www.haskell.org/pipermail/libraries/2014-May/022958.html
>      > [2]: https://github.com/feuerbach/temporary/issues/1
>      >
>      > --
>      > Mateusz K.
>      > _______________________________________________
>      > Libraries mailing list
>      > Libraries at haskell.org <mailto:Libraries at haskell.org>
>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


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

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

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

From hesselink at gmail.com  Thu Jul 23 17:11:46 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Thu, 23 Jul 2015 19:11:46 +0200
Subject: 'temporary' takeover
In-Reply-To: <55B1182D.9020404@ifi.lmu.de>
References: <55AF6B3B.8010103@fuuzetsu.co.uk>
 <CAPeieQGhc-q3ioaA=CHuGekB2SfBxGRYTqtQkqkq70h+rCr5Ow@mail.gmail.com>
 <CAKA2JgJ6yfdwM3cqdRtmvMkJ2Op4aVz46a5NRBob-LWoo82Bgw@mail.gmail.com>
 <55B1182D.9020404@ifi.lmu.de>
Message-ID: <CAPeieQF6k6edUSAiEmXzXnX97QPoptXQ_GzH=pgmJQDecAvM7w@mail.gmail.com>

Well, there is the takeover policy [1], which tries to balance the
good of the community with the sense of ownership package developers
have. I think that, combined with the ability of trustees to do quick
fixes, we're in pretty good shape to avoid both breakage of the
package ecosystem and at the same time giving people enough ownership
rights of their packages on hackage.

Regards,

Erik

[1] http://www.haskell.org/haskellwiki/Taking_over_a_package

On Thu, Jul 23, 2015 at 6:37 PM, Andreas Abel <andreas.abel at ifi.lmu.de> wrote:
> +1.  I think adding trusted developers as co-maintainers for unmaintained
> packages should be a rather quick process.  After all, once something on
> hackage and others to depend on it, ownership has little value in
> comparision to the common good of the community...
>
> On 23.07.2015 15:34, Michael Snoyman wrote:
>>
>> Big +1 from me.
>>
>> On Thu, Jul 23, 2015 at 2:06 AM Erik Hesselink <hesselink at gmail.com
>> <mailto:hesselink at gmail.com>> wrote:
>>
>>     Hi Mateusz,
>>
>>     Sounds good. I don't think Max is active anymore [1] and many of his
>>     other packages have been taken over in the past years. Also given that
>>     Roman also stated his intention to take over the package more than a
>>     year ago, I think it's no problem to transfer maintainership to you on
>>     Monday (even though the normal term is at least 2-6 weeks). It also
>>     seems that this is not blocking the move back to temporary, since
>>     there's currently no difference between the two packages.
>>
>>     I've created an issue on the hackage trustee tracker [2] to track
>>     the takeover.
>>
>>     Regards,
>>
>>     Erik
>>
>>     [1]
>> https://mail.haskell.org/pipermail/libraries/2015-April/025570.html
>>     [2] https://github.com/haskell-infra/hackage-trustees/issues/43
>>
>>     On Wed, Jul 22, 2015 at 12:06 PM, Mateusz Kowalczyk
>>     <fuuzetsu at fuuzetsu.co.uk <mailto:fuuzetsu at fuuzetsu.co.uk>> wrote:
>>      > Hi,
>>      >
>>      > I'm looking to take over the ?temporary? package. This is to
>>     address the
>>      > issue of any patches/fixes into ?temporary? not being merged in a
>>     timely
>>      > manner[1]. This caused Roman Cheplyaka to create a fork package,
>>      > ?temporary-rc?. It's less than ideal to have some packages use
>>     temporary
>>      > and others use temporary-rc (PackageImports needed?) so this is in
>>      > attempt to bring back temporary as the one true package to use
>>     here and
>>      > let the fork fall into obscurity, preferably deprecated.
>>      >
>>      > The main user of temporary-rc is the popular tasty package which is
>>      > Roman's. If me/him/us both/someone (reliable/available) can take
>> over
>>      > temporary, he seems to be willing to go back to using that instead
>> of
>>      > the fork[2].
>>      >
>>      > CCing the current maintainer. I think until Monday (27th) is a fair
>>      > notice though I point out more time elapsed on [1] without a reply.
>>      >
>>      > [1]:
>> http://www.haskell.org/pipermail/libraries/2014-May/022958.html
>>      > [2]: https://github.com/feuerbach/temporary/issues/1
>>      >
>>      > --
>>      > Mateusz K.
>>      > _______________________________________________
>>      > Libraries mailing list
>>      > Libraries at haskell.org <mailto:Libraries at haskell.org>
>>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>     _______________________________________________
>>     Libraries mailing list
>>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel at gu.se
> http://www2.tcs.ifi.lmu.de/~abel/

From david.feuer at gmail.com  Thu Jul 23 18:09:47 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 23 Jul 2015 14:09:47 -0400
Subject: Proposal: instance MonadIO Q
In-Reply-To: <CADdQpRBFNWidvrgXHNmkwGFwc8M-opmSVqq6r=Ng6MMwk8WD6g@mail.gmail.com>
References: <CADdQpRBFNWidvrgXHNmkwGFwc8M-opmSVqq6r=Ng6MMwk8WD6g@mail.gmail.com>
Message-ID: <CAMgWh9usZPBwqJrp8NRAPQWo92cBqupFfs8ROUf_=L6s_PJHDQ@mail.gmail.com>

I'm very much in the "Damn the torpedoes; full speed ahead" camp most of
the time, but not here. Transformers is a tiny step up from base. Why would
you make it depend on template haskell rather than the other way around?
On Jul 23, 2015 12:17 PM, "Ryan Scott" <ryan.gl.scott at gmail.com> wrote:

> Template Haskell currently has runIO :: IO a -> Q a , which allows you
> to run IO actions with a guarantee of IO effects' ordering in a single
> splice (but not necessarily the order in which all the Q splices are
> run). If runIO is indeed a monad morphism, then there is a law-abiding
> MonadIO Q instance that could be added to transformers:
>
> instance MonadIO Q where
>   liftIO = runIO
>
> This would be useful for dealing with monad transformer stacks with Q
> as the base monad (for an example, see genifunctors
> (
> https://github.com/danr/genifunctors/blob/4677bb57423b1b380ce9b50cc3d765a5c49a957a/Data/Generics/Genifunctors.hs#L47
> ).
> The only catch is that transformers would have to depend on
> template-haskell. I think this would be okay since no quasiquotation
> is involved, but I wanted to hear others' opinions.
>
> Ryan
> _______________________________________________
> 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/20150723/5c95bdcb/attachment.html>

From ryan.gl.scott at gmail.com  Thu Jul 23 18:15:07 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Thu, 23 Jul 2015 13:15:07 -0500
Subject: Proposal: instance MonadIO Q
Message-ID: <CADdQpRCB_0aj5Bp3han8wN7Hjr4S30GPw9dWxOqZbnyLCivMYQ@mail.gmail.com>

> Why would you make it depend on template haskell rather than the other
way around?

No particular reason, I'd be fine putting the instance in template-haskell
instead if that's more palatable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150723/542fb4d6/attachment.html>

From david.feuer at gmail.com  Thu Jul 23 18:19:52 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 23 Jul 2015 14:19:52 -0400
Subject: Proposal: instance MonadIO Q
In-Reply-To: <CADdQpRCB_0aj5Bp3han8wN7Hjr4S30GPw9dWxOqZbnyLCivMYQ@mail.gmail.com>
References: <CADdQpRCB_0aj5Bp3han8wN7Hjr4S30GPw9dWxOqZbnyLCivMYQ@mail.gmail.com>
Message-ID: <CAMgWh9u5GmhiutwN3BJG5VrUd621GDPnFcSJ8OeTmCRJnpyR+Q@mail.gmail.com>

I think making transformers depend on *anything* is a non-starter, so yes,
go the other way.
On Jul 23, 2015 2:15 PM, "Ryan Scott" <ryan.gl.scott at gmail.com> wrote:

> > Why would you make it depend on template haskell rather than the other
> way around?
>
> No particular reason, I'd be fine putting the instance in template-haskell
> instead if that's more palatable.
>
> _______________________________________________
> 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/20150723/4dfbd39d/attachment.html>

From mail at nh2.me  Thu Jul 23 19:20:30 2015
From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=)
Date: Thu, 23 Jul 2015 21:20:30 +0200
Subject: Proposal: instance MonadIO Q
In-Reply-To: <CAMgWh9usZPBwqJrp8NRAPQWo92cBqupFfs8ROUf_=L6s_PJHDQ@mail.gmail.com>
References: <CADdQpRBFNWidvrgXHNmkwGFwc8M-opmSVqq6r=Ng6MMwk8WD6g@mail.gmail.com>
 <CAMgWh9usZPBwqJrp8NRAPQWo92cBqupFfs8ROUf_=L6s_PJHDQ@mail.gmail.com>
Message-ID: <55B13E7E.1000802@nh2.me>

I'd also like to mention that there's a camp of people who'd like to
have a safe/pure version of TH that cannot do any IO - for changes like
the proposed one we should check whether they'd make that more difficult.

On 23/07/15 20:09, David Feuer wrote:
> I'm very much in the "Damn the torpedoes; full speed ahead" camp most of
> the time, but not here. Transformers is a tiny step up from base. Why
> would you make it depend on template haskell rather than the other way
> around?

From ekmett at gmail.com  Thu Jul 23 19:55:55 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 23 Jul 2015 15:55:55 -0400
Subject: Proposal: instance MonadIO Q
In-Reply-To: <55B13E7E.1000802@nh2.me>
References: <CADdQpRBFNWidvrgXHNmkwGFwc8M-opmSVqq6r=Ng6MMwk8WD6g@mail.gmail.com>
 <CAMgWh9usZPBwqJrp8NRAPQWo92cBqupFfs8ROUf_=L6s_PJHDQ@mail.gmail.com>
 <55B13E7E.1000802@nh2.me>
Message-ID: <CAJumaK_iL1sjPdjd0S6_Xc7bUPA+ZDsi0+Z8wZaiN5mv9o_GoQ@mail.gmail.com>

Alternately we could lift MonadIO into base.

This could be used eventually to lift more computations into MonadIO. Then
nobody incurs an extra dependency and we have a first step towards more
generic IO operations.

-Edward

On Thu, Jul 23, 2015 at 3:20 PM, Niklas Hamb?chen <mail at nh2.me> wrote:

> I'd also like to mention that there's a camp of people who'd like to
> have a safe/pure version of TH that cannot do any IO - for changes like
> the proposed one we should check whether they'd make that more difficult.
>
> On 23/07/15 20:09, David Feuer wrote:
> > I'm very much in the "Damn the torpedoes; full speed ahead" camp most of
> > the time, but not here. Transformers is a tiny step up from base. Why
> > would you make it depend on template haskell rather than the other way
> > around?
> _______________________________________________
> 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/20150723/d270efc8/attachment.html>

From ekmett at gmail.com  Thu Jul 23 19:56:44 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 23 Jul 2015 15:56:44 -0400
Subject: 'temporary' takeover
In-Reply-To: <CAKA2JgJ6yfdwM3cqdRtmvMkJ2Op4aVz46a5NRBob-LWoo82Bgw@mail.gmail.com>
References: <55AF6B3B.8010103@fuuzetsu.co.uk>
 <CAPeieQGhc-q3ioaA=CHuGekB2SfBxGRYTqtQkqkq70h+rCr5Ow@mail.gmail.com>
 <CAKA2JgJ6yfdwM3cqdRtmvMkJ2Op4aVz46a5NRBob-LWoo82Bgw@mail.gmail.com>
Message-ID: <CAJumaK_9gOwUdnx-wMrfp+wwbRTUmn2jyxeC-bUOCGm+UifagA@mail.gmail.com>

+1 here

On Thu, Jul 23, 2015 at 9:34 AM, Michael Snoyman <michael at snoyman.com>
wrote:

> Big +1 from me.
>
> On Thu, Jul 23, 2015 at 2:06 AM Erik Hesselink <hesselink at gmail.com>
> wrote:
>
>> Hi Mateusz,
>>
>> Sounds good. I don't think Max is active anymore [1] and many of his
>> other packages have been taken over in the past years. Also given that
>> Roman also stated his intention to take over the package more than a
>> year ago, I think it's no problem to transfer maintainership to you on
>> Monday (even though the normal term is at least 2-6 weeks). It also
>> seems that this is not blocking the move back to temporary, since
>> there's currently no difference between the two packages.
>>
>> I've created an issue on the hackage trustee tracker [2] to track the
>> takeover.
>>
>> Regards,
>>
>> Erik
>>
>> [1] https://mail.haskell.org/pipermail/libraries/2015-April/025570.html
>> [2] https://github.com/haskell-infra/hackage-trustees/issues/43
>>
>> On Wed, Jul 22, 2015 at 12:06 PM, Mateusz Kowalczyk
>> <fuuzetsu at fuuzetsu.co.uk> wrote:
>> > Hi,
>> >
>> > I'm looking to take over the ?temporary? package. This is to address the
>> > issue of any patches/fixes into ?temporary? not being merged in a timely
>> > manner[1]. This caused Roman Cheplyaka to create a fork package,
>> > ?temporary-rc?. It's less than ideal to have some packages use temporary
>> > and others use temporary-rc (PackageImports needed?) so this is in
>> > attempt to bring back temporary as the one true package to use here and
>> > let the fork fall into obscurity, preferably deprecated.
>> >
>> > The main user of temporary-rc is the popular tasty package which is
>> > Roman's. If me/him/us both/someone (reliable/available) can take over
>> > temporary, he seems to be willing to go back to using that instead of
>> > the fork[2].
>> >
>> > CCing the current maintainer. I think until Monday (27th) is a fair
>> > notice though I point out more time elapsed on [1] without a reply.
>> >
>> > [1]: http://www.haskell.org/pipermail/libraries/2014-May/022958.html
>> > [2]: https://github.com/feuerbach/temporary/issues/1
>> >
>> > --
>> > Mateusz K.
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150723/f051b162/attachment.html>

From david.feuer at gmail.com  Thu Jul 23 20:08:27 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 23 Jul 2015 16:08:27 -0400
Subject: Proposal: instance MonadIO Q
In-Reply-To: <CAJumaK_iL1sjPdjd0S6_Xc7bUPA+ZDsi0+Z8wZaiN5mv9o_GoQ@mail.gmail.com>
References: <CADdQpRBFNWidvrgXHNmkwGFwc8M-opmSVqq6r=Ng6MMwk8WD6g@mail.gmail.com>
 <CAMgWh9usZPBwqJrp8NRAPQWo92cBqupFfs8ROUf_=L6s_PJHDQ@mail.gmail.com>
 <55B13E7E.1000802@nh2.me>
 <CAJumaK_iL1sjPdjd0S6_Xc7bUPA+ZDsi0+Z8wZaiN5mv9o_GoQ@mail.gmail.com>
Message-ID: <CAMgWh9urMK_pr50TFh1vaqQUETe_SSXGWTmrebhHKVQGDW5ehg@mail.gmail.com>

Personally I'd think it sensible to push down Control.Monad.Trans.Class,
Control.Monad.Trans.Reader, and Control.Monad.Trans.State.Strict into base.
I don't know if any Writer or RWST variants are quite ready for that sort
of treatment, and ListT obviously isn't.
On Jul 23, 2015 3:55 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

> Alternately we could lift MonadIO into base.
>
> This could be used eventually to lift more computations into MonadIO. Then
> nobody incurs an extra dependency and we have a first step towards more
> generic IO operations.
>
> -Edward
>
> On Thu, Jul 23, 2015 at 3:20 PM, Niklas Hamb?chen <mail at nh2.me> wrote:
>
>> I'd also like to mention that there's a camp of people who'd like to
>> have a safe/pure version of TH that cannot do any IO - for changes like
>> the proposed one we should check whether they'd make that more difficult.
>>
>> On 23/07/15 20:09, David Feuer wrote:
>> > I'm very much in the "Damn the torpedoes; full speed ahead" camp most of
>> > the time, but not here. Transformers is a tiny step up from base. Why
>> > would you make it depend on template haskell rather than the other way
>> > around?
>> _______________________________________________
>> 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/20150723/c94d966f/attachment-0001.html>

From ekmett at gmail.com  Thu Jul 23 20:35:34 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 23 Jul 2015 16:35:34 -0400
Subject: Proposal: instance MonadIO Q
In-Reply-To: <CAMgWh9urMK_pr50TFh1vaqQUETe_SSXGWTmrebhHKVQGDW5ehg@mail.gmail.com>
References: <CADdQpRBFNWidvrgXHNmkwGFwc8M-opmSVqq6r=Ng6MMwk8WD6g@mail.gmail.com>
 <CAMgWh9usZPBwqJrp8NRAPQWo92cBqupFfs8ROUf_=L6s_PJHDQ@mail.gmail.com>
 <55B13E7E.1000802@nh2.me>
 <CAJumaK_iL1sjPdjd0S6_Xc7bUPA+ZDsi0+Z8wZaiN5mv9o_GoQ@mail.gmail.com>
 <CAMgWh9urMK_pr50TFh1vaqQUETe_SSXGWTmrebhHKVQGDW5ehg@mail.gmail.com>
Message-ID: <CAJumaK_W=yNJMSSHkLhc12EEW4s+8hhURZWMbJU=PDwkm9JGfA@mail.gmail.com>

I'd hesitate to bring in MonadTrans or the rest of transformers into base,
but MonadIO is fully non-controversial and fully Haskell 98.

Lifting up and dropping that *one* module into base is a fairly simple
change.

SPJ made a suggestion of adopting some more of the Data.Functor.* modules
into base a year or so back. We took him up on the idea of Identity, but
punted on the remainder. It may make sense to put together a separate
proposal for the integration of Data.Functor.{Sum, Product, Compose}.

I would only support either proposal if they brought the modules in
unmolested, without bikeshedding.

This would leave the "transformers" in the transformers package.

There are reasons not to like the existing MonadTrans class and reasons as
well not to change it. There is also no need for it in base, nothing in
base is set up in a fashion that it'd even be possible to make use of it to
generalize any existing signatures.

-Edward

On Thu, Jul 23, 2015 at 4:08 PM, David Feuer <david.feuer at gmail.com> wrote:

> Personally I'd think it sensible to push down Control.Monad.Trans.Class,
> Control.Monad.Trans.Reader, and Control.Monad.Trans.State.Strict into base.
> I don't know if any Writer or RWST variants are quite ready for that sort
> of treatment, and ListT obviously isn't.
> On Jul 23, 2015 3:55 PM, "Edward Kmett" <ekmett at gmail.com> wrote:
>
>> Alternately we could lift MonadIO into base.
>>
>> This could be used eventually to lift more computations into MonadIO.
>> Then nobody incurs an extra dependency and we have a first step towards
>> more generic IO operations.
>>
>> -Edward
>>
>> On Thu, Jul 23, 2015 at 3:20 PM, Niklas Hamb?chen <mail at nh2.me> wrote:
>>
>>> I'd also like to mention that there's a camp of people who'd like to
>>> have a safe/pure version of TH that cannot do any IO - for changes like
>>> the proposed one we should check whether they'd make that more difficult.
>>>
>>> On 23/07/15 20:09, David Feuer wrote:
>>> > I'm very much in the "Damn the torpedoes; full speed ahead" camp most
>>> of
>>> > the time, but not here. Transformers is a tiny step up from base. Why
>>> > would you make it depend on template haskell rather than the other way
>>> > around?
>>> _______________________________________________
>>> 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/20150723/36e867d4/attachment.html>

From qdunkan at gmail.com  Thu Jul 23 20:44:12 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Thu, 23 Jul 2015 13:44:12 -0700
Subject: Proposal: instance MonadIO Q
In-Reply-To: <CAJumaK_W=yNJMSSHkLhc12EEW4s+8hhURZWMbJU=PDwkm9JGfA@mail.gmail.com>
References: <CADdQpRBFNWidvrgXHNmkwGFwc8M-opmSVqq6r=Ng6MMwk8WD6g@mail.gmail.com>
 <CAMgWh9usZPBwqJrp8NRAPQWo92cBqupFfs8ROUf_=L6s_PJHDQ@mail.gmail.com>
 <55B13E7E.1000802@nh2.me>
 <CAJumaK_iL1sjPdjd0S6_Xc7bUPA+ZDsi0+Z8wZaiN5mv9o_GoQ@mail.gmail.com>
 <CAMgWh9urMK_pr50TFh1vaqQUETe_SSXGWTmrebhHKVQGDW5ehg@mail.gmail.com>
 <CAJumaK_W=yNJMSSHkLhc12EEW4s+8hhURZWMbJU=PDwkm9JGfA@mail.gmail.com>
Message-ID: <CACbaDy44XxNy+jZREkWy25=xmuAJwcOVckCrJ4DY3oFknK25hQ@mail.gmail.com>

On Thu, Jul 23, 2015 at 1:35 PM, Edward Kmett <ekmett at gmail.com> wrote:
> I'd hesitate to bring in MonadTrans or the rest of transformers into base,
> but MonadIO is fully non-controversial and fully Haskell 98.

Doesn't GHC internally have its own MonadIO?  I remember being really
confused by type errors from the GHC API until I figured out that the
MonadIO it used was not the one I was expecting.  It would be nice to
merge those.

From ryan.gl.scott at gmail.com  Thu Jul 23 21:29:39 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Thu, 23 Jul 2015 16:29:39 -0500
Subject: Proposal: instance MonadIO Q
Message-ID: <CADdQpRAGzTiwiZQ26Nvse1vpjLvrKo53nZPJGa5JQae_7xLGCw@mail.gmail.com>

It looks like GHC's internal MonadIO was replaced with the one from
transformers in 2013 [1], so this is already fixed.

Also, +1 on the MonadIO to base suggestion, now that's there's some
momentum behind that idea.

----------
[1] http://git.haskell.org/ghc.git/blobdiff/b13d546f9c454e6d2a15c20a3e10ec47328e33db..71feb1025eed0c3cc849c85e2b00e16bc1a21790:/compiler/utils/MonadUtils.hs

From ekmett at gmail.com  Thu Jul 23 23:18:15 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 23 Jul 2015 19:18:15 -0400
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
Message-ID: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>

As part of GHC 7.10 we moved Data.Functor.Identity from transformers into
base. (We'd previously had a private, equivalent definition buried in
Data.Traversable that we didn't export.)

In a similar vein, I hereby propose moving Data.Functor.Sum,
Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes into
base as they exist in transformers, without unduly bikeshedding their APIs.

This would effectively reduce the role of transformers to simply supplying
actual transformers and continue the general pattern of universal
constructions migrating into base. Without bikeshedding their
implementations this migration becomes a no-op for existing users.

The most awkward of these is the Data.Functor.Classes API, but it affects a
number of their instances, and without it, those instances would have to be
orphans, so my gut reaction would be to say yes, we should move that as
well. There are also some in-flight API changes in the works in the HEAD
version of transformers for which a base-based version of the API could
exploit DefaultSignatures to ease migration.

I'm rather deliberately not including Data.Functor.Constant in this
proposal as when it has been discussed in the past, Const from
Control.Applicative has effectively grown to subsume that role. That said,
we if we bring in the rest of this stuff we could migrate it to
Data.Functor.Const and simply re-export it from Control.Applicative to
avoid breakage.

So, as a concrete proposal I propose that we:

1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and
Data.Functor.Classes into base.

2.) Move Control.Applicative's Const into Data.Functor.Const, but continue
to re-export it from Control.Applicative.

3.) Add whatever missing, sensible, instances make sense after the
transition that were ruled out by these modules' previous placement. *e.g.*
Data, Generic, Generic1.

Discussion Period: 2 weeks

-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150723/03362bba/attachment.html>

From david.feuer at gmail.com  Thu Jul 23 23:39:37 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 23 Jul 2015 19:39:37 -0400
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
In-Reply-To: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
References: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
Message-ID: <CAMgWh9sP8Uri1_8hSieciPQQPrLiGqrNvZJ1cHuQ7ZGcinSDQQ@mail.gmail.com>

The biggest problem with Constant is the bloody name. The one from
transformers is called Constant, while the one in Control.Applicative is
called Const, so they are incompatible. I have no idea how to fix that.
On Jul 23, 2015 7:18 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

> As part of GHC 7.10 we moved Data.Functor.Identity from transformers into
> base. (We'd previously had a private, equivalent definition buried in
> Data.Traversable that we didn't export.)
>
> In a similar vein, I hereby propose moving Data.Functor.Sum,
> Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes into
> base as they exist in transformers, without unduly bikeshedding their
> APIs.
>
> This would effectively reduce the role of transformers to simply
> supplying actual transformers and continue the general pattern of universal
> constructions migrating into base. Without bikeshedding their
> implementations this migration becomes a no-op for existing users.
>
> The most awkward of these is the Data.Functor.Classes API, but it affects
> a number of their instances, and without it, those instances would have to
> be orphans, so my gut reaction would be to say yes, we should move that as
> well. There are also some in-flight API changes in the works in the HEAD
> version of transformers for which a base-based version of the API could
> exploit DefaultSignatures to ease migration.
>
> I'm rather deliberately not including Data.Functor.Constant in this
> proposal as when it has been discussed in the past, Const from
> Control.Applicative has effectively grown to subsume that role. That
> said, we if we bring in the rest of this stuff we could migrate it to
> Data.Functor.Const and simply re-export it from Control.Applicative to
> avoid breakage.
>
> So, as a concrete proposal I propose that we:
>
> 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and
> Data.Functor.Classes into base.
>
> 2.) Move Control.Applicative's Const into Data.Functor.Const, but
> continue to re-export it from Control.Applicative.
>
> 3.) Add whatever missing, sensible, instances make sense after the
> transition that were ruled out by these modules' previous placement.
> *e.g.* Data, Generic, Generic1.
>
> Discussion Period: 2 weeks
>
> -Edward Kmett
>
> _______________________________________________
> 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/20150723/449b858b/attachment-0001.html>

From kenta at mit.edu  Thu Jul 23 23:49:47 2015
From: kenta at mit.edu (Ken T Takusagawa)
Date: Thu, 23 Jul 2015 19:49:47 -0400 (EDT)
Subject: Proposal: genericReplicateM
Message-ID: <alpine.DEB.2.10.1507231947010.16233@contents-vnder-pressvre.mit.edu>

Overloaded versions of replicateM and replicateM_ for any 
Integral type:

genericReplicateM :: (Monad m, Integral i) => i -> m a -> m [a]
genericReplicateM n = sequence . genericReplicate n

genericReplicateM_ :: (Monad m, Integral i) => i -> m a -> m ()
genericReplicateM_ n = sequence_ . genericReplicate n

--ken

From ekmett at gmail.com  Fri Jul 24 00:22:32 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 23 Jul 2015 20:22:32 -0400
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
In-Reply-To: <CAMgWh9sP8Uri1_8hSieciPQQPrLiGqrNvZJ1cHuQ7ZGcinSDQQ@mail.gmail.com>
References: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
 <CAMgWh9sP8Uri1_8hSieciPQQPrLiGqrNvZJ1cHuQ7ZGcinSDQQ@mail.gmail.com>
Message-ID: <CAJumaK--Y159L3OkTYG9gEaMnaFDNkmiOaDXHfp0c-b0yjExiQ@mail.gmail.com>

The fix is to remove the one from transformers, nobody uses the thing.
Hence why it was decidedly not included in this proposal.

-Edward

On Thu, Jul 23, 2015 at 7:39 PM, David Feuer <david.feuer at gmail.com> wrote:

> The biggest problem with Constant is the bloody name. The one from
> transformers is called Constant, while the one in Control.Applicative is
> called Const, so they are incompatible. I have no idea how to fix that.
> On Jul 23, 2015 7:18 PM, "Edward Kmett" <ekmett at gmail.com> wrote:
>
>> As part of GHC 7.10 we moved Data.Functor.Identity from transformers
>> into base. (We'd previously had a private, equivalent definition buried
>> in Data.Traversable that we didn't export.)
>>
>> In a similar vein, I hereby propose moving Data.Functor.Sum,
>> Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes
>> into base as they exist in transformers, without unduly bikeshedding
>> their APIs.
>>
>> This would effectively reduce the role of transformers to simply
>> supplying actual transformers and continue the general pattern of universal
>> constructions migrating into base. Without bikeshedding their
>> implementations this migration becomes a no-op for existing users.
>>
>> The most awkward of these is the Data.Functor.Classes API, but it
>> affects a number of their instances, and without it, those instances would
>> have to be orphans, so my gut reaction would be to say yes, we should move
>> that as well. There are also some in-flight API changes in the works in the
>> HEAD version of transformers for which a base-based version of the API
>> could exploit DefaultSignatures to ease migration.
>>
>> I'm rather deliberately not including Data.Functor.Constant in this
>> proposal as when it has been discussed in the past, Const from
>> Control.Applicative has effectively grown to subsume that role. That
>> said, we if we bring in the rest of this stuff we could migrate it to
>> Data.Functor.Const and simply re-export it from Control.Applicative to
>> avoid breakage.
>>
>> So, as a concrete proposal I propose that we:
>>
>> 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose
>> and Data.Functor.Classes into base.
>>
>> 2.) Move Control.Applicative's Const into Data.Functor.Const, but
>> continue to re-export it from Control.Applicative.
>>
>> 3.) Add whatever missing, sensible, instances make sense after the
>> transition that were ruled out by these modules' previous placement.
>> *e.g.* Data, Generic, Generic1.
>>
>> Discussion Period: 2 weeks
>>
>> -Edward Kmett
>>
>> _______________________________________________
>> 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/20150723/6cef317d/attachment.html>

From michael at snoyman.com  Fri Jul 24 00:30:07 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Fri, 24 Jul 2015 00:30:07 +0000
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
In-Reply-To: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
References: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
Message-ID: <CAKA2JgLzbZe8gxRgD1YR6vRLREiEH913T2sL0aE2JVEZp+N8rw@mail.gmail.com>

This sounds reasonable, +1. I notice that there was also mention earlier
today about MonadIO, and that it was not mentioned in this email. Does that
mean that a separate proposal may be coming?

On Thu, Jul 23, 2015 at 4:18 PM Edward Kmett <ekmett at gmail.com> wrote:

> As part of GHC 7.10 we moved Data.Functor.Identity from transformers into
> base. (We'd previously had a private, equivalent definition buried in
> Data.Traversable that we didn't export.)
>
> In a similar vein, I hereby propose moving Data.Functor.Sum,
> Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes into
> base as they exist in transformers, without unduly bikeshedding their
> APIs.
>
> This would effectively reduce the role of transformers to simply
> supplying actual transformers and continue the general pattern of universal
> constructions migrating into base. Without bikeshedding their
> implementations this migration becomes a no-op for existing users.
>
> The most awkward of these is the Data.Functor.Classes API, but it affects
> a number of their instances, and without it, those instances would have to
> be orphans, so my gut reaction would be to say yes, we should move that as
> well. There are also some in-flight API changes in the works in the HEAD
> version of transformers for which a base-based version of the API could
> exploit DefaultSignatures to ease migration.
>
> I'm rather deliberately not including Data.Functor.Constant in this
> proposal as when it has been discussed in the past, Const from
> Control.Applicative has effectively grown to subsume that role. That
> said, we if we bring in the rest of this stuff we could migrate it to
> Data.Functor.Const and simply re-export it from Control.Applicative to
> avoid breakage.
>
> So, as a concrete proposal I propose that we:
>
> 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and
> Data.Functor.Classes into base.
>
> 2.) Move Control.Applicative's Const into Data.Functor.Const, but
> continue to re-export it from Control.Applicative.
>
> 3.) Add whatever missing, sensible, instances make sense after the
> transition that were ruled out by these modules' previous placement.
> *e.g.* Data, Generic, Generic1.
>
> Discussion Period: 2 weeks
>
> -Edward Kmett
> _______________________________________________
> 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/20150724/581a8d00/attachment.html>

From ekmett at gmail.com  Fri Jul 24 00:40:20 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 23 Jul 2015 20:40:20 -0400
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
In-Reply-To: <CAKA2JgLzbZe8gxRgD1YR6vRLREiEH913T2sL0aE2JVEZp+N8rw@mail.gmail.com>
References: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
 <CAKA2JgLzbZe8gxRgD1YR6vRLREiEH913T2sL0aE2JVEZp+N8rw@mail.gmail.com>
Message-ID: <CAJumaK_MX+u_RkwjfS158v0zi4PEdHadWSMW2VnbzCaEAhjNSw@mail.gmail.com>

I think I'd like to consider that a separate proposal and let it succeed or
fail on its own merits.

-Edward

On Thu, Jul 23, 2015 at 8:30 PM, Michael Snoyman <michael at snoyman.com>
wrote:

> This sounds reasonable, +1. I notice that there was also mention earlier
> today about MonadIO, and that it was not mentioned in this email. Does that
> mean that a separate proposal may be coming?
>
> On Thu, Jul 23, 2015 at 4:18 PM Edward Kmett <ekmett at gmail.com> wrote:
>
>> As part of GHC 7.10 we moved Data.Functor.Identity from transformers
>> into base. (We'd previously had a private, equivalent definition buried
>> in Data.Traversable that we didn't export.)
>>
>> In a similar vein, I hereby propose moving Data.Functor.Sum,
>> Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes
>> into base as they exist in transformers, without unduly bikeshedding
>> their APIs.
>>
>> This would effectively reduce the role of transformers to simply
>> supplying actual transformers and continue the general pattern of universal
>> constructions migrating into base. Without bikeshedding their
>> implementations this migration becomes a no-op for existing users.
>>
>> The most awkward of these is the Data.Functor.Classes API, but it
>> affects a number of their instances, and without it, those instances would
>> have to be orphans, so my gut reaction would be to say yes, we should move
>> that as well. There are also some in-flight API changes in the works in the
>> HEAD version of transformers for which a base-based version of the API
>> could exploit DefaultSignatures to ease migration.
>>
>> I'm rather deliberately not including Data.Functor.Constant in this
>> proposal as when it has been discussed in the past, Const from
>> Control.Applicative has effectively grown to subsume that role. That
>> said, we if we bring in the rest of this stuff we could migrate it to
>> Data.Functor.Const and simply re-export it from Control.Applicative to
>> avoid breakage.
>>
>> So, as a concrete proposal I propose that we:
>>
>> 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose
>> and Data.Functor.Classes into base.
>>
>> 2.) Move Control.Applicative's Const into Data.Functor.Const, but
>> continue to re-export it from Control.Applicative.
>>
>> 3.) Add whatever missing, sensible, instances make sense after the
>> transition that were ruled out by these modules' previous placement.
>> *e.g.* Data, Generic, Generic1.
>>
>> Discussion Period: 2 weeks
>>
>> -Edward Kmett
>> _______________________________________________
>> 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/20150723/cf9b66f3/attachment-0001.html>

From ryan.gl.scott at gmail.com  Fri Jul 24 03:13:38 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Thu, 23 Jul 2015 22:13:38 -0500
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
Message-ID: <CADdQpRA+X5-biyBS9X273pXL2GfGj=nq2Np5kjy0epxqFrPgBA@mail.gmail.com>

I really like this proposal, especially since having convenient Eq1,
Ord1, Read1, Show1, etc. instances is something I've wanted for a
while.

I have some questions about some specifics:

1. Just to verify, you're proposing a breaking change in which
Data.Functor.Constant no longer exports Constant, but rather Const?
2. You mentioned that the additions to base could use
DefaultSignatures. Could you give an example of how this would work?

From marcin.jan.mrotek at gmail.com  Fri Jul 24 07:08:02 2015
From: marcin.jan.mrotek at gmail.com (Marcin Mrotek)
Date: Fri, 24 Jul 2015 09:08:02 +0200
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
In-Reply-To: <CADdQpRA+X5-biyBS9X273pXL2GfGj=nq2Np5kjy0epxqFrPgBA@mail.gmail.com>
References: <CADdQpRA+X5-biyBS9X273pXL2GfGj=nq2Np5kjy0epxqFrPgBA@mail.gmail.com>
Message-ID: <CAJcfPzkRCWyRjuBd2kLxrTVqN76U8pbCd3crNvUQqy=Ka=0zuQ@mail.gmail.com>

Does it count as bikeshedding if I'd suggest to make them polykinded?
I think Vinyl would benefit from this:
https://hackage.haskell.org/package/vinyl-0.5.1/docs/Data-Vinyl-Functor.html

Best regards,
Marcin Mrotek

From lambda.fairy at gmail.com  Fri Jul 24 11:23:02 2015
From: lambda.fairy at gmail.com (Chris Wong)
Date: Fri, 24 Jul 2015 23:23:02 +1200
Subject: [Haskell-cafe] ANN: haddock-2.16.1
In-Reply-To: <CAPabhsKDw+M=y6PnLmDfz0ePc5dnA6LmP3XRaexbrvtykWJUdg@mail.gmail.com>
References: <55B0086D.8000801@fuuzetsu.co.uk>
 <CALuQ0m_8_Y=UgisboYNxqyJ652CqETRBTDyiT1T8MzDqYK-Njw@mail.gmail.com>
 <CAPabhsKDw+M=y6PnLmDfz0ePc5dnA6LmP3XRaexbrvtykWJUdg@mail.gmail.com>
Message-ID: <CANQO64JG4sbuhQY9RP=O2+CV0UGMj4JTv+2j=c42DoQpN_5a2w@mail.gmail.com>

On Fri, Jul 24, 2015 at 10:24 PM, Tomas Carnecky
<tomas.carnecky at gmail.com> wrote:
> Will hackage rebuild all existing documentation or only when I upload a new
> version?

IIRC, it will only build a package when its documentation is not present.

> If not automatically, can I manually tell hackage to rebuild the
> docs?

Go to the package page, and click the "edit package information" link
at the bottom. There should be an option to clear and rebuild the
docs.

>
> On Wed, Jul 22, 2015 at 11:43 PM Matthew Pickering
> <matthewtpickering at gmail.com> wrote:
>>
>> The curious can see an example of this new hyperlinked source here[1].
>>
>> Great work ?ukasz and Mateusz!
>>
>> [1]:
>> https://hackage.haskell.org/package/ghc-exactprint-0.3/docs/src/Language.Haskell.GHC.ExactPrint.html
>>
>> On Wed, Jul 22, 2015 at 11:17 PM, Mateusz Kowalczyk
>> <fuuzetsu at fuuzetsu.co.uk> wrote:
>> > Hi,
>> >
>> > We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I
>> > inline the changelog at the bottom. It should work fine with 7.10.x GHC
>> > family. The packages are already on Hackage: haddock for the executable,
>> > haddock-api for the guts and use from Haskell and haddock-library which
>> > is the comment parser.
>> >
>> > It should also be shipping with GHC 7.10.2.
>> >
>> > I think two things are worth mentioning before:
>> >
>> > * The pending mathjax PR[1] is going to be included in future release of
>> > Haddock. As it is likely to break the interface file version, I am
>> > putting it off a bit to bundle with other possibly interface-breaking
>> > changes.
>> >
>> > * Our GSOC student has successfully completed first part of his
>> > project[2]. It involves native source code highlighting and perhaps more
>> > excitingly, source hyperlinking: you should now be able to click on
>> > identifiers to be taken to their definitions. This change is not in
>> > 2.16.1 as it is rather recent so we erred on the side of safety when
>> > picking what to release with GHC 7.10.2. You can try it by building
>> > current Haddock master, should work with 7.10.x family.
>> >
>> > As usual, if you want to contribute, please do so on GitHub. We're also
>> > on IRC under #haddock.
>> >
>> > Thanks!
>> >
>> > Changes in version 2.16.1
>> >
>> >  * Don't default to type constructors for out-of-scope names (#253 and
>> >    #375)
>> >
>> >  * Fix Hoogle display of constructors (#361)
>> >
>> >  * Fully qualify names in Hoogle instances output (#263)
>> >
>> >  * Output method documentation in Hoogle backend (#259)
>> >
>> >  * Don't print instance safety information in Hoogle (#168)
>> >
>> >  * Expand response files in arguments (#285)
>> >
>> >  * Build the main executable with -threaded (#399)
>> >
>> >  * Use SrcSpan of declarations for inferred type sigs (#207)
>> >
>> >  * Fix cross-module instance locations (#383)
>> >
>> >  * Fix alignment of Source link for instances in Firefox (#384)
>> >
>> > [1]: https://github.com/haskell/haddock/pull/397
>> > [2]: https://github.com/haskell/haddock/pull/410
>> >
>> > --
>> > Mateusz K.
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Chris Wong (https://lambda.xyz)

"Humans find such fascinating ways to waste their time."
    -- Steven Universe

From bernardy at chalmers.se  Fri Jul 24 11:44:59 2015
From: bernardy at chalmers.se (Jean-Philippe Bernardy)
Date: Fri, 24 Jul 2015 13:44:59 +0200
Subject: Intention to takeover glpk-hs
Message-ID: <CAAB3OF=B1eDNSQS5HBMf6b-=H0X2-qFLpwudQikMFEsppG727g@mail.gmail.com>

Hi,

I intend to take over the glpk-hs package from Louis, who did not
respond to my direct request, made June 22nd.

The last update to the package was made in 2012 and it does not
compile with ghc 7.10.

Cheers,
JP.

From ekmett at gmail.com  Fri Jul 24 12:30:44 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 24 Jul 2015 08:30:44 -0400
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
In-Reply-To: <CAJcfPzkRCWyRjuBd2kLxrTVqN76U8pbCd3crNvUQqy=Ka=0zuQ@mail.gmail.com>
References: <CADdQpRA+X5-biyBS9X273pXL2GfGj=nq2Np5kjy0epxqFrPgBA@mail.gmail.com>
 <CAJcfPzkRCWyRjuBd2kLxrTVqN76U8pbCd3crNvUQqy=Ka=0zuQ@mail.gmail.com>
Message-ID: <CAJumaK-pB_ytx9bYgB=EwQ7_mjq=hoQTybw=v1umD30uDrt+bg@mail.gmail.com>

Enabling PolyKinds is actually one motivation for doing the move in the
first place. It changes nothing about the modules involved when used in
code that doesn't turn on the extension.

-Edward

On Fri, Jul 24, 2015 at 3:08 AM, Marcin Mrotek <marcin.jan.mrotek at gmail.com>
wrote:

> Does it count as bikeshedding if I'd suggest to make them polykinded?
> I think Vinyl would benefit from this:
>
> https://hackage.haskell.org/package/vinyl-0.5.1/docs/Data-Vinyl-Functor.html
>
> Best regards,
> Marcin Mrotek
> _______________________________________________
> 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/20150724/d2d7920e/attachment.html>

From ekmett at gmail.com  Fri Jul 24 12:36:36 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 24 Jul 2015 08:36:36 -0400
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
In-Reply-To: <CADdQpRA+X5-biyBS9X273pXL2GfGj=nq2Np5kjy0epxqFrPgBA@mail.gmail.com>
References: <CADdQpRA+X5-biyBS9X273pXL2GfGj=nq2Np5kjy0epxqFrPgBA@mail.gmail.com>
Message-ID: <CAJumaK8e4V9=j9qERSNpMUBvN6F0qOfyLbqWFicZwq+PYTE3eQ@mail.gmail.com>

Ryan: I'm proposing not moving Data.Functor.Constant at all and leaving
that module alone, unmoved.

I'm proposing rather adding Data.Functor.Const and having
Control.Applicative re-export Const from it rather than supply its own.

This allows us to follow the general pattern of having all the data types
available on display in the Data.Functor.* hierarchy, while still allowing
for the fact that Const won the convenience war a long time ago.

This avoids breaking any of the handful of users of the current Constant
data type, which could then be gracefully deprecated -- or not as Ross sees
fit, within his purview as the maintainer of the transformers package.

-Edward

On Thu, Jul 23, 2015 at 11:13 PM, Ryan Scott <ryan.gl.scott at gmail.com>
wrote:

> I really like this proposal, especially since having convenient Eq1,
> Ord1, Read1, Show1, etc. instances is something I've wanted for a
> while.
>
> I have some questions about some specifics:
>
> 1. Just to verify, you're proposing a breaking change in which
> Data.Functor.Constant no longer exports Constant, but rather Const?
> 2. You mentioned that the additions to base could use
> DefaultSignatures. Could you give an example of how this would work?
> _______________________________________________
> 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/20150724/9a8a6dd2/attachment.html>

From adam at bergmark.nl  Fri Jul 24 13:22:13 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Fri, 24 Jul 2015 15:22:13 +0200
Subject: Intention to takeover glpk-hs
In-Reply-To: <CAAB3OF=B1eDNSQS5HBMf6b-=H0X2-qFLpwudQikMFEsppG727g@mail.gmail.com>
References: <CAAB3OF=B1eDNSQS5HBMf6b-=H0X2-qFLpwudQikMFEsppG727g@mail.gmail.com>
Message-ID: <CACnqJZZ6qPjka67iq6hRN3uuKKhbaiG9eVR-fJGTMOLfskBKSg@mail.gmail.com>

Louis did show up briefly to give shared maintenance of pqueue shortly
before your e-mail. I've opened up an issue for this here:
https://github.com/haskell-infra/hackage-trustees/issues/44

- Adam


On Fri, Jul 24, 2015 at 1:44 PM, Jean-Philippe Bernardy <
bernardy at chalmers.se> wrote:

> Hi,
>
> I intend to take over the glpk-hs package from Louis, who did not
> respond to my direct request, made June 22nd.
>
> The last update to the package was made in 2012 and it does not
> compile with ghc 7.10.
>
> Cheers,
> JP.
> _______________________________________________
> 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/20150724/6e309be1/attachment.html>

From apfelmus at quantentunnel.de  Fri Jul 24 18:16:50 2015
From: apfelmus at quantentunnel.de (Heinrich Apfelmus)
Date: Fri, 24 Jul 2015 20:16:50 +0200
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <CAKA2JgJ_dJM17skitwCQk649F5dnLzdfFFESnzXWQ=bQ5CzfEQ@mail.gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <moq7q7$t5d$1@ger.gmane.org>
 <CAKA2JgJ_dJM17skitwCQk649F5dnLzdfFFESnzXWQ=bQ5CzfEQ@mail.gmail.com>
Message-ID: <motvd2$3ot$1@ger.gmane.org>

Michael Snoyman wrote:
> 
>> Hopefully, they come with suitable documentation. For instance, one
>> thing I don't understand about  stack  yet is in which location it
>> "magically" installs GHC and packages, and how I can invoke `ghci` from
>> these locations. Somehow, I was unable to understand this from the FAQ.
>>
>>
> I think this FAQ entry should help[1] on the first question:
>
> [1]: https://github.com/commercialhaskell/stack/wiki/FAQ [..]
> 
>> Note that stack setup installs GHC into
> ~/.stack/programs/$platform/ghc-$version/ and not a global location.

Ah, ok. Can I assume that the non-sandboxed packages are also installed
in the ~/.stack directory? That's the other part I didn't understand.

> For the second question: either `stack ghci` or `stack exec ghci` should
> achieve what you're looking for. The former is a bit more experimental, and
> does more intelligent stuff at the project level as far as loading up your
> code. The latter simply runs the ghci command with appropriate PATH and
> GHC_PACKAGE_PATH environment variables set.

`stack ghci` sounds good to me, then. I really like the short startup
times of ghci and never use `cabal exec ghci` for that reason.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com



From michael at snoyman.com  Fri Jul 24 18:27:00 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Fri, 24 Jul 2015 18:27:00 +0000
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <motvd2$3ot$1@ger.gmane.org>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <moq7q7$t5d$1@ger.gmane.org>
 <CAKA2JgJ_dJM17skitwCQk649F5dnLzdfFFESnzXWQ=bQ5CzfEQ@mail.gmail.com>
 <motvd2$3ot$1@ger.gmane.org>
Message-ID: <CAKA2JgK_aRpieGVUkf0LG0kGCXVOU9XQ0fARRpeZNbaZiho+pg@mail.gmail.com>

On Fri, Jul 24, 2015 at 11:16 AM Heinrich Apfelmus <
apfelmus at quantentunnel.de> wrote:

> Michael Snoyman wrote:
> >
> >> Hopefully, they come with suitable documentation. For instance, one
> >> thing I don't understand about  stack  yet is in which location it
> >> "magically" installs GHC and packages, and how I can invoke `ghci` from
> >> these locations. Somehow, I was unable to understand this from the FAQ.
> >>
> >>
> > I think this FAQ entry should help[1] on the first question:
> >
> > [1]: https://github.com/commercialhaskell/stack/wiki/FAQ [..]
> >
> >> Note that stack setup installs GHC into
> > ~/.stack/programs/$platform/ghc-$version/ and not a global location.
>
> Ah, ok. Can I assume that the non-sandboxed packages are also installed
> in the ~/.stack directory? That's the other part I didn't understand.
>
>
I'm not sure what "non-sandboxed packages" means. Do you mean
snapshot-level packages? If so, yes. If you mean project-specific packages:
they're all stored in the .stack-work directory of the project itself.

My recommendation overall is: build a project with `stack`, and run `stack
path` to get information on all of the different paths it's using for
various things.


> > For the second question: either `stack ghci` or `stack exec ghci` should
> > achieve what you're looking for. The former is a bit more experimental,
> and
> > does more intelligent stuff at the project level as far as loading up
> your
> > code. The latter simply runs the ghci command with appropriate PATH and
> > GHC_PACKAGE_PATH environment variables set.
>
> `stack ghci` sounds good to me, then. I really like the short startup
> times of ghci and never use `cabal exec ghci` for that reason.
>
>
I think `stack exec ghci` is what you mean, correct?

>
> Best regards,
> Heinrich Apfelmus
>
> --
> http://apfelmus.nfshost.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/20150724/9cd08ea4/attachment.html>

From lemming at henning-thielemann.de  Fri Jul 24 21:52:35 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 24 Jul 2015 23:52:35 +0200 (CEST)
Subject: non-ASCII filepaths in a C function
Message-ID: <alpine.DEB.2.02.1507242344260.7190@sputnik>


In my 'soxlib' package I have written a binding to

sox_format_t * sox_open_read(
     char               const * path,
     sox_signalinfo_t   const * signal,
     sox_encodinginfo_t const * encoding,
     char               const * filetype);


I construct the C filepath "path" from a Haskell FilePath using 
Foreign.C.String.withCString. This works for ASCII and non-ASCII 
characters in Linux. However, non-ASCII characters let sox_open_read fail 
on Windows. What is the correct way to convert FilePath to "char *"?

From blamario at ciktel.net  Sat Jul 25 02:33:49 2015
From: blamario at ciktel.net (=?UTF-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=)
Date: Fri, 24 Jul 2015 22:33:49 -0400
Subject: Proposal: Migrate Data.Functor.{Sum, Product,
 Compose} from transformers to base.
In-Reply-To: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
References: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
Message-ID: <55B2F58D.9080508@ciktel.net>

On 07/23/2015 07:18 PM, Edward Kmett wrote:
> ...
> So, as a concrete proposal I propose that we:
>
> 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose 
> and Data.Functor.Classes into base.
>
> 2.) Move Control.Applicative's Const into Data.Functor.Const, but 
> continue to re-export it from Control.Applicative.
>
> 3.) Add whatever missing, sensible, instances make sense after the 
> transition that were ruled out by these modules' previous placement. 
> /e.g./ Data, Generic, Generic1.

+1 to all three parts


From alpmestan at gmail.com  Sat Jul 25 07:14:04 2015
From: alpmestan at gmail.com (Alp Mestanogullari)
Date: Sat, 25 Jul 2015 09:14:04 +0200
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
In-Reply-To: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
References: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
Message-ID: <CADZnDvACL2FiqBbPLsVF0XN3eRuk01dRqhYedVdPtYGog6XAVA@mail.gmail.com>

+1 as well.

On Fri, Jul 24, 2015 at 1:18 AM, Edward Kmett <ekmett at gmail.com> wrote:

> As part of GHC 7.10 we moved Data.Functor.Identity from transformers into
> base. (We'd previously had a private, equivalent definition buried in
> Data.Traversable that we didn't export.)
>
> In a similar vein, I hereby propose moving Data.Functor.Sum,
> Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes into
> base as they exist in transformers, without unduly bikeshedding their
> APIs.
>
> This would effectively reduce the role of transformers to simply
> supplying actual transformers and continue the general pattern of universal
> constructions migrating into base. Without bikeshedding their
> implementations this migration becomes a no-op for existing users.
>
> The most awkward of these is the Data.Functor.Classes API, but it affects
> a number of their instances, and without it, those instances would have to
> be orphans, so my gut reaction would be to say yes, we should move that as
> well. There are also some in-flight API changes in the works in the HEAD
> version of transformers for which a base-based version of the API could
> exploit DefaultSignatures to ease migration.
>
> I'm rather deliberately not including Data.Functor.Constant in this
> proposal as when it has been discussed in the past, Const from
> Control.Applicative has effectively grown to subsume that role. That
> said, we if we bring in the rest of this stuff we could migrate it to
> Data.Functor.Const and simply re-export it from Control.Applicative to
> avoid breakage.
>
> So, as a concrete proposal I propose that we:
>
> 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and
> Data.Functor.Classes into base.
>
> 2.) Move Control.Applicative's Const into Data.Functor.Const, but
> continue to re-export it from Control.Applicative.
>
> 3.) Add whatever missing, sensible, instances make sense after the
> transition that were ruled out by these modules' previous placement.
> *e.g.* Data, Generic, Generic1.
>
> Discussion Period: 2 weeks
>
> -Edward Kmett
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>


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

From hvr at gnu.org  Sat Jul 25 07:16:11 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sat, 25 Jul 2015 09:16:11 +0200
Subject: Proposal: Migrate Data.Functor.{Sum, Product,
 Compose} from transformers to base.
In-Reply-To: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
 (Edward Kmett's message of "Thu, 23 Jul 2015 19:18:15 -0400")
References: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
Message-ID: <87si8ck8qs.fsf@gnu.org>

On 2015-07-24 at 01:18:15 +0200, Edward Kmett wrote:

[...]

> So, as a concrete proposal I propose that we:
>
> 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and
> Data.Functor.Classes into base.
>
> 2.) Move Control.Applicative's Const into Data.Functor.Const, but continue
> to re-export it from Control.Applicative.
>
> 3.) Add whatever missing, sensible, instances make sense after the
> transition that were ruled out by these modules' previous placement. *e.g.*
> Data, Generic, Generic1.
>
> Discussion Period: 2 weeks

+1

From malcolm.wallace at me.com  Sat Jul 25 07:40:59 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Sat, 25 Jul 2015 08:40:59 +0100
Subject: non-ASCII filepaths in a C function
In-Reply-To: <alpine.DEB.2.02.1507242344260.7190@sputnik>
References: <alpine.DEB.2.02.1507242344260.7190@sputnik>
Message-ID: <F98CB23A-941B-419C-A8AC-10D643C1C33F@me.com>

I believe the native representation for FilePaths on Windows should be UTF16 strings.

Regards,
    Malcolm

> On 24 Jul 2015, at 22:52, Henning Thielemann <lemming at henning-thielemann.de> wrote:
> 
> 
> In my 'soxlib' package I have written a binding to
> 
> sox_format_t * sox_open_read(
>    char               const * path,
>    sox_signalinfo_t   const * signal,
>    sox_encodinginfo_t const * encoding,
>    char               const * filetype);
> 
> 
> I construct the C filepath "path" from a Haskell FilePath using Foreign.C.String.withCString. This works for ASCII and non-ASCII characters in Linux. However, non-ASCII characters let sox_open_read fail on Windows. What is the correct way to convert FilePath to "char *"?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From lemming at henning-thielemann.de  Sat Jul 25 08:03:39 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 25 Jul 2015 10:03:39 +0200 (CEST)
Subject: non-ASCII filepaths in a C function
In-Reply-To: <F98CB23A-941B-419C-A8AC-10D643C1C33F@me.com>
References: <alpine.DEB.2.02.1507242344260.7190@sputnik>
 <F98CB23A-941B-419C-A8AC-10D643C1C33F@me.com>
Message-ID: <alpine.DEB.2.02.1507251002460.7220@sputnik>


On Sat, 25 Jul 2015, Malcolm Wallace wrote:

> I believe the native representation for FilePaths on Windows should be UTF16 strings.

Is there a replacement for withCString that works everywhere?

From lemming at henning-thielemann.de  Sat Jul 25 08:05:35 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 25 Jul 2015 10:05:35 +0200 (CEST)
Subject: non-ASCII filepaths in a C function
In-Reply-To: <F98CB23A-941B-419C-A8AC-10D643C1C33F@me.com>
References: <alpine.DEB.2.02.1507242344260.7190@sputnik>
 <F98CB23A-941B-419C-A8AC-10D643C1C33F@me.com>
Message-ID: <alpine.DEB.2.02.1507251004220.7220@sputnik>


On Sat, 25 Jul 2015, Malcolm Wallace wrote:

> I believe the native representation for FilePaths on Windows should be UTF16 strings.

Btw. I don't think that soxlib expects UTF16 filepath strings on Windows 
because it works for purely ASCII filepaths.

From dominic at steinitz.org  Sat Jul 25 08:45:57 2015
From: dominic at steinitz.org (Dominic Steinitz)
Date: Sat, 25 Jul 2015 08:45:57 +0000 (UTC)
Subject: Intention to takeover glpk-hs
References: <CAAB3OF=B1eDNSQS5HBMf6b-=H0X2-qFLpwudQikMFEsppG727g@mail.gmail.com>
 <CACnqJZZ6qPjka67iq6hRN3uuKKhbaiG9eVR-fJGTMOLfskBKSg@mail.gmail.com>
Message-ID: <loom.20150725T103835-900@post.gmane.org>

> Louis did show up briefly to give shared maintenance of pqueue
> shortly before your e-mail.  I've opened up an issue for this
> here:?https://github.com/haskell-infra/hackage- trustees/issues/44 -
> Adam

> On Fri, Jul 24, 2015 at 1:44 PM, Jean-Philippe Bernardy <bernardy
> <at> chalmers.se> wrote:Hi, I intend to take over the glpk-hs
> package from Louis, who did not respond to my direct request, made
> June 22nd.  The last update to the package was made in 2012 and it
> does not compile with ghc 7.10.  Cheers, JP.

I am really pleased this is happening. I don't think Louis is very
active in maintaining this. I opened up a PR about 2 years ago which
is still sitting there: https://github.com/lowasser/glpk- hs/pulls.

Dominic.

From spam at scientician.net  Sat Jul 25 09:52:41 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sat, 25 Jul 2015 11:52:41 +0200
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
In-Reply-To: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
References: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
Message-ID: <movm99$r7l$1@ger.gmane.org>

On 07/24/2015 01:18 AM, Edward Kmett wrote:
> 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and
> Data.Functor.Classes into base.
> 
> 2.) Move Control.Applicative's Const into Data.Functor.Const, but continue
> to re-export it from Control.Applicative.
> 
> 3.) Add whatever missing, sensible, instances make sense after the
> transition that were ruled out by these modules' previous placement. *e.g.*
> Data, Generic, Generic1.
> 

+1

Regards,


From strake888 at gmail.com  Sat Jul 25 17:30:06 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Sat, 25 Jul 2015 09:30:06 -0800
Subject: Proposal: Migrate Data.Functor.{Sum, Product, Compose} from
 transformers to base.
In-Reply-To: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
References: <CAJumaK-P1ZbgbW1TDh1Oz3W2KQOcbF1nfOfLBG_50q4gjQKYLQ@mail.gmail.com>
Message-ID: <CAL3m8eDA_AGJA32B=H8JbP1rJjjSb=pv5BchmMqW9Hsf9jMCtA@mail.gmail.com>

On 23/07/2015, Edward Kmett <ekmett at gmail.com> wrote:
> So, as a concrete proposal I propose that we:
>
> 1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and
> Data.Functor.Classes into base.
>
> 2.) Move Control.Applicative's Const into Data.Functor.Const, but continue
> to re-export it from Control.Applicative.
>
> 3.) Add whatever missing, sensible, instances make sense after the
> transition that were ruled out by these modules' previous placement. *e.g.*
> Data, Generic, Generic1.

+1 all

From cma at bitemyapp.com  Sat Jul 25 20:50:40 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Sat, 25 Jul 2015 15:50:40 -0500
Subject: Proposal: Add missing Monoid for ZipList
Message-ID: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>

http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList

There's a Monoid that matches what the Applicative for ZipList does that
seems to be missing.

instance Monoid a => Monoid (ZipList a) where
  mempty  = pure mempty
  mappend = liftA2 mappend

It's been brought up before:

https://mail.haskell.org/pipermail/haskell-cafe/2009-October/067861.html

Not only is it useful when it's the Monoid you want, but it serves an
educational purpose for highlighting the relationship between Monoid and
Applicative as well.

Are there any good reasons not to have it?

I'd like to limit discussion to two weeks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150725/a26e312e/attachment.html>

From david.feuer at gmail.com  Sat Jul 25 20:57:39 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 25 Jul 2015 16:57:39 -0400
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
Message-ID: <CAMgWh9scQNCKheGhqFV_-yh9KRq_O9ODOYC2v9sO+wB6uiQf3w@mail.gmail.com>

-1. This breaks the rule that "ZipList is [] with a different Applicative
instance". The monoid instance for lists would work just fine for these.
On Jul 25, 2015 4:50 PM, "Christopher Allen" <cma at bitemyapp.com> wrote:

>
> http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList
>
> There's a Monoid that matches what the Applicative for ZipList does that
> seems to be missing.
>
> instance Monoid a => Monoid (ZipList a) where
>   mempty  = pure mempty
>   mappend = liftA2 mappend
>
> It's been brought up before:
>
> https://mail.haskell.org/pipermail/haskell-cafe/2009-October/067861.html
>
> Not only is it useful when it's the Monoid you want, but it serves an
> educational purpose for highlighting the relationship between Monoid and
> Applicative as well.
>
> Are there any good reasons not to have it?
>
> I'd like to limit discussion to two weeks.
>
>
> _______________________________________________
> 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/20150725/971274f3/attachment.html>

From lemming at henning-thielemann.de  Sat Jul 25 20:57:46 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 25 Jul 2015 22:57:46 +0200 (CEST)
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1507252253510.7220@sputnik>



On Sat, 25 Jul 2015, Christopher Allen wrote:

> http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList
> 
> There's a Monoid that matches what the Applicative for ZipList does that seems to be missing.
> 
> instance Monoid a => Monoid (ZipList a) where
> ? mempty ?= pure mempty
> ? mappend = liftA2 mappend
> 
> It's been brought up before:
> 
> https://mail.haskell.org/pipermail/haskell-cafe/2009-October/067861.html
> 
> Not only is it useful when it's the Monoid you want, but it serves an 
> educational purpose for highlighting the relationship between Monoid and 
> Applicative as well.
> 
> Are there any good reasons not to have it?

The Monoid instance for lists is not related to Applicative list instance 
- so why should the instances for ZipList? We could as well use the Monoid 
list implementation for ZipLists. If there is no actual application for 
the instance I would leave it unimplemented.

From dct25-561bs at mythic-beasts.com  Sat Jul 25 21:04:54 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Sat, 25 Jul 2015 22:04:54 +0100
Subject: non-ASCII filepaths in a C function
In-Reply-To: <F98CB23A-941B-419C-A8AC-10D643C1C33F@me.com>
References: <alpine.DEB.2.02.1507242344260.7190@sputnik>
 <F98CB23A-941B-419C-A8AC-10D643C1C33F@me.com>
Message-ID: <CAErCyQ-ggad7UY2yXsZ5yj-GR1oxjYfF7P6a-hMLrd9s7r7xjw@mail.gmail.com>

Hi,

The native representation for filepaths on Linux is char[] (i.e. raw
bytes). withCString converts from String to char[] using the current
locale, which doesn't always work (at least, it doesn't always do what you
want). As long as everything is in the same locale, ideally UTF-8, then
you'll be fine, but it's legitimate to have a file whose name is not legal
UTF-8 even in a UTF-8 locale, and these will cause you problems.

(Minor, nitpicky bugbear: the native representation for filepaths on
Windows is wchar_t[] which is interpreted as UTF-16 *where possible*, but
there are also some legal filenames (e.g. "C:\\Temp\\\xd800") which are
invalid as UTF-16)

I'm not familiar with soxlib specifically, but for opening a file on
Windows named as a char[] I'm going to guess that the library ultimately
ends up calling a so-called ANSI version of a function like CreateFileA,
which accepts a char[] and converts it to wchar_t[] within the OS according
to the current code page. withCString seems to look at the current code
page when converting a String to a char[] too, but clearly something's not
matching for you.

So a few things to check:

- does soxlib use the ANSI version, CreateFileA or similar?
- what code page does it think it's in?
- can you convert the troublesome filename to bytes in this code page by
hand, and compare with what withCString is doing?
- can you convert these bytes to wchar_t[] using MultiByteToWideChar in the
current code page? Does this look like what you expect?

Unfortunately there's no complete general solution to this problem that
fits through an API that only uses char[] for filenames - the mapping from
filenames written as char[] to Windows filenames is never surjective. The
best solution would be for soxlib to offer an API that accepted wchar_t[]
filenames on Windows, although I appreciate this might not be reasonable!

Hopefully this helps a bit.

On 25 July 2015 at 08:40, Malcolm Wallace <malcolm.wallace at me.com> wrote:

> I believe the native representation for FilePaths on Windows should be
> UTF16 strings.
>
> Regards,
>     Malcolm
>
> > On 24 Jul 2015, at 22:52, Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
> >
> >
> > In my 'soxlib' package I have written a binding to
> >
> > sox_format_t * sox_open_read(
> >    char               const * path,
> >    sox_signalinfo_t   const * signal,
> >    sox_encodinginfo_t const * encoding,
> >    char               const * filetype);
> >
> >
> > I construct the C filepath "path" from a Haskell FilePath using
> Foreign.C.String.withCString. This works for ASCII and non-ASCII characters
> in Linux. However, non-ASCII characters let sox_open_read fail on Windows.
> What is the correct way to convert FilePath to "char *"?
> > _______________________________________________
> > 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/20150725/152c9354/attachment.html>

From david.feuer at gmail.com  Sat Jul 25 21:13:05 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 25 Jul 2015 17:13:05 -0400
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
Message-ID: <CAMgWh9scOKmXKO0a2wy5GOSL+V8Nhjsgvbj_C+Z3vE16d922dQ@mail.gmail.com>

We could add a newtype for this in Data.Monoid.

newtype Appl f a = Appl (f a)
instance (Applicative f, Monoid a) => Monoid (Appl f a) where
  mempty = Appl $ pure mempty
  mplus (Appl x) (Appl y) = Appl $ liftA2 mplus x y
On Jul 25, 2015 4:50 PM, "Christopher Allen" <cma at bitemyapp.com> wrote:

>
> http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList
>
> There's a Monoid that matches what the Applicative for ZipList does that
> seems to be missing.
>
> instance Monoid a => Monoid (ZipList a) where
>   mempty  = pure mempty
>   mappend = liftA2 mappend
>
> It's been brought up before:
>
> https://mail.haskell.org/pipermail/haskell-cafe/2009-October/067861.html
>
> Not only is it useful when it's the Monoid you want, but it serves an
> educational purpose for highlighting the relationship between Monoid and
> Applicative as well.
>
> Are there any good reasons not to have it?
>
> I'd like to limit discussion to two weeks.
>
>
> _______________________________________________
> 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/20150725/8c64e372/attachment-0001.html>

From roma at ro-che.info  Sat Jul 25 21:45:09 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sun, 26 Jul 2015 00:45:09 +0300
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
Message-ID: <55B40365.1000503@ro-che.info>

This is a neat idea, and potentially useful. +1.

If this gets through, the instance should include documentation
describing how it works (probably mentioning zipWith) and contrasting it
with the Monoid [a] instance.

On 25/07/15 23:50, Christopher Allen wrote:
> http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList
> 
> There's a Monoid that matches what the Applicative for ZipList does that
> seems to be missing.
> 
> instance Monoid a => Monoid (ZipList a) where
>   mempty  = pure mempty
>   mappend = liftA2 mappend
> 
> It's been brought up before:
> 
> https://mail.haskell.org/pipermail/haskell-cafe/2009-October/067861.html
> 
> Not only is it useful when it's the Monoid you want, but it serves an
> educational purpose for highlighting the relationship between Monoid and
> Applicative as well.
> 
> Are there any good reasons not to have it?
> 
> I'd like to limit discussion to two weeks.




-------------- 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/20150726/3ce8d475/attachment.sig>

From apfelmus at quantentunnel.de  Sat Jul 25 21:52:17 2015
From: apfelmus at quantentunnel.de (Heinrich Apfelmus)
Date: Sat, 25 Jul 2015 23:52:17 +0200
Subject: Improving the "Get Haskell Experience"
In-Reply-To: <CAKA2JgK_aRpieGVUkf0LG0kGCXVOU9XQ0fARRpeZNbaZiho+pg@mail.gmail.com>
References: <CAAOoiFa6mrW_HxE1i1ZrGJgEJoed_J9X9Y10avaLjrywKYt1Zg@mail.gmail.com>
 <moq7q7$t5d$1@ger.gmane.org>
 <CAKA2JgJ_dJM17skitwCQk649F5dnLzdfFFESnzXWQ=bQ5CzfEQ@mail.gmail.com>
 <motvd2$3ot$1@ger.gmane.org>
 <CAKA2JgK_aRpieGVUkf0LG0kGCXVOU9XQ0fARRpeZNbaZiho+pg@mail.gmail.com>
Message-ID: <mp10cv$vuv$1@ger.gmane.org>

Michael Snoyman wrote:
>>>
>>>> Note that stack setup installs GHC into
>>> ~/.stack/programs/$platform/ghc-$version/ and not a global location.
>>
>> Ah, ok. Can I assume that the non-sandboxed packages are also installed
>> in the ~/.stack directory? That's the other part I didn't understand.
>>
>>
> I'm not sure what "non-sandboxed packages" means. Do you mean
> snapshot-level packages? If so, yes. If you mean project-specific packages:
> they're all stored in the .stack-work directory of the project itself.
> 
> My recommendation overall is: build a project with `stack`, and run `stack
> path` to get information on all of the different paths it's using for
> various things.

Sounds good to me. I didn't know about the `stack path` command. 
Hopfully, that could be added to the documentation.


>>> For the second question: either `stack ghci` or `stack exec ghci` should
>>> achieve what you're looking for. The former is a bit more experimental,
>>> and does more intelligent stuff at the project level as far as loading up
>>< your code. The latter simply runs the ghci command with appropriate PATH and
>>> GHC_PACKAGE_PATH environment variables set.
>>
>> `stack ghci` sounds good to me, then. I really like the short startup
>> times of ghci and never use `cabal exec ghci` for that reason.
>>
> I think `stack exec ghci` is what you mean, correct?

Err, yes, thanks.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


From cma at bitemyapp.com  Sat Jul 25 22:02:02 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Sat, 25 Jul 2015 17:02:02 -0500
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <alpine.DEB.2.02.1507252253510.7220@sputnik>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
 <alpine.DEB.2.02.1507252253510.7220@sputnik>
Message-ID: <CADnndOotjCs_wTQf4x9wWSWSorJudXXZwFQrv=HQ63E1Ny9XHQ@mail.gmail.com>

>We could as well use the Monoid list implementation for ZipLists.

We could, but that would be redundant and wouldn't fit what ZipList is for
as well.


On Sat, Jul 25, 2015 at 3:57 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
>
> On Sat, 25 Jul 2015, Christopher Allen wrote:
>
>
>> http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList
>>
>> There's a Monoid that matches what the Applicative for ZipList does that
>> seems to be missing.
>>
>> instance Monoid a => Monoid (ZipList a) where
>>   mempty  = pure mempty
>>   mappend = liftA2 mappend
>>
>> It's been brought up before:
>>
>> https://mail.haskell.org/pipermail/haskell-cafe/2009-October/067861.html
>>
>> Not only is it useful when it's the Monoid you want, but it serves an
>> educational purpose for highlighting the relationship between Monoid and
>> Applicative as well.
>>
>> Are there any good reasons not to have it?
>>
>
> The Monoid instance for lists is not related to Applicative list instance
> - so why should the instances for ZipList? We could as well use the Monoid
> list implementation for ZipLists. If there is no actual application for the
> instance I would leave it unimplemented.




-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150725/22bade72/attachment.html>

From strake888 at gmail.com  Sun Jul 26 01:31:00 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Sat, 25 Jul 2015 17:31:00 -0800
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
Message-ID: <55b434ec.c511460a.3550.ffff9e9d@mx.google.com>

On 25/07/2015 at 15:50:40 -0500, Christopher Allen wrote:
> instance Monoid a => Monoid (ZipList a) where
>   mempty  = pure mempty
>   mappend = liftA2 mappend

+1

It's appropriately zippy.

From fumiexcel at gmail.com  Sun Jul 26 03:23:13 2015
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Sun, 26 Jul 2015 12:23:13 +0900
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
Message-ID: <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>

There is another possible instance:

instance Semigroup a => Monoid (ZipList a) where
  mempty = ZipList []
  mappend (ZipList xs0) (ZipList ys0) = ZipList (mappend xs0 ys0) where
    go (x:xs) (y:ys) = x <> y : go xs ys
    go xs [] = xs
    go [] ys = ys

But +1 to the original one.

2015-07-26 5:50 GMT+09:00 Christopher Allen <cma at bitemyapp.com>:

>
> http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList
>
> There's a Monoid that matches what the Applicative for ZipList does that
> seems to be missing.
>
> instance Monoid a => Monoid (ZipList a) where
>   mempty  = pure mempty
>   mappend = liftA2 mappend
>
> It's been brought up before:
>
> https://mail.haskell.org/pipermail/haskell-cafe/2009-October/067861.html
>
> Not only is it useful when it's the Monoid you want, but it serves an
> educational purpose for highlighting the relationship between Monoid and
> Applicative as well.
>
> Are there any good reasons not to have it?
>
> I'd like to limit discussion to two weeks.
>
>
> _______________________________________________
> 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/20150726/8dac4739/attachment.html>

From fumiexcel at gmail.com  Sun Jul 26 03:24:27 2015
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Sun, 26 Jul 2015 12:24:27 +0900
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
 <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
Message-ID: <CAATCwU=2dWvzFp0KC5R-nwzzG1Nb4gQDaneiMg_Xt-qY+w+KxQ@mail.gmail.com>

Sorry, it should be `mappend (ZipList xs0) (ZipList ys0) = ZipList (go xs0
ys0) where`

2015-07-26 12:23 GMT+09:00 Fumiaki Kinoshita <fumiexcel at gmail.com>:

> There is another possible instance:
>
> instance Semigroup a => Monoid (ZipList a) where
>   mempty = ZipList []
>   mappend (ZipList xs0) (ZipList ys0) = ZipList (mappend xs0 ys0) where
>     go (x:xs) (y:ys) = x <> y : go xs ys
>     go xs [] = xs
>     go [] ys = ys
>
> But +1 to the original one.
>
> 2015-07-26 5:50 GMT+09:00 Christopher Allen <cma at bitemyapp.com>:
>
>>
>> http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList
>>
>> There's a Monoid that matches what the Applicative for ZipList does that
>> seems to be missing.
>>
>> instance Monoid a => Monoid (ZipList a) where
>>   mempty  = pure mempty
>>   mappend = liftA2 mappend
>>
>> It's been brought up before:
>>
>> https://mail.haskell.org/pipermail/haskell-cafe/2009-October/067861.html
>>
>> Not only is it useful when it's the Monoid you want, but it serves an
>> educational purpose for highlighting the relationship between Monoid and
>> Applicative as well.
>>
>> Are there any good reasons not to have it?
>>
>> I'd like to limit discussion to two weeks.
>>
>>
>> _______________________________________________
>> 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/20150726/21e7575a/attachment-0001.html>

From david.feuer at gmail.com  Sun Jul 26 03:27:25 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 25 Jul 2015 23:27:25 -0400
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
 <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
Message-ID: <CAMgWh9uJsqfwoMvjErfSpNSf2OeKqAysBEVicBYtB+iRjFs+rQ@mail.gmail.com>

Can someone please explain *why* they want this instance?
On Jul 25, 2015 11:23 PM, "Fumiaki Kinoshita" <fumiexcel at gmail.com> wrote:

> There is another possible instance:
>
> instance Semigroup a => Monoid (ZipList a) where
>   mempty = ZipList []
>   mappend (ZipList xs0) (ZipList ys0) = ZipList (mappend xs0 ys0) where
>     go (x:xs) (y:ys) = x <> y : go xs ys
>     go xs [] = xs
>     go [] ys = ys
>
> But +1 to the original one.
>
> 2015-07-26 5:50 GMT+09:00 Christopher Allen <cma at bitemyapp.com>:
>
>>
>> http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList
>>
>> There's a Monoid that matches what the Applicative for ZipList does that
>> seems to be missing.
>>
>> instance Monoid a => Monoid (ZipList a) where
>>   mempty  = pure mempty
>>   mappend = liftA2 mappend
>>
>> It's been brought up before:
>>
>> https://mail.haskell.org/pipermail/haskell-cafe/2009-October/067861.html
>>
>> Not only is it useful when it's the Monoid you want, but it serves an
>> educational purpose for highlighting the relationship between Monoid and
>> Applicative as well.
>>
>> Are there any good reasons not to have it?
>>
>> I'd like to limit discussion to two weeks.
>>
>>
>> _______________________________________________
>> 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/20150725/1a1837c3/attachment.html>

From strake888 at gmail.com  Sun Jul 26 03:43:41 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Sat, 25 Jul 2015 19:43:41 -0800
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
 <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
Message-ID: <55b45405.edb8420a.7c661.ffffb177@mx.google.com>

On 26/07/2015 at 12:23:13 +0900, Fumiaki Kinoshita wrote:
> There is another possible instance:
> 
> instance Semigroup a => Monoid (ZipList a) where
>   mempty = ZipList []
>   mappend (ZipList xs0) (ZipList ys0) = ZipList (mappend xs0 ys0) where
>     go (x:xs) (y:ys) = x <> y : go xs ys
>     go xs [] = xs
>     go [] ys = ys

This breaks the identity law.

From oleg.grenrus at iki.fi  Sun Jul 26 06:20:53 2015
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Sun, 26 Jul 2015 09:20:53 +0300
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <55b45405.edb8420a.7c661.ffffb177@mx.google.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
 <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
 <55b45405.edb8420a.7c661.ffffb177@mx.google.com>
Message-ID: <ECADA438-8BC5-4962-B4EB-095482388254@iki.fi>


> On 26 Jul 2015, at 06:43, M Farkas-Dyck <strake888 at gmail.com> wrote:
> 
> On 26/07/2015 at 12:23:13 +0900, Fumiaki Kinoshita wrote:
>> There is another possible instance:
>> 
>> instance Semigroup a => Monoid (ZipList a) where
>>  mempty = ZipList []
>>  mappend (ZipList xs0) (ZipList ys0) = ZipList (mappend xs0 ys0) where
>>    go (x:xs) (y:ys) = x <> y : go xs ys
>>    go xs [] = xs
>>    go [] ys = ys
> 
> This breaks the identity law.

    instance Monoid a a => Monoid (ZipList a) where
      mempty = ZipList (repeat mempty)
      mappend (ZipList xs) (ZipList ys) = ZipList (zipWith (<>) xs ys)

No preference on actual proposal or the instance. I have no strong opinion whether Alternative and Monoid1 should be the same.

Cheers,
Oleg Grenrus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150726/c7e37a6a/attachment.sig>

From lemming at henning-thielemann.de  Sun Jul 26 06:30:33 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 26 Jul 2015 08:30:33 +0200 (CEST)
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <ECADA438-8BC5-4962-B4EB-095482388254@iki.fi>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
 <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
 <55b45405.edb8420a.7c661.ffffb177@mx.google.com>
 <ECADA438-8BC5-4962-B4EB-095482388254@iki.fi>
Message-ID: <alpine.DEB.2.02.1507260826490.7220@sputnik>


On Sun, 26 Jul 2015, Oleg Grenrus wrote:

>> On 26 Jul 2015, at 06:43, M Farkas-Dyck <strake888 at gmail.com> wrote:
>>
>> On 26/07/2015 at 12:23:13 +0900, Fumiaki Kinoshita wrote:
>>> There is another possible instance:
>>>
>>> instance Semigroup a => Monoid (ZipList a) where
>>>  mempty = ZipList []
>>>  mappend (ZipList xs0) (ZipList ys0) = ZipList (mappend xs0 ys0) where
>>>    go (x:xs) (y:ys) = x <> y : go xs ys
>>>    go xs [] = xs
>>>    go [] ys = ys
>>
>> This breaks the identity law.

I don't see, how it breaks the identity law. :-(


>    instance Monoid a a => Monoid (ZipList a) where
>      mempty = ZipList (repeat mempty)
>      mappend (ZipList xs) (ZipList ys) = ZipList (zipWith (<>) xs ys)

This was the original proposal, isn't it?


Since there does not seem to be a real application for the instance there 
is no way to choose a particular one. But then it is better to omit the 
instance, at all. Not having an instance can be a good thing in terms of 
(type) safety.

From oleg.grenrus at iki.fi  Sun Jul 26 06:30:37 2015
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Sun, 26 Jul 2015 09:30:37 +0300
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <ECADA438-8BC5-4962-B4EB-095482388254@iki.fi>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
 <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
 <55b45405.edb8420a.7c661.ffffb177@mx.google.com>
 <ECADA438-8BC5-4962-B4EB-095482388254@iki.fi>
Message-ID: <7E7F4B16-CBF1-4734-BC77-2B6476864967@iki.fi>

Sorry, that seems to be exactly the instances which is originally proposed.

> On 26 Jul 2015, at 09:20, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
> 
> 
>> On 26 Jul 2015, at 06:43, M Farkas-Dyck <strake888 at gmail.com> wrote:
>> 
>> On 26/07/2015 at 12:23:13 +0900, Fumiaki Kinoshita wrote:
>>> There is another possible instance:
>>> 
>>> instance Semigroup a => Monoid (ZipList a) where
>>> mempty = ZipList []
>>> mappend (ZipList xs0) (ZipList ys0) = ZipList (mappend xs0 ys0) where
>>>   go (x:xs) (y:ys) = x <> y : go xs ys
>>>   go xs [] = xs
>>>   go [] ys = ys
>> 
>> This breaks the identity law.
> 
>    instance Monoid a a => Monoid (ZipList a) where
>      mempty = ZipList (repeat mempty)
>      mappend (ZipList xs) (ZipList ys) = ZipList (zipWith (<>) xs ys)
> 
> No preference on actual proposal or the instance. I have no strong opinion whether Alternative and Monoid1 should be the same.
> 
> Cheers,
> Oleg Grenrus
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From strake888 at gmail.com  Sun Jul 26 06:51:48 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Sat, 25 Jul 2015 22:51:48 -0800
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <alpine.DEB.2.02.1507260826490.7220@sputnik>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
 <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
 <55b45405.edb8420a.7c661.ffffb177@mx.google.com>
 <ECADA438-8BC5-4962-B4EB-095482388254@iki.fi>
 <alpine.DEB.2.02.1507260826490.7220@sputnik>
Message-ID: <55b4801c.8758460a.137dc.ffffd5c4@mx.google.com>

On 26/07/2015 at 08:30:33 +0200, Henning Thielemann wrote:
> 
> On Sun, 26 Jul 2015, Oleg Grenrus wrote:
> 
> >>On 26 Jul 2015, at 06:43, M Farkas-Dyck <strake888 at gmail.com> wrote:
> >>
> >>On 26/07/2015 at 12:23:13 +0900, Fumiaki Kinoshita wrote:
> >>>There is another possible instance:
> >>>
> >>>instance Semigroup a => Monoid (ZipList a) where
> >>> mempty = ZipList []
> >>> mappend (ZipList xs0) (ZipList ys0) = ZipList (mappend xs0 ys0) where
> >>>   go (x:xs) (y:ys) = x <> y : go xs ys
> >>>   go xs [] = xs
> >>>   go [] ys = ys
> >>
> >>This breaks the identity law.
> 
> I don't see, how it breaks the identity law. :-(

Derp. I misread the code, sorry.

From blamario at ciktel.net  Sun Jul 26 13:18:46 2015
From: blamario at ciktel.net (=?UTF-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=)
Date: Sun, 26 Jul 2015 09:18:46 -0400
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <CAMgWh9scOKmXKO0a2wy5GOSL+V8Nhjsgvbj_C+Z3vE16d922dQ@mail.gmail.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
 <CAMgWh9scOKmXKO0a2wy5GOSL+V8Nhjsgvbj_C+Z3vE16d922dQ@mail.gmail.com>
Message-ID: <55B4DE36.9040704@ciktel.net>

On 07/25/2015 05:13 PM, David Feuer wrote:
>
> We could add a newtype for this in Data.Monoid.
>
> newtype Appl f a = Appl (f a)
> instance (Applicative f, Monoid a) => Monoid (Appl f a) where
>   mempty = Appl $ pure mempty
>   mplus (Appl x) (Appl y) = Appl $ liftA2 mplus x y
>

     I like this idea, it would go well with the recently-added Alt 
newtype. You should make it a separate proposal, though. I'm +0 on the 
parent proposal.


From ekmett at gmail.com  Sun Jul 26 15:42:41 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 26 Jul 2015 11:42:41 -0400
Subject: Proposal: Add missing Monoid for ZipList
In-Reply-To: <55b45405.edb8420a.7c661.ffffb177@mx.google.com>
References: <CADnndOrkHQr_bZuFS0k6MKNTNfqsnecZmSUWFu=JLmBAv0dhWg@mail.gmail.com>
 <CAATCwUkUwL67hUGd7DSpbb4zwxju8Z7+Si9cLXe915nAVDTCBw@mail.gmail.com>
 <55b45405.edb8420a.7c661.ffffb177@mx.google.com>
Message-ID: <CAJumaK8Ek+Q2qnQAAVPYk0uwiVP0MEYCm=f3YYEZmO1foCXwyQ@mail.gmail.com>

Fumiaka Kinoshita's instance actually seems both sound and "slightly more
defined".

It even relates more obviously to the proposed Alternative, which can be
seen as exploiting the fact that the First semigroup can be applied on any
data type and then using this instance.

m <|> n = fmap getFirst (fmap First m <> fmap First n)

-Edward


On Sat, Jul 25, 2015 at 11:43 PM, M Farkas-Dyck <strake888 at gmail.com> wrote:

> On 26/07/2015 at 12:23:13 +0900, Fumiaki Kinoshita wrote:
> > There is another possible instance:
> >
> > instance Semigroup a => Monoid (ZipList a) where
> >   mempty = ZipList []
> >   mappend (ZipList xs0) (ZipList ys0) = ZipList (mappend xs0 ys0) where
> >     go (x:xs) (y:ys) = x <> y : go xs ys
> >     go xs [] = xs
> >     go [] ys = ys
>
> This breaks the identity law.
> _______________________________________________
> 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/20150726/26dbdd6c/attachment.html>

From ryan.gl.scott at gmail.com  Sun Jul 26 17:05:16 2015
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Sun, 26 Jul 2015 12:05:16 -0500
Subject: Proposal: genericReplicateM
Message-ID: <CADdQpRDrsz=F=XaVttui=aQSywkp=Fs8rq+nPDv2yrAm_S4szQ@mail.gmail.com>

This sounds like a good idea to me. This might be a good thing to
bundle with a separate proposal [1] to generalize replicateM(_) to use
Applicative instead of Monad.

[1] https://ghc.haskell.org/trac/ghc/ticket/10168

From david.feuer at gmail.com  Mon Jul 27 03:34:42 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 26 Jul 2015 23:34:42 -0400
Subject: Proposal: newtype for applicatives of monoids
In-Reply-To: <CAMgWh9v-ohYu23dUgSf47kGq2o_mYAbWLmw_1+7LDNt=U7wvJQ@mail.gmail.com>
References: <CAMgWh9s+1m7PoNGMnx0NHuXKHatu-G3Db4ROqGD5_TOg5yjyxQ@mail.gmail.com>
 <CAMgWh9v-ohYu23dUgSf47kGq2o_mYAbWLmw_1+7LDNt=U7wvJQ@mail.gmail.com>
Message-ID: <CAMgWh9u58jwfKG75=S8rbE3TOn5iiZC+_Mrt=odPwtdRB07RTw@mail.gmail.com>

Sorry for the terrible title, but I think we should add something like the
following to Data.Monoid (I already mentioned this in the discussion of a
Monoid instance for ZipList).

newtype Appl f m = Appl (f m)

instance (Applicative f, Monoid m) => Monoid (Appl f m) where
  mempty = Appl $ pure mempty
  mplus (Appl x) (Appl y) = Appl $ liftA2 mplus x y

It may be possible to use coercions to improve mplus; I haven't tried it.

This type is the same as WrappedApplicative from semigroupoids, do it might
be best just to give it that name.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150726/7c818808/attachment.html>

From mhoermann at gmail.com  Wed Jul 29 13:30:06 2015
From: mhoermann at gmail.com (=?UTF-8?Q?Matthias_H=C3=B6rmann?=)
Date: Wed, 29 Jul 2015 15:30:06 +0200
Subject: Proposal: instance MonadIO Q
In-Reply-To: <CADdQpRAGzTiwiZQ26Nvse1vpjLvrKo53nZPJGa5JQae_7xLGCw@mail.gmail.com>
References: <CADdQpRAGzTiwiZQ26Nvse1vpjLvrKo53nZPJGa5JQae_7xLGCw@mail.gmail.com>
Message-ID: <CABSPmx2tf=MgbcaC0eLw7+695zMjo2LjOVAUmrGCPNgmbwJk=w@mail.gmail.com>

Is there a particular reason to still push MonadIO even though
MonadBase (from transformers-base) is a cleaner, more
general approach that also fits much more nicely with more powerful
abstractions like MonadBaseControl (from monad-control)?

I know it uses MultiParamTypeClasses but is there another, more
practical reason for not using MonadBase IO instead of MonadIO?

On Thu, Jul 23, 2015 at 11:29 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> It looks like GHC's internal MonadIO was replaced with the one from
> transformers in 2013 [1], so this is already fixed.
>
> Also, +1 on the MonadIO to base suggestion, now that's there's some
> momentum behind that idea.
>
> ----------
> [1] http://git.haskell.org/ghc.git/blobdiff/b13d546f9c454e6d2a15c20a3e10ec47328e33db..71feb1025eed0c3cc849c85e2b00e16bc1a21790:/compiler/utils/MonadUtils.hs
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From ekmett at gmail.com  Wed Jul 29 16:33:25 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 29 Jul 2015 12:33:25 -0400
Subject: Proposal: instance MonadIO Q
In-Reply-To: <CABSPmx2tf=MgbcaC0eLw7+695zMjo2LjOVAUmrGCPNgmbwJk=w@mail.gmail.com>
References: <CADdQpRAGzTiwiZQ26Nvse1vpjLvrKo53nZPJGa5JQae_7xLGCw@mail.gmail.com>
 <CABSPmx2tf=MgbcaC0eLw7+695zMjo2LjOVAUmrGCPNgmbwJk=w@mail.gmail.com>
Message-ID: <CAJumaK-gjM5kJ=a_Bpexcg_eOhna_tLsT3i-Rpkeuy_7cLDk1A@mail.gmail.com>

MonadIO remains Haskell 98. This means that it has a chance of actually
getting into core libraries in a standardizable form and eventually making
it into the report.

The problem is there is no full description of MultiParamTypeClasses +
FunctionalDependencies that is compatible with all the implementations out
there to bless and readily standardize. GHC and Hugs (and older GHCs)
disagree on a number of corner cases of how this works.

Worse, the corner cases where they disagree come up because of how GHC
desugars things into type families, so describing current GHC behavior
really would require dragging into the report pretty much all of
OutsideIn(X), which is an order of magnitude more complicated than the
entire report today.

So, yes, if we ever want to be able to see the bulk of the combinators in
base lifted generalized and have that fact become enshrined in a standard
then there is a very real reason to favor MonadIO.

-Edward

On Wed, Jul 29, 2015 at 9:30 AM, Matthias H?rmann <mhoermann at gmail.com>
wrote:

> Is there a particular reason to still push MonadIO even though
> MonadBase (from transformers-base) is a cleaner, more
> general approach that also fits much more nicely with more powerful
> abstractions like MonadBaseControl (from monad-control)?
>
> I know it uses MultiParamTypeClasses but is there another, more
> practical reason for not using MonadBase IO instead of MonadIO?
>
> On Thu, Jul 23, 2015 at 11:29 PM, Ryan Scott <ryan.gl.scott at gmail.com>
> wrote:
> > It looks like GHC's internal MonadIO was replaced with the one from
> > transformers in 2013 [1], so this is already fixed.
> >
> > Also, +1 on the MonadIO to base suggestion, now that's there's some
> > momentum behind that idea.
> >
> > ----------
> > [1]
> http://git.haskell.org/ghc.git/blobdiff/b13d546f9c454e6d2a15c20a3e10ec47328e33db..71feb1025eed0c3cc849c85e2b00e16bc1a21790:/compiler/utils/MonadUtils.hs
> > _______________________________________________
> > 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/20150729/c82bdb7f/attachment.html>