- Libraries - Haskell.org

Proposal: split Chan and TChan into read and write ends
by Brandon Simmons 05 Nov '12

05 Nov '12

Hi everybody, Just discovered all the great discussion here, and although my google-fu turned up no prior discussions on this subject, I apologize if it has already been discussed. I propose that Chan and TChan should be implemented as a pair of read and write ends, initialized as follows: newSplitChan :: IO (InChan a, OutChan a) I've implemented this already here: http://hackage.haskell.org/package/chan-split . You can ignore the type classes I've defined; they're there for my own reasons and not part of the proposal. Here is my best defense: 1) My own (and I assume others') use of Chans involves some bits of code which do only reads, and others which do only writes; a split implementation lets us use the type-checker to allocate read or write "permissions" when we pass around either end, and generally makes things easier to reason about. Others have independently reached this conclusion as well. 2) The API is simpler (and in the case of TChans *much* simpler) with a split approach; some examples: in TChan the types of the 'duplicate' functions actually suggest (IMHO) the details of how they treat existing messages, and require a less roundabout explanation dupTChan :: InTChan a -> STM (OutTChan a) cloneTChan :: OutTChan a -> STM (OutTChan a) another example, 'newBroadcastTChan' is actually just: -- | Create a new write end of a TChan. Use dupTChan to get an OutChan that values can be read from. newInTChan :: STM (InTChan a) and doesn't require any explanation beyond that. 3) It's trivial to modify the *Chan libs in this way with a few edits (really, they're already implemented this way, but with some added contortions to return both a read and write end for each operation), so there're no new tricky concurrency issues to reason about. 4) Values written to the write end can be reliably GC'd when readers go away, although recent GHC seems to be able to do this on the current implementation with -O2 on my simple tests. 5) While this is a big API change, I imagine the vast majority of users would only have to change a few type signatures and the Chan initialization action. An `OldChan` module could easily be implemented in terms of the new split version. Alternatively, a *Chan.Split module could be added, and the current Chan module defined in terms of it. So two weeks of discussion? Thanks all, Brandon http://brandon.si

9 10

very last HP mac release candidates for 2012.4.0.0
by Mark Lentczner 05 Nov '12

05 Nov '12

Haskellistas - The third release candidate of the Mac OS X build of HP 2012.4.0.0 is now available: - Mac 32-bit installer: Haskell Platform 2012.4.0.0 32bit rc3 signed.pkg<http://ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%2032bit…> - Mac 64-bit installer: Haskell Platform 2012.4.0.0 64bit rc3 signed.pkg<http://ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%2064bit…> Unless I hear hew and cry, I'll bless these, and the rest of 2012.4.0.0 as released tomorrow night. - Mark

1 0

Proposal: Num instance for tuples
by Twan van Laarhoven 01 Nov '12

01 Nov '12

Dear list, One piece of utility code that I find myself writing over and over again is the pointwise Num instance for tuples, i.e. instance (Num a, Num b) => Num (a,b) where fromInteger x = (fromInteger x, fromInteger x) (a,b) + (a',b') = (a + a', b + b') (a,b) - (a',b') = (a - a', b - b') (a,b) * (a',b') = (a * a', b * b') negate (a,b) = (negate a, negate b) abs (a,b) = (abs a, abs b) signum (a,b) = (signum a, signum b) I therefore propose that this instance be added to the base library. If we do that, the equivalent instances for (,,) (,,,) etc. should perhaps also be added, as well as instances for other numeric classes such as Fractional and Floating. Discussion period: 2 weeks, ends 2012-11-01. Twan

15 18

Proposal: packages in GHC should have different versions from hackage if the packages differ
by Henning Thielemann 31 Oct '12

31 Oct '12

I opened the following ticket [1] about the versioning of packages shipped with GHC, but was told to start a discussion first. I hope libraries(a)haskell.org is the right place to do that. [1] http://hackage.haskell.org/trac/ghc/ticket/6053 Let me repeat the issue description here: I try to compile a package with many dependencies using GHC-7.5.20120426 in order to check whether #5970 is resolved. This turns out to be difficult because this temporary GHC version seems to use packages with the same version as their counterparts on Hackage but different content. For example GHC-7.5.20120426 is bundled with unix-2.5.1.0 and bytestring-0.10.0.0. However the unix-2.5.1.0 on Hackage excludes bytestring-0.10.0.0. Thus cabal-install refuses to install something that depends on unix-2.5.1.0. Another example: Both GHC-7.4.1 and GHC-7.5.20120426 are bundled with base-4.5.0.0. However in GHC-7.5, Num is no longer superclass of Bits. I think such a change requires a version bump to base-4.6. In my opinion the condition should be that if you publish a package on Hackage then there should not be a package with the same version but different content somewhere else. Thus I propose that package versions are increased immediately in the repository according to the PVP if something is changed. That's how I handle versioning for my private packages, too.

