- Libraries - Haskell.org

Notes from "Haskell takes over the world" BoF at ICFP
by Don Stewart 07 Oct '10

07 Oct '10

Here are the notes transcribed from the Future of Haskell BoF held after the Haskell Symposium last week. -- Don = Future of Haskell BoF Notes = A "birds of a feather" meeting was held at ICFP, organized by Bryan and Johan. We had 30 (?) people in a room, for 2 hours, discussing how to ensure Haskell succeeds. These are the transcribed notes. == Libraries == * Need to encourage special interest groups (SIGs) to form around particular domain areas in the libraries. AI, BioInf, Networking, etc. * Document the SIG process: what resources they have, how you get results. * Missing SIGs for certain platforms: Mac, CentOS etc. * More tutorials on use of Haskell in particular domains. * Keen for Hackage 2.0 quality review tools: embedded wikis, voting * Hackage analysis tools: reverse indexing of the code base. * There is no PVP tool. * Library fragmentation occuring due to type duplication (String, Text, ...) * Focus on intitiatives for common, core types. HP polish. * What is the "Son of Containers" going to be? * Build reports would help the community a lot. Integrated with Hackage. Haddock pages on hackage should be editable wikis (per-top-level function, dvcs backed? record history, captchas. roll back spam, by default assume good contributions) * Need to register patches to packages with lost maintainers. * Belgium Hackathon coming up. * Improve libraries process: esp. for small contributions. * Hackage maintainance: + maintainer timeout. + hackage package clobbering. + tweaks. hackage-local .cabal fixes. * Unclear what the rules for contributing are. Document them! * In particular, document how to contribute to: * ghc * cabal * core and HP * hackage * dockathon == IDEs == * A new ghci. + scriptable, scion-server? + repls on top of ghc-api + ruby repl + .ghci + documentation + hpaste/ghci. * IDE + scion. contributions. market places. + documentation. + EclipseFP, scion? + NetBeans. * Special Interest Groups + as the vehicle for domain projects. + formal process for forming a group. + a small amount of structure for groups + document process for forming a strike team. * haskell.org + polishing the wiki. + wikibooks. + call for sig. * haskell visual design group? + consistent color themes across haskell.org sites. + consistent haskell branding. * community server mailing lists in poor state * Move community more online ? Community services. + google groups + digests. + reply at the right point in the threads. + serious lists. + ghc users. libraries. + announces. + stackoverflow for new questions? + keep refering to SO. + reddit for news? == GHC == * ghc status + 50% split in room on moving ghc from darcs to git. + bug reports and interaction load with ghc + well documented workflow for lightweight changes + heavy weight process for major work. + bugs, tickets. + Simon Marlow "contributions are going up, and process is working well" * Release schedule. + RC at ICFP. + GHC release page. + HP/GHC release. + stage releases. + more clearly announced that ghc will be a beta prior to GHC HP. * HP, uses GHC installers as is. GHC zip. == Teaching / tutorials == * Tutorials. Documentation. + Writing a blog post that is wrong is a pretty good way to get feedback. + Find a forum to ask the question, so the answer is findable. + Ask on SO. + Clojure and Scala communities have active blog spheres. + they love descriptions of data structures + e.g. high fanout trees. + Aggregating the ephemera. + Archives: Haskell Reddit has all the interesting blog posts. -- Haskell Wikibook. * Cabal and integration with other languages. + Easier integration with C. + Higher barrier to entry on the Mac. + Playing well with other languages?

2 1

random gremlin
by Conor McBride 06 Oct '10

06 Oct '10

M'luds, There's probably a place to report this properly, but I thought if I mentioned it here, you could throw cabbages at me and tell me where to go. Exhibit A, from http://haskell.org/ghc/docs/6.12.2/html/libraries/random-1.0.0.2/System-Ran… "In addition, read may be used to map an arbitrary string (not necessarily one produced by show) onto a value of type StdGen. In general, the read instance of StdGen has the following properties: * It guarantees to succeed on any string." Exhibit B, from ghci Prelude System.Random> read "00-00-00-00-00-00" :: StdGen Loading package old-locale-1.0.0.2 ... linking ... done. Loading package time-1.1.4 ... linking ... done. Loading package random-1.0.0.2 ... linking ... done. *** Exception: Prelude.read: no parse The prosecution rests. Conor

