April 2014 - Haskell-Cafe

Re: [Haskell-cafe] "add ifM and whenM to Control.Monad" and other discussions like that
by Yuri de Wit 22 Apr '14

22 Apr '14

I haven't been around for long in the Haskell community, but I have seen a few of these discussions taking long email rounds in different mailing lists. I don't have a strong opinion at this point to add my vote here or there one way or the other, and I do appreciate the effort made by everyone to find a sort of consensus, as hard as that can be sometimes. However, the question I keep asking myself is why can't the compiler disambiguate between two definitions with the same name based on the actual argument types? This would allow packages to choose their own names for functions without such global-naming discussions and without much pain when using them. e.g.: > import PackageA (when) > import PackageB (when) > when (Just True) doSomething versus: > when True 1 Is there a theoretical or practical issue that makes this an undesirable feature in Haskell?

2 1

Does this typeclass have a name?
by Bardur Arantsson 21 Apr '14

21 Apr '14

Hi all, I was wondering if anyone out there knows if this type class has a name? class Foo a e where foo :: e -> a -> a bar :: a (I also have a fundep a -> e, but that's not essential.) Essentially the usage is: You have a sequence of "events" e_i and a starting value "bar" and can use the "foo" function to apply all events to that starting value foo e_n $ foo e_{n-1} $ ... $ foo e_0 $ bar and thus get the final value of the a induced by the events e_i. (I've included the "bar" starting value in the type class, but I suppose it could be supplied by a Default instance.) Regards,

6 10

Re: [Haskell-cafe] conduit zips
by Ben Foppa 21 Apr '14

21 Apr '14

Don't know how I missed those. Thanks! On Mon, Apr 21, 2014 at 3:04 PM, Michael Snoyman <michael(a)snoyman.com>wrote: > Instead of functions, they're now newtype wrappers: ZipSource, ZipSink, > and ZipConduit (that last one never existed as a function). Some > information on each of these: > > * http://www.yesodweb.com/blog/2013/09/zipsinks-conduit-extra > * http://www.yesodweb.com/blog/2014/02/conduit-zip-source > * > http://stackoverflow.com/questions/21671688/single-stepping-a-conduit/21684… > > > On Mon, Apr 21, 2014 at 3:52 AM, Ben Foppa <benjamin.foppa(a)gmail.com>wrote: > >> Since conduit-1.1.*, the package hasn't contained conduit zipping >> functions anymore. They don't appear to have been moved to conduit-extra, >> either. Did they get lost in the ether, or are they in a separate package? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >

1 0

ANN: v0.0.8 of treeviz package released.
by David Banas 21 Apr '14

21 Apr '14

- Split code into multiple files. - Completed Haddoc documentation. - Changed decimation style flag from Boolean to custom type, DecimationStyle, w/ constructors: DIT & DIF, as per Mark L.’s suggestion. - Introduced type alias: type Radix = Int, for readability. cabal install treeviz http://www.haskell.org/haskellwiki/Treeviz Cheers, -db

1 0

GHC-7.8.2 & Win
by Cédric Chantepie 21 Apr '14

21 Apr '14

Hi, Try to setup GHC 7.8.2 & cabal 1.8 on Windows (7/64bits), using binary distributions from haskell.org I get error when I try to install glib package using cabal : cabal: Missing dependency on a foreign library: * Missing (or bad) header file: primitive-memops.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. If the header file does exist, it may contain errors that are caught by the C compiler at the preprocessing stage. In this case you can re-run configure with the verbosity flag -v3 to see the error messages. Failed to install primitive-0.5.2.1 cabal: Error: some packages failed to install: Command cabal install primitive raise the same error. I have tried either within cygwin or from plain cmd. Thanks for any hint, best.

2 1

conduit zips
by Ben Foppa 21 Apr '14

21 Apr '14

Since conduit-1.1.*, the package hasn't contained conduit zipping functions anymore. They don't appear to have been moved to conduit-extra, either. Did they get lost in the ether, or are they in a separate package?

1 0

A list library without fixpoints and recursive types.
by flicky frans 21 Apr '14

21 Apr '14