5 5

Time to add the Traversable laws to the Documentation
by roconnor＠theorem.ca 30 Oct '12

30 Oct '12

Based on recent work of Edward Kmett and myself and older work by Twan van Laarhoven, we have derived a set of laws for Traversable that are essentially the same to the Laws given by Jeremey Gibbons, Bruno Oliveria in "The Essence of the Iterator Pattern" and which are again the same as the laws given by Mauro Jaskelioff and Ondrej Rypacek in "An Investigation of the Laws of Traversals". With such wide spread agreement going back at least 6 years, I think it is time to add the following 2 laws to the documentation for Data.Traversable.Traversable. (1) traverse Identity == Identity (2) traverse (Compose . fmap g . f) == Compose . fmap (traverse g) . traverse f (and adding a link to the paper titled "An Investigation of the Laws of Traversals" is probably also worthwhile.) In some publications you will see law 1 written as traverse (Identity . f) == Identity . fmap f This is form is equivalent to law 1 by parametricity. Another alterantive formulation of law 1 is traverse pure == pure which is equivalent to law 1 by the Applicative typeclass parametricity. I can provide short proofs of these two equivalences on demand. Of these different formulations of law (1), I think "traverse Identity == Identity" is the nicest because it is concise, mirrors the analogous functor law, and Identity is the natural identity element for Compose. But more importantly, some choice of formal specification of the traversal laws needs to be added to the documentation. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

3 8

Re: Proposal: split Chan and TChan into read and write ends
by Brandon Simmons 30 Oct '12

30 Oct '12

> On 10/27/12 12:28 PM, Johan Tibell wrote: >> I think this makes for a great package or perhaps an extra >> Unidirectional module nested inside the Chan module. Breaking the well >> used Chan API doesn't seem necessary in this case. > > I agree. I like the idea, and I'd like to see it gain traction, but I'm > not so keen on breaking the Chan/TChan API. Also, there seem to be some > API issues to be ironed out (e.g., someone proposed > > newBrodcastTChan :: STM (InTChan a, STM (OutTChan a)) > > which has an obvious meaning, over > > newInTChan :: STM (InTChan a) > > which is going to take some explaining.) I assume you mixed those up? `newBroadcastTChan` naturally turns into the (IMHO) much simpler `newInTChan` when the chan ends are split. > > > It sounds like many people have implemented versions of this and > uploaded them to Hackage already. Perhaps the best approach would be to > (1) unify all those packages into a single "blessed" package, to reduce > redundancy; (2) advertise that package as the way to go for new > projects; (3) add it to the Platform if it gains traction; (4) maybe get > around to deprecating the current Chan/TChan API some years down the > road when it's no longer popular. The best approach then for this route would be to go through the Chan and TChan package and to turn it into a "split" version with minimum edits (should only take a few minutes), perhaps changing a few names where a better one obviously exists or the original no longer makes sense (e.g. newBroadcastTChan). That way people can both see it's correct, and easily port their code over. I also wanted to link to in my original post, but couldn't find for some reason, Leon P Smith's library: http://hackage.haskell.org/package/split-channel It uses the name 'listen' for the equivalent function to the old 'dupTChan' which I think is an excellent choice. Brandon

1 0

Re: Proposal: split Chan and TChan into read and write ends
by Brandon Simmons 27 Oct '12

27 Oct '12

On Sat, Oct 27, 2012 at 8:48 PM, Shachaf Ben-Kiki <shachaf(a)gmail.com> wrote: > On Fri, Oct 26, 2012 at 8:23 PM, Brandon Simmons > <brandon.m.simmons(a)gmail.com> wrote: >> Hi everybody, >> Just discovered all the great discussion here, and although my >> google-fu turned up no prior discussions on this subject, I apologize >> if it has already been discussed. >> >> I propose that Chan and TChan should be implemented as a pair of read >> and write ends, initialized as follows: >> >> newSplitChan :: IO (InChan a, OutChan a) >> >> I've implemented this already here: >> http://hackage.haskell.org/package/chan-split . You can ignore the >> type classes I've defined; they're there for my own reasons and not >> part of the proposal. >> >> Here is my best defense: >> >> 1) My own (and I assume others') use of Chans involves some bits of >> code which do only reads, and others which do only writes; a split >> implementation lets us use the type-checker to allocate read or write >> "permissions" when we pass around either end, and generally makes >> things easier to reason about. Others have independently reached this >> conclusion as well. >> > > To (1), it's probably worth mentioning the idiom of pre-applying > readTChan and writeTChan to a channel to produce values of types "STM > a" and "a -> STM ()", which gives you something pretty similar to > read-only and write-only channels. It doesn't solve every problem, but > for many things it's much simpler than introducing special-purpose > types that only ever have one operation applied to them (similarly you > could use values "STM (STM a)" with dupTChan/newBroadcastTChan, and so > on). > > Shachaf Ah! I use that myself in a library because it let me create Functor and Contravariant instances for the read and write ends respectively, and I didn't require any additional operations beyond read and write.