2 4

building network-2.2.1.7 on Windows
by wagnerdm＠seas.upenn.edu 06 Oct '10

06 Oct '10

Hello all, I am once again trying to guide a non-Haskeller through http://dmwit.com/wyvern/#install_source and he is having trouble getting the network package installed. Any ideas what the problem could be? Thanks! ~d P.S. IcedEarth, sorry for the duplicate message. I was apparently not a libraries(a)haskell.org member when I sent the first one. Quoting IcedEarth <icedearth(a)baduk.org>: > *So, it phailed at this step:* > > $ cabal install dgs sgf > Resolving dependencies... > Configuring network-2.2.1.7... > checking build system type... i686-pc-cygwin > checking host system type... i686-pc-cygwin > checking for gcc... gcc > checking for C compiler default output file name... a.exe > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... .exe > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for an ANSI C-conforming const... yes > checking how to run the C preprocessor... gcc -E > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking limits.h usability... yes > checking limits.h presence... yes > checking for limits.h... yes > checking for stdlib.h... (cached) yes > checking for sys/types.h... (cached) yes > checking for unistd.h... (cached) yes > checking winsock2.h usability... no > checking winsock2.h presence... yes > configure: WARNING: winsock2.h: present but cannot be compiled > configure: WARNING: winsock2.h: check for missing prerequisite headers? > configure: WARNING: winsock2.h: see the Autoconf documentation > configure: WARNING: winsock2.h: section "Present But Cannot Be Compiled" > configure: WARNING: winsock2.h: proceeding with the preprocessor's result > configure: WARNING: winsock2.h: in the future, the compiler will take > precedence > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to libraries(a)haskell.org ## > configure: WARNING: ## ------------------------------------ ## > checking for winsock2.h... yes > checking ws2tcpip.h usability... no > checking ws2tcpip.h presence... yes > configure: WARNING: ws2tcpip.h: present but cannot be compiled > configure: WARNING: ws2tcpip.h: check for missing prerequisite headers? > configure: WARNING: ws2tcpip.h: see the Autoconf documentation > configure: WARNING: ws2tcpip.h: section "Present But Cannot Be Compiled" > configure: WARNING: ws2tcpip.h: proceeding with the preprocessor's result > configure: WARNING: ws2tcpip.h: in the future, the compiler will take > precedence > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to libraries(a)haskell.org ## > configure: WARNING: ## ------------------------------------ ## > checking for ws2tcpip.h... yes > checking wspiapi.h usability... no > checking wspiapi.h presence... no > checking for wspiapi.h... no > checking arpa/inet.h usability... no > checking arpa/inet.h presence... yes > configure: WARNING: arpa/inet.h: present but cannot be compiled > configure: WARNING: arpa/inet.h: check for missing prerequisite headers? > configure: WARNING: arpa/inet.h: see the Autoconf documentation > configure: WARNING: arpa/inet.h: section "Present But Cannot Be > Compiled" > configure: WARNING: arpa/inet.h: proceeding with the preprocessor's result > configure: WARNING: arpa/inet.h: in the future, the compiler will take > precedence > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to libraries(a)haskell.org ## > configure: WARNING: ## ------------------------------------ ## > checking for arpa/inet.h... yes > checking netdb.h usability... no > checking netdb.h presence... yes > configure: WARNING: netdb.h: present but cannot be compiled > configure: WARNING: netdb.h: check for missing prerequisite headers? > configure: WARNING: netdb.h: see the Autoconf documentation > configure: WARNING: netdb.h: section "Present But Cannot Be Compiled" > configure: WARNING: netdb.h: proceeding with the preprocessor's result > configure: WARNING: netdb.h: in the future, the compiler will take > precedence > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to libraries(a)haskell.org ## > configure: WARNING: ## ------------------------------------ ## > checking for netdb.h... yes > checking netinet/in.h usability... no > checking netinet/in.h presence... yes > configure: WARNING: netinet/in.h: present but cannot be compiled > configure: WARNING: netinet/in.h: check for missing prerequisite > headers? > configure: WARNING: netinet/in.h: see the Autoconf documentation > configure: WARNING: netinet/in.h: section "Present But Cannot Be > Compiled" > configure: WARNING: netinet/in.h: proceeding with the preprocessor's result > configure: WARNING: netinet/in.h: in the future, the compiler will take > precedence > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to libraries(a)haskell.org ## > configure: WARNING: ## ------------------------------------ ## > checking for netinet/in.h... yes > checking netinet/tcp.h usability... no > checking netinet/tcp.h presence... yes > configure: WARNING: netinet/tcp.h: present but cannot be compiled > configure: WARNING: netinet/tcp.h: check for missing prerequisite > headers? > configure: WARNING: netinet/tcp.h: see the Autoconf documentation > configure: WARNING: netinet/tcp.h: section "Present But Cannot Be > Compiled" > configure: WARNING: netinet/tcp.h: proceeding with the preprocessor's result > configure: WARNING: netinet/tcp.h: in the future, the compiler will take > precedence > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to libraries(a)haskell.org ## > configure: WARNING: ## ------------------------------------ ## > checking for netinet/tcp.h... yes > checking sys/socket.h usability... no > checking sys/socket.h presence... yes > configure: WARNING: sys/socket.h: present but cannot be compiled > configure: WARNING: sys/socket.h: check for missing prerequisite > headers? > configure: WARNING: sys/socket.h: see the Autoconf documentation > configure: WARNING: sys/socket.h: section "Present But Cannot Be > Compiled" > configure: WARNING: sys/socket.h: proceeding with the preprocessor's result > configure: WARNING: sys/socket.h: in the future, the compiler will take > precedence > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to libraries(a)haskell.org ## > configure: WARNING: ## ------------------------------------ ## > checking for sys/socket.h... yes > checking sys/uio.h usability... no > checking sys/uio.h presence... yes > configure: WARNING: sys/uio.h: present but cannot be compiled > configure: WARNING: sys/uio.h: check for missing prerequisite headers? > configure: WARNING: sys/uio.h: see the Autoconf documentation > configure: WARNING: sys/uio.h: section "Present But Cannot Be Compiled" > configure: WARNING: sys/uio.h: proceeding with the preprocessor's result > configure: WARNING: sys/uio.h: in the future, the compiler will take > precedence > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to libraries(a)haskell.org ## > configure: WARNING: ## ------------------------------------ ## > checking for sys/uio.h... yes > checking sys/un.h usability... no > checking sys/un.h presence... yes > configure: WARNING: sys/un.h: present but cannot be compiled > configure: WARNING: sys/un.h: check for missing prerequisite headers? > configure: WARNING: sys/un.h: see the Autoconf documentation > configure: WARNING: sys/un.h: section "Present But Cannot Be Compiled" > configure: WARNING: sys/un.h: proceeding with the preprocessor's result > configure: WARNING: sys/un.h: in the future, the compiler will take > precedence > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to libraries(a)haskell.org ## > configure: WARNING: ## ------------------------------------ ## > checking for sys/un.h... yes > checking for readlink... yes > checking for symlink... yes > checking for struct msghdr.msg_control... yes > checking for struct msghdr.msg_accrights... no > checking for struct sockaddr.sa_len... no > checking for in_addr_t in netinet/in.h... yes > checking for SO_PEERCRED and struct ucred in sys/socket.h... yes > checking for _head_libws2_32_a in -lws2_32... yes > checking for getaddrinfo... no > checking for getaddrinfo if WINVER is 0x0501... no > checking for gai_strerror... yes > checking whether AI_ADDRCONFIG is declared... no > checking whether AI_ALL is declared... no > checking whether AI_NUMERICSERV is declared... no > checking whether AI_V4MAPPED is declared... no > checking for sendfile in sys/sendfile.h... no > checking for sendfile in sys/socket.h... no > checking for gethostent... no > configure: creating ./config.status > config.status: creating network.buildinfo > config.status: creating include/HsNetworkConfig.h > cabal.exe: Missing dependency on a foreign library: > * Missing header file: HsNet.h > This problem can usually be solved by installing the system package that > provides this library (you may need the "-dev" version). If the library is > already installed but in a non-standard location then you can use the flags > --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > cabal.exe: Error: some packages failed to install: > HTTP-4000.0.9 depends on network-2.2.1.7 which failed to install. > dgs-0.2 depends on network-2.2.1.7 which failed to install. > network-2.2.1.7 failed during the configure step. The exception was: > ExitFailure 1

