http://blog.gmane.org/gmane.comp.lang.haskell.libraries hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19482 <pre>Hello libraries, it's on! Time to tackle the Applicative-Monad issue, hopefully once and for all. Over the last couple of weeks I've looked through previous proposals, asked #haskell about their opinions, and compiled it all into one file that sums up what I made of that. It's a bit long for an email and uses markdown, so I'll just provide links at the end of this mail instead of pasting it in here. In there, the whole thing and how to approach it is explained in more detail. Here's an abstract of what it the proposal consists of: - Don't break compatibility - Apply it gently - Applicative m =&gt; Monad m - Applicative into Prelude (and therefore into the Report) - (Alternative m, Monad m) =&gt; MonadPlus m - Promote `join` into the Monad typeclass Let's make this happen! I'm going to give a ballpark discussion period of four weeks, but since I can imagine this discussion could become quite complex we shouldn't take it too serious. I'll summarize what's been going on periodically though. David Links: The proposal text on Github (link fixed, sorry for the deadlink yesterday): https://github.com/quchen/articles/blob/master/applicative_monad.md (This file is subject to changes, depending on how this discussion goes. I'll try to make it reflect the current consensus.) And just in case Github silentbans me again for submitting too many edits to my Gist (grrr), here's a copy of the file on HPaste as backup: http://hpaste.org/88423 </pre> David Luposchainsky 2013-05-23T19:39:17 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19467 <pre>This "burning bridges" thread has really got us going! I'm a bit concerned, though, that we don't have an effective mechanism for resolving such debates. If everyone feels that they have a vote, perhaps, but only one among many, then one feels either mandated or indeed willing to invest the extra cycles to summarise pros and cons based on feedback, crisply articulate alternatives, and so on. And, worse still, no one feels mandated to actually decide anything. That's fine when there's a clear consensus; not so fine when there isn't, as here. Several people on the "Burning bridges" thread have commented on the interminable nature of the debate. Our general procedures for library changes are described here: http://www.haskell.org/haskellwiki/Library_submissions. For specialised libraries (eg MD5 checksum, or even containers) the situation is clear: the author or current maintainer decides. But for the basic core libraries, whose influence is pervasive, matters are murkier. Looking at http://www.haskell.org/haskellwiki/Library_submissions#The_Core_Libraries we see that many are maintained by "GHC HQ". But the plain fact is that GHC HQ is not up to the task, especially now that Simon M has moved on to Facebook. To be absolutely explicit, I'm worried that decision making may get stuck because I don't have the capacity to participate, lead, drive, propose, and ultimately make a decision. So there's a decision-making vacuum for the "GHC HQ" libraries. If that's the case, then the best thing is for GHC HQ to get out of the way! Is that what others feel, or are you all happy? My proposal would be to form a Library Tsars committee, that * Takes ownership of the "GHC HQ" libraries * Also owns any global library issues; ones that can't be resolved by a single maintainer Like any maintainer the Library Tsars would be expected to follow the guidance on the wiki http://www.haskell.org/haskellwiki/Library_submissions#Guidance_for_maintainers (responsiveness, consultation, etc). But they could actually decide things. One other thing. I'd certainly consider well-argued proposals for changing GHC to better support backward compatibility in the face of library change. One such proposal was the "class alias" story, but that was a big, complex general mechanism (and arguably big benefits). Because of its complexity it is currently stalled. But there may be other much more modest things we could do to help; the question about ad-hoc deprecation of Monad without Functor is a small, highly-specific, ad-hoc idea. Simon </pre> Simon Peyton-Jones 2013-05-23T07:48:22 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19434 <pre> Here are the current totals by my count, ignoring any 0s: +13 / -0 +1 / -11 +0 / -12 +0 / -13 - C. </pre> Casey McCann 2013-05-22T19:01:13 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19392 <pre>The Mac OS X RC3 installers are up: Haskell Platform 2013.2.0.0 32bit rc3.signed.pkg&lt;http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2032bit%20rc3.signed.pkg&gt; Haskell Platform 2013.2.0.0 64bit rc3.signed.pkg&lt;http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2064bit%20rc3.signed.pkg&gt; Only difference in these from RC2 is that the missing documentation for network, random, and primitive has been restored. These will be the final, barring any catastrophic issue. — Mark 15dd8762c9800308cb7cfdd16ea1a8e74988e06a Haskell Platform 2013.2.0.0 32bit rc3.signed.pkg 89e6fb747816af69acabc5c04cee103257855614 Haskell Platform 2013.2.0.0 64bit rc3.signed.pkg _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Mark Lentczner 2013-05-21T16:15:58 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19373 <pre>I want to apologize to wren (and everybody else). I was tired and overreacted when the discussion started veering into making more breaking changes. I don't mind the Foldable changes too much. My main concerns are: * loss of monomorphism makes teaching more difficult * They can be generalized in other useful ways However, I don't consider those concerns show-stoppers. </pre> Gabriel Gonzalez 2013-05-21T05:41:31 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19370 <pre>lets see what concerns there are 1) will any code break? Nope! In fact, it's trivial to provide a shim that only exposes the list monomorphic versions. 2) does the change make learning the language more challenging? No. In fact, i've encountered *many* more smart people getting confused as to why the map / fold etc in prelude are all list specific than i've seen people struggle with type classes. The various list specific versions of the foldable codes actually **confuses** smart software folks who are starting to learn haskell for fun. I can't explain to a smart engineer *any* reason why minimum :: Ord&lt;http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Ord&gt; a =&gt; [a] -&gt; a exists in prelude. I *can* explain why something like minimum :: (Foldable&lt;http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Foldable.html#t:Foldable&gt; t, Ord&lt;http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Ord.html#t:Ord&gt; a) =&gt; t a -&gt; a would be useful and deserving of being in the standard prelue. I've actually had to explain to a smart python engineering friend who's learning haskell this very problem. (that the list only versions are there for no deep reason aside from some pedagogical approach from over a decade ago that is no longer used) tl;dr no code will break, there will be less inessential nonuniformity that doesn't aid in engineering or learning with haskell, so a win in every direction. lets make things happen. -Carter On Mon, May 20, 2013 at 11:04 PM, &lt;amindfv&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Carter Schonwald 2013-05-21T05:06:18 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19366 <pre>Hi all, I've uploaded the RC1 2013.2.0.0 release candidate installer to http://code.haskell.org/~refold/HaskellPlatform-2013.2.0.0-rc1-setup.exe SHA1: fe9a4eee2fe8839eb3b240f15a2af229a110e37f What's new in 2013.2.0.0-rc1: * Updated versions of all packages Known issues: * OpenGL-related libraries are compiled without -split-objs because of GHC performance issues. * Also see http://trac.haskell.org/haskell-platform/wiki/Windows Unless someone finds serious bugs in this RC, it can be released unchanged. Enjoy! </pre> Mikhail Glushenkov 2013-05-21T00:00:15 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19333 <pre>On some haskell list I read that for lists, mapM_ f l is more space-efficient that just void $ mapM f l Any reason why mapM_ is missing from Data.Traversable? Cheers, Andreas </pre> Andreas Abel 2013-05-18T21:21:53 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19300 <pre>Hello everyone, I recently went through GHC's source, and discovered there are quite a few instances of Monad that don't have Functor or Applicative instances. Fixing this is very easy by adding the standard instances (pure = return etc.), and will not break code. There is one exception to this: Hoopl defines its own (&lt;*&gt;). However, since it does not seem to have any packages depend on it otherwise, renaming this operator is also easily done (the thing is only used ten times or so). I called it (&lt;*|*&gt;) to complement (|*&gt;&lt;*|), but naming should be the least important issue here. Small piece of backstory: The idea behind this is making GHC future-proof for changing Applicative to be a superclass of Monad. However, I think adding the Applicative instances is a good idea regardless of whether this will ever happen, so that's the only thing I'm proposing right now. Greetings, David </pre> David Luposchainsky 2013-05-16T11:33:44 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19285 <pre>Hi, I'm trying to expose some byte swapping (bSwap) capabilities in base, namely operation to allow to swap endianness on word{16,32,64}, i.e.: bswap16 :: Word16 -&gt; Word16 bswap16 a = (a `shiftR` 8) .|. (a `shiftL` 8) ... I'ld want to propose to extends Bits to do so generically: class Bits a where ... bSwap : a -&gt; a I'm attaching a patch that do as explained, and add a default implementation for bSwap, so that compatibility is assured for existing instances. </pre> Vincent Hanquez 2013-05-16T06:59:28 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19266 <pre>Hello all, While looking through the pull requests for stm-chans I came across a discrepancy in the new stm. Namely, we have the following definitions: * stm == 2.4 newBroadcastTChan :: STM (TChan a) newBroadcastTChan = do dummy_hole &lt;- newTVar TNil write_hole &lt;- newTVar TNil read &lt;- newTVar dummy_hole write &lt;- newTVar write_hole return (TChan read write) newBroadcastTChanIO :: IO (TChan a) newBroadcastTChanIO = do dummy_hole &lt;- newTVarIO TNil write_hole &lt;- newTVarIO TNil read &lt;- newTVarIO dummy_hole write &lt;- newTVarIO write_hole return (TChan read write) * stm == 2.4.2 newBroadcastTChan :: STM (TChan a) newBroadcastTChan = do write_hole &lt;- newTVar TNil read &lt;- newTVar (error ...) write &lt;- newTVar write_hole return (TChan read write) newBroadcastTChanIO :: IO (TChan a) newBroadcastTChanIO = do dummy_hole &lt;- newTVarIO TNil write_hole &lt;- newTVarIO TNil read &lt;- newTVarIO dummy_hole write &lt;- newTVarIO write_hole return (TChan read write) Thus, whoever changed the definition of newBroadcastTChan in 2.4.2 forgot to change newBroadcastTChanIO to keep it in sync. PROPOSAL: I propose changing newBroadcastTChanIO to match newBroadcastTChan. (Deadline: 2 weeks) QUESTION: Is there any way to re-implement these functions using only the public API of version 2.3? </pre> wren ng thornton 2013-05-13T05:24:57 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19265 <pre>-------------------------------------------- </pre> wren ng thornton 2013-05-13T04:35:17 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19260 <pre>*We are in the home stretch for Haskell Platform 2013.2!* The Mac OS X RC2 installers are up: Haskell Platform 2013.2.0.0 32bit rc2.signed.pkg&lt;http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2032bit%20rc2.signed.pkg&gt; Haskell Platform 2013.2.0.0 64bit rc2.signed.pkg&lt;http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2064bit%20rc2.signed.pkg&gt; Only real difference in these from RC1 is packaging: the Cabal doc is now included. There is no update to source tarball RC1, which is still there too. I expect these to be renamed the official release within a week. *Packagers:* Please produce Release Candidates. The package version list shouldn't change, unless any of you find an issue. - Mark _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Mark Lentczner 2013-05-11T17:55:42 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19233 <pre>I would like to propose the addition of whenJust :: Monad m =&gt; Maybe a -&gt; (a -&gt; m ()) -&gt; m () whenJust (Just x) f = f x whenJust _ _ = return () to Control.Monad, in the section "Conditional execution of monadic expressions" next to guard :: MonadPlus m =&gt; Bool -&gt; m () when :: Monad m =&gt; Bool -&gt; m () -&gt; m () unless :: Monad m =&gt; Bool -&gt; m () -&gt; m () Why? It would allow us to write more readable code and fit well into the group of similar functions of this style. Compare mUser &lt;- lookupUser whenJust mUser email or whenJust mUser $ \user -&gt; do putStrLn "Mailing!" email user with some currently available alternatives: case mUser of Just user -&gt; do putStrLn "Mailing!" email user Nothing -&gt; return () (Default base case clutter.) import Data.Foldable forM_ mUser $ \user -&gt; do putStrLn "Mailing!" email user (Not too intuitive/well-named here and "Ambiguous occurrence forM_" clash with Control.Monad.) Some more dissatisfying alternatives: maybe (return ()) (\user -&gt; do putStrLn "Mailing!" email user ) mUser flip (maybe (return ())) mUser $ \user -&gt; do putStrLn "Mailing!" email user import Control.Monad.Trans.Maybe import Control.Monad.Trans (lift) _ &lt;- runMaybeT $ return mUser &gt;&gt;= \user -&gt; lift $ do putStrLn "Mailing!" email user return () Alternative names: - withJust, analog to withFile and withForeignPtr Any comments? </pre> Niklas Hambüchen 2013-05-10T06:13:45 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19230 <pre>The Mac OS X installers for HP 2013.2 RC 1 are up: Haskell Platform 2013.2.0.0 32bit rc1.signed.pkg&lt;http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2032bit%20rc1.signed.pkg&gt; Haskell Platform 2013.2.0.0 64bit rc1.signed.pkg&lt;http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202013.2.0.0%2064bit%20rc1.signed.pkg&gt; This corresponds to what is currently checked in to the pre-release branch on github: https://github.com/haskell/haskell-platform/tree/pre-release There is at least one small wibble with these: The cabal documentation is missing. So I expect at least one small turn before final release.... but this is pretty close. - Mark _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Mark Lentczner 2013-05-08T07:41:21 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19226 <pre>The current build of the platform has grown over the years to a somewhat convoluted collection of shell scripts, makefiles, autoconf, and some custom Haskell. It is further complicated by three distinct stages: making the source distribution, building the packages, bundling for distribution. Lastly, I suspect that each distribution (Mac, Windows, and n × unix-like) has it's own path through these stages. I've done some amount of rework on the process over the last two years, but I'm thinking it is time for wholesale replacement. I'm considering using Shake &lt;http://community.haskell.org/~ndm/shake/&gt; to replace all three stages as one build. Distributions could choose to either re-cast their process into this Shake program, or work from the source distribution. The source distribution currently contains scripts and other bits for generically building the platform from source. I currently have no way to know which parts of those bits people rely on for their distributions. This transition would substantially change what is shipped with the source release. *Packagers &amp; Those of you that build the platform from source:* Can you tell me which of these three directions for the source distribution you'd like: - Bare: Just the package sources and a .cabal file, than you. - Scripted: Like the current distribution, shell/make/autoconf scripts that build the platform for some idealized unix-like system. - Programmatic: Include a Haskell program (perhaps Shake based) that builds the platform I'm interested in hearing how people use the source distribution, and/or if people use the repo directly to build. If I hear crickets, I'll take that as free-reign to hatch evil schemes! — Mark _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Mark Lentczner 2013-05-05T15:55:34 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19225 <pre>The source tar-ball for HP 2013.2 RC 1 is up: http://www.ozonehouse.com/mark/platform/haskell-platform-2013.2.0.0-rc1.tar.gz This corresponds to what is currently checked in to the pre-release branch on github: https://github.com/haskell/haskell-platform/tree/pre-release *Packagers:* Please produce an RC1 candidate from the above. I'm having some trouble producing a Mac release (Xcode woes again...) but expect it in a few days. — Mark _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Mark Lentczner 2013-05-05T15:37:13 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19214 <pre>There is a list of problems with the current "Map" and "IntMap" modification interfaces: - they are filled with quirky and too specialized functions - they are not consistent in terms of how equally named functions behave: http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-IntMap-Strict.html#v:updateLookupWithKey - they still don't cover some important scenarios of use Because of the above I have very often found myself in requirement for the following function: withItem :: (Ord k) =&gt; k -&gt; (Maybe i -&gt; (r, Maybe i)) -&gt; Map k i -&gt; (r, Map k i) withItem k f m = let item = Map.lookup k m (r, item') = f item m' = Map.update (const item') k m in (r, m') It covers all the imaginable scenarios of modification operations: delete, update, replace, - yet it also provides one with ability to extract the modified data and not only. The problem is that this implementation involves a repeated lookup for the same item: first with "lookup", then with "update" - but the "containers" library exposes no functionality to get around that. So I suggest to implement an efficient version of "withItem" in the library. This function turns out to be far more generalized than any of the currently present in the library, so it can become a basic building block for all sorts of modifying functions, including all the already existing ones, e.g.: alter :: Ord k =&gt; (Maybe a -&gt; Maybe a) -&gt; k -&gt; Map k a -&gt; Map k a alter f k = snd . withItem k (\i -&gt; ((), f i)) delete :: Ord k =&gt; k -&gt; Map k a -&gt; Map k a delete k = snd . withItem k (const ((), Nothing)) updateLookupWithKey :: (Ord k) =&gt; (k -&gt; a -&gt; Maybe a) -&gt; k -&gt; Map k a -&gt; (Maybe a, Map k a) updateLookupWithKey f k = withItem k $ \i -&gt; case i of Just i -&gt; case f k i of Nothing -&gt; (Just i, Nothing) Just i' -&gt; (Just i', Just i') _ -&gt; (Nothing, Nothing) You can see how easy it makes to achieve any sort of specialized functionality. So, besides the evident benefits, this function can also become a replacement for a whole list of confusing specialized ones, thus greatly lightening the library. You might have also noticed how this function is based around the standard "a -&gt; (b, a)" pattern of the "State" monad, thus making it easily composable with it using the "state" and "runState" functions. Summarizing, my suggestions are: 1. Implement an efficient version of "withItem" for lazy and strict versions of "Map" and "IntMap". 2. Change the order of parameters from "lambda -&gt; key" to "key -&gt; lambda". The "updateLookupWithKey" example implementation shows how this change can be benefitial. 3. Begin the deprecation process of the following functions: insertWith, insertWithKey, insertLookupWithKey, adjust, adjustWithKey, update, updateWithKey, updateLookupWithKey, alter. A deadline for discussion is set to 6 weeks. For a formatted version of this message please visit https://github.com/haskell/containers/issues/28. _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Nikita Volkov 2013-04-30T13:18:48 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19210 <pre> Hi all, Currently, if you try to use rawSystem to run a program that doesn't exist, you will just get a bad error code as a result, e.g. this program: import System.IO.Error import System.Process main :: IO () main = do (rawSystem "/bin/true" [] &gt;&gt;= print) `catchIOError` \e -&gt; putStrLn ("Exc: " ++ show e) (rawSystem "/bin/false" [] &gt;&gt;= print) `catchIOError` \e -&gt; putStrLn ("Exc: " ++ show e) (rawSystem "/non/existent" [] &gt;&gt;= print) `catchIOError` \e -&gt; putStrLn ("Exc: " ++ show e) putStrLn "Done" prints: ExitSuccess ExitFailure 1 ExitFailure 127 Done However, if we are on a platform that supports vfork, then we can pass information from the child process back to the parent process as they share address space. With the attached patch we instead get: ExitSuccess ExitFailure 1 Exc: resolveProcessHandle: does not exist (No such file or directory) (and it should be easy to also get "/non/existent" in the exception). If there are platforms that don't support vfork, then they will still give the old output. I haven't yet looked at whether we can also get good exceptions on Windows (the patch won't build on Windows yet; I still need to update the Windows-specific code). I think that despite the possibility that some platforms may not be able to support it, we should provide the better behaviour on platforms that do. What do you think? And do you have any other comments on the patch? (this proposal was inspired by http://hackage.haskell.org/trac/ghc/ticket/7859). Suggested discussion deadline: Mon 13 May 2013. Thanks Ian _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Ian Lynagh 2013-04-28T13:36:24 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19202 <pre>Hi all, I would like to add a derived MonadPlus instance for both Rand and RandT. Also, since it seems that MonadRandom has no maintainer I propose to take on its maintainership. Any comments/objections/etc. welcome. -Brent </pre> Brent Yorgey 2013-04-24T18:38:01 http://comments.gmane.org/gmane.comp.lang.haskell.libraries/19199 <pre>Hello lists, I'm pleased to announce the first release of data-textual[1], a library that provides human-friendly counterparts (called Printable/Textual) of the compiler-friendly Show/Read type classes. The library is intended to be used for printing and parsing of non-compound and non-polymorphic compound data (e.g. numbers, network and hardware addresses, date/time, etc). A quick example (vs network-ip[2] library): λ&gt; import Data.Maybe (fromJust) λ&gt; import Data.Textual λ&gt; import Network.IP.Addr λ&gt; let x = fromString "[dead::b:e:e:f]:123" :: Maybe Inet6Addr λ&gt; x Just (InetAddr {inetHost = ip6FromWords 0xdead 0x0 0x0 0x0 0xb 0xe 0xe 0xf, inetPort = 123}) λ&gt; toString (fromJust x) "[dead::b:e:e:f]:123" λ&gt; let y = fromStringAs aNet4Addr "192.168.100.1/24" λ&gt; y Just (netAddr (ip4FromOctets 192 168 100 1) 24) λ&gt; toText (netPrefix $ fromJust y) "192.168.100.0" [1] http://hackage.haskell.org/package/data-textual [2] http://hackage.haskell.org/package/network-ip _______________________________________________ Libraries mailing list Libraries&lt; at &gt;haskell.org http://www.haskell.org/mailman/listinfo/libraries </pre> Mikhail Vorozhtsov 2013-04-24T06:18:51 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.libraries