Hello. I read some Oleg Kiselyov's papers and tried to write more or less efficient list library with lists represented as their right fold, as mentioned here http://okmij.org/ftp/Haskell/zip-folds.lhs : It would be interesting to see, constructively, how to build the full-fledged (FR)-list library and avoid general recursion. Let the FR-list be the only driver of iterations. Here is the code: http://ideone.com/NKNeWy I don't post it to hackage, since I'm not sure, these lists are really efficient. There are two main ideas: 1) List is represented as an accumulating right fold, and an accumulator passes from left to right. 2) For efficiency purposes elements skipping is incorporated into the cons (($:) in the code) function. So there is only one isSkipped test (d == 0 in the code) for every element, no matter, how many times drop (or tail or dropWhile) was applied. So there are no redundant (<= 0) checks, as described in the zip-folds paper: The function sdrop shows the major deficiency: we're stuck with the (<=0) test for the rest of the stream. In this case, some delimited continuation operators like `control' can help, in limited circumstances. Here are the pluses: 1) No fixpoints and recursive types. 2) These lists are totally isomorphic to ordinary haskell's, even in a strict monad. 3) No redundant (<= 0) checks. There are some not very big problems with this encoding: 1) Code becomes more complicated than with the ordinary right fold. 2) In fscanl and fsndMapAccumL functions skipped elements are traversed twice, because you need to traverse an accumulator through skipped elements too. And the same holds for the fdropWhile function with additional skipping overhead. 3) Since an accumulator passes from left to right, it's not possible to efficiently fuse fscanr and fmapAccumR functions, so they are defined in the terms of ($:) and ffoldr. And one big problem: zipWith and all other functions, that require parallel lists processing, are quadratic. And the same holds for the ftails function and all other functions, that deconstruct a list by repeatedly applying (fhead . ftail) or collect lists, obtained by repeteadly applied ftail function. However I have never seen any other representation, expressible in pure System F with higher-rank types, which allows such deconstruction in a linear time. If someone knows, give me a link, please. Any suggestions are welcome.

1 0

Re: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($))
by Doug McIlroy 20 Apr '14

20 Apr '14

> '$$' should be strongly considered That breaks time-honored practice in hugs and ghci. Doug McIlroy

3 2

Announcing cabal 1.20
by Johan Tibell 20 Apr '14

20 Apr '14

Hi all, On behalf of all the cabal contributors, I'm proud to announce cabal 1.20. With 404 commits since the 1.18 release, this is a feature packed release. Here's a short summary of the perhaps most notable changes: * Dependency freezing * Parallel cabal build * Flag to temporary ignore upper bounds * Unnecessary re-linking avoidance * Streaming cabal test output * New cabal exec command * Haddock configuration options I did a longer write-up about the new features on my blog: http://blog.johantibell.com/2014/04/announcing-cabal-120.html ## Contributors Here are the contributors for this release, ordered by number of commits: * Mikhail Glushenkov * Johan Tibell * Duncan Coutts * Thomas Tuegel * Ian D. Bollinger * Ben Armston * Niklas Hambüchen * Daniel Trstenjak * Tuncer Ayaz * Herbert Valerio Riedel * Tillmann Rendel * Liyang HU * Dominic Steinitz * Brent Yorgey * Ricky Elrod * Geoff Nixon * Florian Hartwig * Bob Ippolito * Björn Peemöller * Wojciech Danilo * Sergei Trofimovich * Ryan Trinkle * Ryan Newton * Roman Cheplyaka * Peter Selinger * Niklas Haas * Nikita Karetnikov * Nick Smallbone * Mike Craig * Markus Pfeiffer * Luke Iannini * Luite Stegeman * John Lato * Jens Petersen * Jason Dagit * Gabor Pali * Daniel Velkov * Ben Millwood Apologies if someone was left out. Once in a while we have to make commits on behalf of an author. Those authors are not captured above. Enjoy, Johan

1 0

Minimal Haskell Platform & Syntax proposal for "reverse apply"/"pipeline apply" (flip ($))
by Mike Meyer 19 Apr '14

19 Apr '14

On Fri, Apr 18, 2014 at 5:31 AM, Johan Tibell <johan.tibell(a)gmail.com>wrote: > We use this "don't reopen issues unless circumstances have changed" policy > for HP package proposals*. I think it's a good policy, as it saves valuable > community energy to discuss new things. If things have truly changed, we > can of course have the discussion again. > Where can I find that information? I went looking through the HP pages on Haskell.org, and couldn't turn up anything on contributions, or suggestions, or similar things. I found one link to a github repository, but it didn't have a README :-(. > * We took the policy from Python's PEP proposal policy. > While I'm relatively new to the Haskell community, I've been part of the Python community since I had to explain to my clients what Python was. One of the things that's always impressed me about that community is it's devotion to maintaining the zen of the language. I've watched it grow the official (as in "import this") zen, and the PEP process, and watched various PEPS go through the process. I've even written a few myself, though I only submitted one, which was rejected. Watching the discussion of the syntax proposal reminds me of watching some of the discussions about Python language changes - though if we have a BDFL, I haven't heard of them. That's also how discussions about the Python standard library looked (they're part of the PEP process now). If we want the HP to be generally useful - not just something to make beginners lives easier or provide hard-to-use tools - it needs to be dealt with with equal care. I'd like to contribute to that process. So, questions that I couldn't find answers to: Is there a Haskell equivalent to a Python PEP? Should there be? Is there a place to discus HP issues, other than here? If I want to contribute to the development of the HP, where should I start? Thanks, Mike

3 2