2 1

Release Candidates for Haskell Platform 2012.4.0.0
by Mark Lentczner 26 Oct '12

26 Oct '12

The second release candidate of HP 2012.4.0.0 is now available: - Source tarball: haskell-platform-2012.4.0.0-rc2.tar.gz<http://ozonehouse.com/mark/platform/haskell-platform-2012.4.0.0-rc2.tar.gz> - Mac 32-bit installer: Haskell Platform 2012.4.0.0 32bit rc2 signed.pkg<http://ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%2032bit…> - Mac 64-bit installer: Haskell Platform 2012.4.0.0 64bit rc2 signed.pkg<http://ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%2064bit…> - Windows installer: HaskellPlatform-2012.4.0.0-rc1-setup.exe<http://code.haskell.org/~refold/HaskellPlatform-2012.4.0.0-rc1-setup.exe> Tickets closed for this release: http://trac.haskell.org/haskell-platform/query?status=closed&group=componen… If you can, please test the release candidate and let us know how it works out. We are on track for final release on November 5th. - Mark

1 0

Re: [Haskell-cafe] Release Candidate 2: HP 2014.4.0.0
by Mark Lentczner 19 Oct '12

19 Oct '12

On Fri, Oct 19, 2012 at 9:30 AM, Colin Adams <colinpauladams(a)gmail.com>wrote: > That's VERY efficient (2014 editions out in 2012). Silly me! Of course, the links are correct: no time travel this cycle - just plain ole' 20*12*.4.0.0 .. aaaaaand: Mac OS 64-bit candidate is out: Haskell Platform 2012.4.0.0 64bit rc2 signed.pkg<http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%206…> *NOTE:* You can only have one architecture per HP version at a time installed on Mac OS X. If you want to switch architectures within the same version of the platform, please use the *uninstaller-hs* utility to remove the one you have *before* installing the other one. If you don't, you'll get an installer error at the end -- it will all work, but your documentation will be less than perfect. *NOTE:* If you use macports <http://www.macports.org/> or homebrew<http://mxcl.github.com/homebrew/>, then be sure that you choose the same architecture (32bit / 64bit) as macports or brew is using, since I believe those systems do not install universal libs (both architectures) by default. - Mark

1 0

Release Candidate 2: HP 2014.4.0.0
by Mark Lentczner 19 Oct '12

19 Oct '12

Haskellistas - The second release candidate of HP 2014.4.0.0 is now available: - Source tarball: haskell-platform-2012.4.0.0-rc2.tar.gz<http://ozonehouse.com/mark/platform/haskell-platform-2012.4.0.0-rc2.tar.gz> - Mac 32-bit installer: Haskell Platform 2012.4.0.0 32bit rc2 signed.pkg<http://ozonehouse.com/mark/platform/Haskell%20Platform%202012.4.0.0%2032bit…> Mac notes: This version is now digitally signed by me, and so will install without fuss on OS X 10.8. I'll put up 64-bit version soon. - Mark Changes since RC1: TODO ---- [x] update vector and primitive versions (they had a point release to fix a bad bug, and the fix was very very simple) [x] remove Build.hs - it did all its work by shelling out anyway! [x] main .cabal file should not have versions commented out [x] this will require a way to extract the list of packages that need to be part of the source release [x] why not also extract the list of packages needed for core.packages [x] fix to build.hs (ticket #195) [x] bugs in build.sh (ticket #197) [x] build instructions in the tarball (ticket #207) [x] merge in shared library patch (ticket #198) MAC TODO -------- [x] mac cabal script needs to quote things with $HOME or ~ in them (ticket #192) [x] If the cabal command is "update" then the wrapper script shouldn't do an update the first time through! [x] sign Mac installers (ticket #203)

1 0