May 2013 - Haskell-Cafe

ANNOUNCE: grid 5.0
by Amy de Buitléir 04 May '13

04 May '13

I'm happy to announce a new major release of the grid package: http://hackage.haskell.org/package/grid https://github.com/mhwombat/grid/wiki (wiki) WHAT'S NEW: * Octagonal grids (just the thing for tiling that hyperbolic bathroom floor!) * Want to use the square grid, but need diagonal movement too? Try the octagonal grid. See the userguide for more information. * Updated the userguide to reflect the changes. ABOUT GRID: Grid provides tools for working with regular arrangements of tiles, such as might be used in a board game or self-organising map (SOM). Grid currently supports triangular, square, hexagonal, and octagonal tiles, with various 2D and toroidal layouts. If you need a tile shape or layout that isn't currently provided, please let me know. See Math.Geometry.Grid for an example of how to use the package. Suggestions for improvement are welcome.

1 0

Backward compatibility
by Adrian May 04 May '13

04 May '13

Hi All, Please don't interpret this as a rant: I'm just feeling a bit disappointed about probably having to give up on Haskell. Let's face it: this decision to change the default syntax in GHC7 means that right now Haskell looks about as stable as Ruby on Rails. I just tried to use Flippi. It broke because of the syntax change so I tried WASH. I couldn't even install it because of the syntax change. I persisted for a while but gave up because getPackageId doesn't exist in any form at all anymore. This was only the install script: what would WASH itself have in store for me to get my brain around? What are my choices here: 1) Revert to GHC6 or put pragmas and compiler switches everywhere, switch 2010 off globally with cabal or even make an alias of ghc: That means I'll gradually clash with people who decide ... 2) Convert all my code and a lot of other peoples' to the new syntax, thereby exacerbating the problem that ruled out 1. Either way, we're looking at a long period during which a large portion of the libraries will be incompatible with the other portion, and nobody will know which style to write. I don't know if or when WASH or any other library will convert, or even if I'd prefer that to happen sooner or later, because that would depend on when other libraries do and how I'd worked around it in the meantime. Altogether that means I can't sensibly decide to rely on any library, so I can't use Haskell. I'll just have to go back to fumbling around in XSL, PHP and the like. Is Haskell 2010 really so much better that it justifies this? I just saw that movie "The Words": the moral of the story is that you shouldn't try to change your mistakes. ... Apparently it's not only 2010. I now find that buildng the Haskell Platform wants GHC 7.4.2, not 7.4.1 because of the line "import Prelude" (if I remember rightly,) and even when I follow the rules precisely I still get several different deprecation warnings. The prelude is not exactly obscure. If you deprecate that you've broken everything. Is it really impossible to keep such a basic mantra meaningful from one minor version to the next? Java was fond of deprecating things in the early days, but when they said "deprecated" they didn't mean "switched off", let alone that it would lead to a syntax error. They just meant "not trendy anymore." It's a very common illusion to believe that the central thing in your life is also the central thing in everybody else's. That's why things like Norton take over your whole machine: those guys believe that the only reason you bought the computer was to fight viruses, because that's what most of the machines in their office were bought for. There seems to be something similar going on in the way Haskellers are expected to update all their code whenever GHC decide to issue an update. But in reality we have jobs of our own. I'd like to choose Haskell over XSL because I think it'll enable me to write web sites more efficiently, not because I want to forget all about my job and savour the brilliance of the latest Haskell version. But in reality I'm just sitting here waiting for the Platform to compile just in case it's the Ubuntu package's fault, but I know it won't help. I'll just get other problems instead. Reality is that the whole ecosytem is in disarray because of this lack of respect for backward compatibility. At least Rails can plead that it's relatively new, but Haskell has been around for over 20 years. I understand that progress has to be made, and it would be nice if people did just update all their code quickly so you could switch off old stuff and move on. But it's not hard to survey the code that's out there and see how much stuff you'd be breaking if you did. If it's not a lot, then switching it off to wake them up would be an acceptable compromise. But it looks to me as if a lot of very important stuff is still failing on the GHC from November 2010, so clearly things are going too fast. Adding new stuff is great, and sometimes the new stuff clashes with the old stuff. But how much of that deprecated stuff really *needed* to be switched off, and couldn't the new stuff have been designed so as not to force that? In principle this is the best language on the planet, but with all these version gotchas I don't know that I can use it anymore. What a tragedy. I can't even think of a suggestion as to how Haskell should try to get out of this mess now. Adrian.