2 2

Make lines stricter to fix a space leak
by Daniel Fischer 06 Oct '10

06 Oct '10

Proposal: A stricter implementation of lines. Reason: The current implementation causes a space leak (cf. http://homepages.inf.ed.ac.uk/wadler/papers/leak/leak.ps) at least in GHC. The proposed implementation fixes the leak at the small cost of being stricter if the first _|_ in the String is the first character of a line. Discussion period: Three weeks, until 15th October (because of ICFP). Ticket: http://hackage.haskell.org/trac/ghc/ticket/4334 Cheers, Daniel

10 22

Making it easier to contribute non-functional changes
by Johan Tibell 05 Oct '10

05 Oct '10

Hi all, During the work on the containers library, I felt that it's too difficult to contribute non-functional changes to the libraries managed by the libraries list. If you look at repos of libraries managed by individuals, rather than the libraries list, you see a smattering of small changes that improve: the internal structure, the docs, the tests, and (if you're lucky) the benchmarks of the library. I'd like to see (and make) more non-functional changes to the core libraries, but currently I feel that the overhead of creating a ticket, writing an email, etc., is too large; what should be a 5-minute change stretches to over two weeks. I argue that's the reason we don't see many small, but important, changes to the core libraries. Proposal: Non-functional changes should be allowed without review by the libraries list. Such changes can be commited directly, if the commiter has access to the repo, or attached to a "please merge" ticket on the bug tracker. Only changes that don't affect the API or performance (in non-trivial ways) should be allowed in without a review. Examples of patches that shouldn't require review: addition of tests/benchmarks, smaller documentation improvements, internal reorganization, updates due to compiler changes, etc. It's possible that once a commit that should have been reviewed gets commited. I suggest we adopt an "ask for forgiveness, not for permission" policy in these cases. We can always roll back changes. N.B. If someone (e.g. Ian) commits patches of this nature on someone else's behalf, that person should not be held responsible if the patches are rolled back later. Comments welcome! Cheers, Johan

