April 2013 - Haskell-Cafe

Categories (cont.)
by Christopher Howard 08 May '13

08 May '13

I've perhaps been trying everyones patiences with my noobish CT questions, but if you'll bear with me a little longer: I happened to notice that there is in fact a Category class in Haskell base, in Control.Category: quote: -------- class Category cat where A class for categories. id and (.) must form a monoid. Methods id :: cat a a the identity morphism (.) :: cat b c -> cat a b -> cat a c morphism composition -------- However, the documentation lists only two instances of Category, functions (->) and Kleisli Monad. For instruction purposes, could someone show me an example or two of how to make instances of this class, perhaps for a few of the common types? My initial thoughts were something like so: code: -------- instance Category Integer where id = 1 (.) = (*) -- and instance Category [a] where id = [] (.) = (++) ------- But these lead to kind mis-matches. -- frigidcode.com

9 14

Stream fusion and span/break/group/init/tails
by Edward Z. Yang 07 May '13

07 May '13

Hello all, (cc'd stream fusion paper authors) I noticed that the current implementation of stream fusion does not support "multiple-return" stream combinators, e.g. break :: (a -> Bool) -> [a] -> ([a], [a]). I thought a little bit about how might one go about implement this, but the problem seems nontrivial. (One possibility is to extend the definition of Step to support multiple return, but the details are a mess!) Nor, as far as I can tell, does the paper give any treatment of the subject. Has anyone thought about this subject in some detail? Thanks, Edward

8 23

BayHac '13
by Mark Lentczner 04 May '13

04 May '13

Please join us for a weekend of Haskell hacking: *BayHac '13* *May 17th ~ 19th, 2013* *Hacker Dojo* *Mountain View, CA* Full details on the Haskell Wiki: BayHac '13<http://www.haskell.org/haskellwiki/BayHac2013> - Mark

2 2

Markdown extension for Haddock as a GSoC project
by Mateusz Kowalczyk 02 May '13

02 May '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, In light of fairly recent discussion, on this mailing list, I decided to investigate the topic of Markdown support for Haddock. The archives of the recent discussion can be seen at [1]. This post aims to summarise the current state of discussion. I do aim to file a proposal for a GSoC project on this issue but it'd be foolish to file a proposal for a project aiming to benefit the community without consulting the community itself. Here are some main points and ideas gathered: * reSt seems to have a small following - quite a bit smaller than the Markdown community. In fact, there seems to be a significant amount of people pushing for Markdown which contrasts what we can read in a topic from 2008 at [2]. I guess it just shows how much Markdown has gained in popularity in recent years. * There are issues with using Markdown even before we attempt to use it for Haskell documentation: * There exists no formal specification or semantics. It would seem that a significant number of Markdown parsers are creating by reverse engineering an already existing parser. This is bad because we end up propagating the bugs and workarounds around ambiguity that the original parser has. * As a follow-up to the previous point, the (vanilla) Markdown is ambiguous and there is nothing to resolve it. As Richard A. O'Keefe pointed out, there exist situations where it's not possible to infer the semantics of Markdown from its official implementation and the result is parser/writer-specific [6]. * John MacFarlane has already written a Markdown parser in Haskell. It can be read at [3]. This means that the new extension would not need to rely on Pandoc. He says ``I have an experimental thing here that could be used as a basis (it's 7x faster than pandoc and uses 1/5 the memory, BSD licensed)''. This is great! The post can be seen in full at [4]. * An alternative idea was to simply write a writer module for Pandoc for Haddock. * A reader module is already present. * According to John MacFarlane, Haddock is not expressive enough to take advantage of this. Furthermore, Pandoc doesn't have some constructions that Haddock does [4]. * Comes back to the problem on relying on such a large package as Pandoc. * Yet another proposal was rather than introducing Markdown to concentrate on fixing current issues and adding features to Haddock as it stands [8]. This is one of the options listed at the short blog post at [14] by Johan Tibell. * David Waern, one of Haddock maintainers admits that Haddock lacks active development and it has been that way for a longer time. Having said that, he seems to believe that Markdown integration is a project that can realistically be completed over summer. Such project would be able to use the existing HTML backend in Haddock. [9]. * Math expressions were requested and MathJAX was suggested as a solution at [5]. math.stackexchange.com uses MathJAX and it works quite well. Personally, I believe that Haskell documentation would benefit from this simply due to the academic nature of the language. * Support for Literate Haskell would be a welcome addition as suggested by Andrew Butterfield at [7]. * There are issues with CPP and LHS in regards to using Markdown in documentation. They are pointed out at [10] by John MacFarlane and others that he's replying to. * As pointed out 5 years ago at [11], we'd have to do some preprocessing on current, fairly critical sections of comments used by Haddock. I believe these are fairly useful and it would be a shame to see them go. I hope I haven't missed anything of high importance in a list above. When researching the topic, issues with Markdown quickly become apparent. Today, there are tens of different Markdown flavours: each company has different needs and each company interprets the vague original documentation in a way that's convenient to them. In these situations, topics, e-mails and blog posts like this one happen. There is a call to action from October 2012 at [12] but there seems to be absolutely no progress on any of the miraculous things mentioned in the post. As a result of that post, a W3C community was formed at [13]. It's clear that the community is inactive and no progress towards a solution was made. Having considered all information gathered here, I believe this would make a good GSoC project. There has been interest in this for Haskell since 2008 judging by the size of the last thread, it's clear that the community interest is high. In fact, it surprises me that this hasn't been done in previous years. The main issue that I see with using Markdown is the fact that we can't simply add a {-# HADDOCK Markdown #-} and let some parser rip through it. There are many issues that need to be resolved that I outlined above. This will no doubt result in a Markdown flavour suited to documenting Haskell rather than the wonderful, standardised Markdown that [13] is talking about. Is this different in any way from what GitHub or StackOverflow is doing? Introducing yet another flavour? In essence, no. For all Haskellers however, there would be a difference: this is a chance to use the pleasant-to-eye Markdown that many seem to like and use it for documentation. We have the chance to formalise it and make it work properly. It's not a perfect solution for every single person writing documentation out there but it's a good solution for Haskellers. Obviously, the ideal would be to have the wonderful, standardised, formalised Markdown that [13] seems to try and conjure and then extend that. Alas, we have no such luxury. As a closing paragraph, I would like to ask some questions. - - Is creating yet another Markdown flavour acceptable? I see no better solution: we'll have to take Markdown and fix it up to our needs. I'm sure most people are aware of the fairly famous Internet web-comic relating to standards [15]. We're however not trying to push a new standard - writing a proper standard, implementing it and then extending it for Haskell documentation is far too much for a single summer. - - Is there a mentor that would be willing to oversee the project? There's a fairly fresh ticket at [16] but there seems to be no indication of mentor-ship. I'm very interested in the project - it seems to hold high value for the community while not being completely out of scope for a student with a couple of months of Haskell experience, especially considering the large ``Getting up to scratch'' period. Thank you for your time. Links - ----- [1] - http://comments.gmane.org/gmane.comp.lang.haskell.cafe/104398 [2] - http://www.haskell.org/pipermail/haskell-cafe/2008-February/039846.html [3] - https://github.com/jgm/Markdown [4] - http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/104421 [5] - http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/104443 [6] - http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/104422 [7] - http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/104428 [8] - http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/104523 [9] - http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/104545 [10] - http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/104444 [11] - http://www.haskell.org/pipermail/haskell-cafe/2008-February/039939.html [12] - http://www.codinghorror.com/blog/2012/10/the-future-of-markdown.html [13] - http://www.w3.org/community/markdown/ [14] - http://blog.johantibell.com/2013/04/haskellorg-gsoc-ideas.html [15] - http://xkcd.com/927/ [16] - http://trac.haskell.org/haddock/ticket/244 - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRdt+WAAoJEM1mucMq2pqXspkP/j+SCyfho65/ji5OvNCEBFTb YLGC1YY/dk/zbb67gDDxmFtxw/UBGnUifliGUKhCy2Zzm6mwF7BI1U4NWhbR2nkQ VWkysqHMn1JM8uQNtkdXEe/KUi2KxcM+VtOkuCUQeF0mlHB7Hthlz58lGZHD+cMK EvhN0BGrL1/xnKwSexTSNexXIDCmvCW19jTxuR9uwPqVNVPMjWxO0wRVplnzcqyf S8jeG0+Q28S0Su/CxNUdUQ+pE2+FWksNY4a/d/8Tce9sFoTTXUEGAp6Nbgyi+uKd yS+AtBqvcsw7KYw03kQAB1qCD05dtc7ptp9ohjgwYY6jzgRMBrIRdDUvmqT6nPh1 MHgG9rkg9yj+gKhSlNiTZ7MCl/o/CkCtPG0rNtd6//QXDZlH3Xx6CpYKm/GnyAWh a2vX5ZX0urVIapFPPEpClMkleLbHfi2UWGVbC43jP0lvsZTMlr4uvwHzJ8N4e9AI 2MdK4yZes6b/DSH47FPdoAeYksUvwI0xpI5rpkLuoOh+O094gQVhm4yb+ceqF6CE VddqnHPPF4gn7NTeYh6fnsAvzCm5PYgyhEUySbkmlGHjAODtvs6uC9MW4zwYPeCp BvGTSsGx7DbtjHwDYQIzMI/oyjFXMVsQ/+bE+pzIo/tQJevXkILaZKYhBvUyAbE5 ypdJkLdQb8EcWGT5Cx0v =sTE0 -----END PGP SIGNATURE-----

7 12

Summer school on Applied Functional Programming at Utrecht University; deadline for registration May 15
by Doaitse Swierstra 02 May '13

02 May '13

Again we will teach an "Applied Functional Programming Summer in Haskell" school this year at Utrecht University. In the previous four occasions students were all very happy with the school and we plan to repeat this success this year. Among the intended audience are prospective master students who gained an interest in Functional Programming, e.g. by taking a general course on programming languages, and want to learn more about Haskell and its typical programming patterns. In previous years we have taught an introductory part (advanced bachelor level), an advanced part (beginning master level) and a shared part for both groups. Topics covered are, besides some examples of domain specific languages, also monads, monad transformers, arrows, parser combinators and self-analysing programs, underlying principles, type inferencing, etc. Half of the course time is spent on a larger programming exercise; you can also come with a problem of your own if you want, and get help from the Utrecht University Software Technology group in finding the proper Haskell idioms, tools and libraries, for solving it. Important links: -- our own page where we supply information based on questions asked http://www.cs.uu.nl/wiki/USCS/ -- on this page you can find the poster you can print and hang somewhere (why not your office door): Furthermore we ask for your cooperation to bring this announcement under the attention of potential participants. Best, Doaitse Swierstra, Atze Dijkstra and Johan Jeuring

2 1

GSoC - A Cabal Project
by Martin Ruderer 30 Apr '13

30 Apr '13

Hi, I am proposing a GSoC project on Cabal. It aims to open up the dependency solver for debugging purposes. The details are here: https://gist.github.com/mr-/7995081f89cff38e9443 I would really like to hear what you think about it. Best regards, Martin

3 2

ghc-7 -fPIC error
by Christopher Howard 30 Apr '13

30 Apr '13

Hey guys, this probably isn't the official GHC mailing list, but I've been trying to build and install a new GHC on an old RHEL5 system, as mentioned in my previous Cafe thread. I was able to make some good headway: I installed a ghc-6.8 binary, and then used that to build ghc-6.10 source, and then used that to build ghc-6.12 source. The idea is to keep going until I get to ghc-7.6. However, when I get to 7.0, my builds all eventually die with this error: quote: -------- /usr/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation R_X86_64_PC32 against `StgRun' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status -------- After this failed the first time, I tried adding -fPIC to SRC_HC_OPTS, GhcStage1HcOpts, and so forth in build.mk. But ultimately I get the same error. I tried skipping a version and building ghc-7.2 instead, but the same error pops up. -- frigidcode.com

3 2

Haskell compilation errors break the complexity encapsulation on DSLs
by Alberto G. Corona 30 Apr '13

30 Apr '13

Hi I ever was worried about the barrier that the complexity of the Haskell errors impose to users of DSLs. Many DSLs look so simple that even someone without knowledge of Haskell can make use of them for some domains. However when the program is compiled then al the monsters of the deep appear in the surface: polymorphisms, undefined instances, type errors reported in a line produced by a type assumption in another, etc. This is a problem for an industrial use of Haskell in the large scale. For obvious reasons. I would like to know 1) which techniques are used to minimize the problem 2) To suggest some kind of extension that would allow for example to add extra information to the error messages by the library developer.. For example, in http://hackage.haskell.org/packages/archive/control-monad-exception/0.10.3.… There is a nice documentation about two kind of errors that are frequent when using that library: *A type error of the form: * * No instance for (UncaughtException MyException) arising from a use of `g' at examples/docatch.hs:21:32-35 Possible fix: add an instance declaration for (UncaughtException MyException) In the expression: g ()* *is the type checker saying: * *"hey, you are trying to run a computation which throws a MyExceptionwithout handling it, and I won't let you" * *Either handle it or declare MyException as an UncaughtException<http://hackage.haskell.org/packages/archive/control-monad-exception/0.10.3.…>. * The question: Is it possible to develop a GHC extension that attach (or prepend) such an explanation to the ghc error? Or any other alternative that carry out the same functionality. -- Alberto.

3 5

Packages in distro mentioned on hackage?
by Magnus Therning 30 Apr '13

30 Apr '13

I've noticed that some packages have a mention of distributions that include it, and which version. How does a distro get to be added like that? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

2 1

Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
by Mateusz Kowalczyk 29 Apr '13

29 Apr '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/04/13 00:08, Joe Nash wrote: > Managed not to send to all: > > I think the reason markdown was the original suggestion was due to > the fact it is a very widespread and popular syntax, and as Johan > commented in the original thread, has to an extent "won". Having a > consistent, standard documentation syntax for Haskell is of course > important, but this project also seeks to standardise the syntax > beyond Haskell. I don't think standardising it beyond Haskell is the goal at all. I think that coming up with Markdown that doesn't repeat the mistakes of all the flavours out there is quite difficult in itself, but coming up with such Markdown AND making it making it flexible enough to be of any use with Haddock as is? I think it might be a little out of scope. Extending Haddock itself and providing a writer (and a new reader) for Pandoc will let you write Markdown if you please and then convert it to (and from) many of the formats supported by Pandoc. > It may be hedging our bets, as a lot could change and markdown > could suddenly fall from fame, but I believe the large variety of > opposing markup languages are failing to gain traction in > comparison and it is indeed a safe bet. While I don't think it will fall from fame overnight, it would be a shame to restrict people to just using Markdown because that's how all the extensions were implemented. > > If the flexibility of having it pandoc compatible is a desired > feature, can this not be achieved through implementing markdown for > haddock as well? Depending on what haddock specific features were > required to be added to the superset, it may require only minimal > changes to an existing markdown reader/writer in pandoc already. It can, but the restriction comment applies here as well. - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRfPllAAoJEM1mucMq2pqXaKAP/20x2549NvfJgib9oitm1Qn8 CCpGRHdSw4xlIh0pHUE1MKyiJrGGgchuUErN2CJBOKXPhn1fgCWFKJyfOhcPbyr7 2Tpb9t++9G9u0JtIb6/UQpgy6RDXQAqOUs78KxRx3DCb3rYuT5TNpr5ynS58T1+9 7eGQXeUQwhCkKZH6EuIF0qTwxPTsMOAT66oRVnaZJFl2+rOBcw8ZmxMsHnk3bX9t VAR+ySwN4FWce6QZwGU43tMwFHoIxsKrmZ3ZydQPfwdQjJjFjCdTaZhtEYS1Hcvu gg0yU5mjO/1frauqjgC/qo4ez/JrJr5aYHrV91o5S2w0Wl7jfUADAIRDLfhAnTe6 shbiPPBPJeY7EAt6JEytHBmlbwZLyE3zrB0GhlhyaKY344Z5k5Woq2u6zInPx5gi rtiWOUbuerBl8autaKwnPa9i+DSmRwMD8esFIyUMyCbPOMj89YirZtxWGD+ol71i cnBXV8DbX9aYfR8c8U3WNeR8FTOvxKYEC8cc3xErsustrwFlDKzlJD41VGHVZvjB qayuRIR/qMy+fy+8UrxzCFQA32gtZ/ZmjfyHWXHhe2DujThmTi95PtgpLHe1Y2Nh hYuGhj6fqzFvSvSJkE2uWlNPVIu7viBcF1bQEZz07OdYuvU+GbA8OK8q3EzCq+l3 l5uWSedwC4cdyNRxigFS =cgRe -----END PGP SIGNATURE-----

10 14