30 80

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

Lambda Calculus question on equivalence
by Ian Price 04 May '13

04 May '13

Hi, I know this isn't perhaps the best forum for this, but maybe you can give me some pointers. Earlier today I was thinking about De Bruijn Indices, and they have the property that two lambda terms that are alpha-equivalent, are expressed in the same way, and I got to wondering if it was possible to find a useful notion of function equality, such that it would be equivalent to structural equality (aside from just defining it this way), though obviously we cannot do this in general. So the question I came up with was: Can two normalised (i.e. no subterm can be beta or eta reduced) lambda terms be "observationally equivalent", but not alpha equivalent? By observationally equivalent, I mean A and B are observationally equivalent if for all lambda terms L: (L A) is equivalent to (L B) and (A L) is equivalent to (B L). The definition is admittedly circular, but I hope it conveys enough to understand what I'm after. My intuition is no, but I am not sure how to prove it, and it seems to me this sort of question has likely been answered before. Cheers -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"

7 13

A three page web application in a tweet (in Haskell)
by Alberto G. Corona 03 May '13

03 May '13

Hi, Just to share my excitement with you: https://twitter.com/AGoCorona/status/329648864082677760 See the link in the tweet for an explanation Best Regards, -- Alberto.

1 0

Cabal / cabal-install: special installation
by Christopher Howard 02 May '13

02 May '13

Hi. This question dovetails off my previous thread. I described how I got ghc-7.6.3 installed from source onto an old RHEL5 machine. Naturally, I want to get cabal-install installed and start building great Hackage software. However, I have this quirk: I installed GHC to a special directory using ./configure --prefix=/specialdirectory/local. It is in my path, and works just fine. But when I try to build cabal-install, it claims it can't find Base, Cabal, and a few other things I know are installed. I know they are installed because I can see where they are installed and I can import stuff from them within GHCI. The result is the same whether I use the boot script, or whether I use runhaskell Setup configure (with or without a --prefix option). Is there another environment variable I need to set or something like that? (I need to emphasize that I do not want to install anything to $HOME, because my $HOME directory is shared across multiple systems.) -- frigidcode.com

1 0

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

a bug of 32bit ghc on mac ?
by Sray 02 May '13

02 May '13

hi all it seems i have met some bug on a MAC 32bit GHC version 7.4.2 to make long stroy short, my code is about parse a json file using aeson here is my code http://pastebin.com/0VcVhdvX and here is test data http://pastebin.com/PvtSvst5 and test steps save the code , and name it a.hs (or what you want) save the test data ,name it a.json (do not change its name) $ ghc a.hs -o a $ ./a what i get from the output is "fail" and when i run the command below for a few times $ runghc a.hs i even got some ok and some fail mixed together but i copy the code and compile it on my linux, everything goes fine, the output is "OK" i have run "uninstall-hs" and install a 64bit ghc, also goes fine i delete one line randomly chosen from my test data , got an ok roll back ,delete another line, also an ok... I just want to make sure is this my bug or a bug of ghc p.s. the reason using 32bit ghc is yesod, which has met another bug on 64bit mac ghc :( thanks sray

2 2

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

remote-build-reporting: cabal phoning home?!
by Ertugrul Söylemez 02 May '13

02 May '13

Hello there, could somebody please shed some light on the following line that appeared in my ~/.cabal/config? remote-build-reporting: anonymous The option doesn't seem to be documented anywhere, and I'm very nervous about undocumented "remote reporting" features. I expect cabal-install to communicate only to fetch the latest package index and to upload and download packages, the former only when i actually use the "upload" command. If it performs any other communication, please tell me how to disable it. In that case I'd also be interested in an explanation for why this was enabled in the first place. I certainly didn't enable it myself, because it would be a serious security breach in my case. Thank you. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.

2 2