9 15

A paper about the balance of Data.Map and Set
by Kazu Yamamoto 05 Oct '10

05 Oct '10

Hello, This is call for reviewers of our paper. We (Mr Hirai and I) have proved by Coq that the balance of Data.Map with the parameters (3,2) can be maintained after insertion and deletion. We are writing a paper about it and have already showed Milan and Simon PJ. Simon suggested us to find those who are interested in our paper on this ML. If someone are interested and kindly volunteer to review it, please tell us. We will tell the URL of our draft. To be precise, we found the exact valid area of the parameters (delta,ratio) not for Adams's scheme but for Nievergelt & Reingold's scheme. The area is very complicated. (3,2) is one and only one integer solution. Also we found ways to produce counter examples which break balance after deletion. Milan kindly did benchmark comparing Adams (4,2), Adams (3,2), and Nievergelt & Reingold (3,2). Performance of insert, delete, lookup, and merge is almost the same. Milan also pointed out that we should prove that the join function can maintain balance. We are now workig on this. Regards, --Kazu

1 0

Cabal pretty printer, Bug in Prelude, Cabal Test Suite Syntax
by Jürgen Nicklisch-Franken 04 Oct '10

04 Oct '10

This patch adds a pretty printer for GenericPackageDescription. I added a new module Distribution.PackageDescription.PrettyPrint which exports writeGenericPackageDescription and showGenericPackageDescription. I use the field printers from Parse.hs, so that I had to add export statements for them in Distribution.PackageDescription.Parse. I decided to not use a class based approach because: 1. their is already the Text class, which has a parse I didn't want to write, and 2. and more important, I didn't want to use -XFlexibleInstances because I guess cabal should be portable. I have not removed the old printer code, although this may be a good idea (maybe mark it as deprecated first). Then it would make sense as well to rename writeGenericPackageDescription to writePackageDescription and showGenericPackageDescription to showPackageDescription, to be symmetric. I tested with the code from Appendix 1 and the local cabal files of all my installed packages. The test succeeds when writing and reading a package description results in an equal description. This is more rigorous then required, cause different GenericPackageDescr.. can have the same semantic, so for example the order of exe definitions is not relevant. But for our needs (GUI editor of cabal files for leksah), e.g. preserving of order is important and it will help to test the parser and printer to make this approach work. Furthermore I want to print out the cabal file as short as possible, e.g. not printing all empty fields like the old printer did. Testing the code I found the following problems: 1. Found up an obvious "age old" bug: hunk ./Distribution/PackageDescription/Parse.hs 359 - ghcProfOptions (\val binfo -> binfo{ghcSharedOptions=val}) + ghcSharedOptions (\val binfo -> binfo{ghcSharedOptions=val}) 2. The order of elements are reversed by the parser. E.g executables: (repos, flags, lib, exes, tests) <- getBody return (repos, flags, lib, exes ++ [(exename, flds)], tests) since the rest is parsed in the line before, the element needs to be prepended. so I changed to: (repos, flags, lib, exes, tests) <- getBody return (repos, flags, lib, (exename, flds): exes, tests) The same applies to test fields. The opposite order problem applies to storeXFields.., which is called in the order of processing, so I changed it to storeXFieldsPD (f@('x':'-':_),val) pkg = Just pkg{ customFieldsPD = (customFieldsPD pkg) ++ [(f,val)]} 3. The next problem is that we print nothing for empty fields , which works ok, except for compiler opts, where empty opts differ from not given opts, so I added this line to optsField in ParseUtils, which causes empty opts to be parsed, as if no opts are given: update f opts [] = [(f,opts)] 4. The next problem is that we loose final newlines with showFreeText. Astonishing enough the culpid is lines from the List module , which evals lines "a\n" to ["a"]. By the way even the claim that "'unlines' is an inverse operation to 'lines'" from the List module is not true, as unlines (lines "a") -> "a\n" (see Appendix 2). So I use my own unlines' now!. 5. The last problem is connected to the CondTree structure. When I write a Cabal file like: ... library extensions: ForeignFunctionInterface if flag(use_xft) build-depends: X11-xft >= 0.2, utf8-string extensions: ForeignFunctionInterface ... the extension ForeignFunctionInterface in the conditional branch is superflous, as it is specified in any case, so the printer can simplify it to: ... library extensions: ForeignFunctionInterface if flag(use_xft) build-depends: X11-xft >= 0.2, utf8-string ... However the parse result for the two cabal files will differ. Now I gave up here, and added a variable simplifiedPrinting which disables the printer smartness for now. However, I hope someone can make the parser smarter in this respect. Finally a question, is their a way to retreive the cabal files of all packages on Haskell? This would make my tests more extensive. Cheers Jürgen PS. I have added a remark about the new test suite syntax below. ------------------- Appendix1: Test code main = do allCabalFiles <- ... res <- mapM test allCabalFiles if and res then putStrLn "all test succeeded" else putStrLn $ "tests failed: " ++ show (length (filter (== False) res)) ++ " of: " ++ show (length res) test :: FilePath -> IO Bool test cabalFilePath = catch (do gpd <- readPackageDescription silent cabalFilePath writeGenericPackageDescription tempPath gpd gpd2 <- readPackageDescription silent tempPath if gpd == gpd2 then do putStr "." return True else do putStrLn $ "failed for " ++ cabalFilePath return False) (\e -> do putStrLn $ "runtime error " ++ show e ++ " for " ++ cabalFilePath return False) ------------------ Appendix2: lines and unlines revised: -- | 'unlines' is an inverse operation to 'lines'. -- It joins lines, after appending a terminating newline to each. unlines' :: [String] -> String unlines' [] = [] unlines' [x] = x unlines' (x:xs) = x ++ ('\n' : unlines' xs) -- | 'lines' breaks a string up into a list of strings at newline -- characters. The resulting strings do not contain newlines. lines' :: String -> [String] lines' [] = [""] lines' s = let (l, s') = break (== '\n') s in l : case s' of [] -> [] (_:s'') -> lines' s'' ---------------- Appendix 3: I find the test suite syntax problematic, for an exe I have to remeber the combination: test-suite foo type: exitcode-stdio-1.0 main-is: main.hs , and for a module: test-suite bar type: library-1.0 test-module: Bar So its the combination of exitcode-stdio- and main-is or library- and test-module which does the trick. Wouldn't it be easier to write something like: test-suite foo test-version: 1.0 main-is: main.hs , and for a module: test-suite bar test-version: 1.0 test-module: Bar

2 1

Proposal: Better power for Rational
by Daniel Fischer 04 Oct '10

04 Oct '10

Proposal: A better implementation of powers for Rational Discussion period: Three weeks, until 16^th^ October 2010 (ICFP again) Exponentiation by repeated squaring, as is used in (^) is bad for Rational since on each multiplication a gcd has to be calculated. For well-formed Rationals, the numerator and denominator are known to be coprime, hence all powers of the numerator and denominator are also coprime. To avoid superfluous work, I propose a special power function for Rationals and a rewrite rule to replace calls to (^) for Rational bases by the special function. It might also be beneficial to export the specialised function from Data.Ratio to be used if the rule doesn't fire. Proposed function and rule: ratPow :: Integral a => Rational -> a -> Rational ratPow _ e | e < 0 = error "Negative exponent" ratPow _ 0 = 1 :% 1 ratPow r 1 = r ratPow (0:%y) _ = 0 :% 1 ratPow (x:%1) e = (x^e) :% 1 ratPow (x:%y) e = (x^e) :% (y^e) {-# RULES "power/Rational" (^) = ratPow #-} Like the elimination of `gcd` from recip (#4336), this would yield a great performance boost. Cheers, Daniel

8 21

Monadic version of functions for containers (adjustM, updateWithKeyM, etc)
by Thomas DuBuisson 29 Sep '10

29 Sep '10

All, Is there a reason not to have monadic version of the functions in containers? I've a need for functions of type: adjustM :: (Monad m, Ord k) => (a -> m a) -> k -> Map k a -> m (Map k a) updateWithKeyM :: (Monad m, Ord k) => (k -> a -> m (Maybe a)) -> k -> Map k a -> m (Map k a) where adjustM can be ~ half the cost of separate insert/lookup calls and would obey the following rule: adjustM f k m == liftM (\x -> insert k x m) (f $ lookup k m ) They aren't large, but must be in the containers package due to opacity of Map/Set/etc. Perhaps someone can provide a reason for their omission? If not then I'll probably start yet-another proposal in a week or two (once the current containers proposals and my System.Random proposals have concluded). Tentatively I expect to make a patch that includes proper *M functions for Map, Set, IntMap, and IntSet. Cheers, Thomas

8 14

Re: Monadic version of functions for containers (adjustM, updateWithKeyM, etc)
by John Lato 28 Sep '10

28 Sep '10

> Message: 2 > Date: Mon, 27 Sep 2010 23:32:42 -0400 > From: Johan Tibell <johan.tibell(a)gmail.com> > Subject: Re: Monadic version of functions for containers (adjustM, > updateWithKeyM, etc) > To: Thomas DuBuisson <thomas.dubuisson(a)gmail.com> > Cc: Haskell Libraries <libraries(a)haskell.org> > Message-ID: > <AANLkTinUkkfeaHMZUi7x8Czh0CipFzS1gOK2pxp+0nv2(a)mail.gmail.com<AANLkTinUkkfeaHMZUi7x8Czh0CipFzS1gOK2pxp%2B0nv2(a)mail.gmail.com> > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Sep 27, 2010 at 6:13 PM, Thomas DuBuisson > <thomas.dubuisson(a)gmail.com> wrote: > > All, > > > > Is there a reason not to have monadic version of the functions in > > containers? I've a need for functions of type: > > Ack! Haskell needs effect polymorphism. The API already has 150 > functions. How many more do we need to add if we want to cover all the > monadic versions? > More than anything else, I wish this would be solved for Haskell'. Unfortunately I don't have anything like an implementation or even a proposal. John

1 0