April 2015 - Haskell-Cafe

Haskell Weekly News: Issue 322
by Semen Trygubenko / Семен Тригубен ко 21 May '15

21 May '15

New Releases 99 Haskell: A web service by Bram Hoskin Solve live Haskell coding problems based on H-99 in the browser to strengthen your understanding of the language. http://www.99haskell.org/ https://github.com/bramgg/99haskell/ Magic Cookies A commercial Android game is released that is written in Haskell using SDL2 for multimedia and the Arrowized Functional Reactive Programming DSL Yampa. The authors had to "escape their functional comfort zones and come up with smarter abstractions that mutable reality and performance demand". The game consists of 2K lines of code, of which 1K is game specific and 400 are Yampa code. The most complex parts were certain Yampa constructs (arrow-based, with lots of tupling/untupling). http://keera.co.uk/blog/2015/03/19/magic-cookies-released-google-play/ https://play.google.com/store/apps/details?id=uk.co.keera.games.magiccookies https://github.com/keera-studios/keera-hails https://github.com/ivanperez-keera/Yampa Discussion Finding a GHC bug by Neil Mitchell A write up of the hunt for bug #10176 http://neilmitchell.blogspot.it/2015/03/finding-ghc-bug.html https://ghc.haskell.org/trac/ghc/ticket/10176 What are your most persuasive examples of using Quickcheck? Quickcheck helped many people in a number of areas — compiler optimisations, date/time validation, regular expressions, encoding/decoding, topological sort, fuzzing HTTP APIs and even exhibiting classical voting paradox! Apart from the obvious benefit of helping to find big juicy bugs as well as valid but potentially harmless tiny bugs in edge cases that no-one cares about, Quickcheck can help attain enlightenment in the sense that spelling out Quickcheck properties in itself can be rewarding because this can reveal assumptions that have been made without realizing it. Roman Cheplyaka reminds us about SmallCheck and that it should be used instead of Quickcheck when one has a good idea about what depth is needed and when exhaustive search at that depth is affordable. https://www.reddit.com/r/haskell/comments/308ps6/what_are_your_most_persuas… http://stackoverflow.com/questions/20092191/how-much-should-one-control-the… What is the difference between free monads and free monoids? A comment by Edward Kmett. https://www.reddit.com/r/haskell/comments/2znhjk/what_is_the_difference_bet… Type-Checked Pseudo-Code Tom Ashworth argues that Haskell is an excellent tool for fleshing out ideas and prototyping solutions, and that it makes one generalize and shake out many conceptual bugs before concepts become code. https://phuu.net/2015/03/24/type-checked-pseudo-code.html Where does GHC spend most of it's time during compilation? Optimisation and codegen, it seems. Also, GHC compilation times went up substantially from version 7.6 to 7.8. https://www.reddit.com/r/haskell/comments/309430/where_does_ghc_spend_most_… Quotes of the Week "Haskell doesn't feel like code. It feels like a language for thinking in: it's expressive, terse and simple, especially as type-checked pseudo-code." (Tom Ashworth) https://phuu.net/2015/03/24/type-checked-pseudo-code.html "Well that's not in the spec. If you want to change the requirements you have to renegotiate the contract =P" (sccrstud92) https://www.reddit.com/r/haskell/comments/2zxekg/while_learning_haskell_i_m… "Unit tests are double entry bookkeeping" (EvanDaniel) https://www.reddit.com/r/haskell/comments/308ps6/what_are_your_most_persuas… augustss> "Well, type checking is worst case exponential…" barsoap> "Yep. That's also the reason why I don't really get the insistence of dependently-typed languages to have to be total at the type level: I don't care whether type-checking takes ten or infinitely many years, both figures are too large." https://www.reddit.com/r/haskell/comments/309430/where_does_ghc_spend_most_… "Our prophet Djistra said that a testing shows the presence, not the absence of bugs … <snip> … Today Djistra would have been stoned under a myriad of inutile unit tests that people perform for a sense of false security, in a sort of superstitious sacrificial ritual, a waste of time to convince himself and others that his software is right." (agocorona) https://www.reddit.com/r/haskell/comments/308ps6/what_are_your_most_persuas… "You might also consider these sorts of infelicities as teachable moments" (ericpashman) https://www.reddit.com/r/haskell/comments/2zxekg/while_learning_haskell_i_m… "Nice gradual progression there. Big O notion, smoothly divided into 3 easy parts, then bam, Coyoneda. =) I approve. [Yes, I realize it is a bag of topics, not a course outline, but it still grabbed me.]" (edwardkmett) https://www.reddit.com/r/haskell/comments/2zqyes/we_released_a_video_librar…

1 4

Re: [Haskell-cafe] Static executables in minimal Docker containers
by Greg Weber 17 May '15

17 May '15

Haskell is not that great at producing statically linked libraries independent of the OS. The issue you are running into would likely show up in another non-ubuntu image (or even possibly a different version of an ubuntu image), so you could probably use a Fedora image that has tracing. How are you addressing the linker warning about needing a particular glibc version at runtime? On Mon, Apr 13, 2015 at 3:28 AM, Sharif Olorin <sharif.olorin(a)gmail.com> wrote: > Unfortunately, strace and ltrace aren't available in that Docker image, >> but it's a good idea to see if I can get them running there somehow. >> > > Failing that, you might be able to get useful information of the same kind > by running docker (the server, not the `docker run` command) under perf[0] > and then running your busybox container. It should at least give you an > idea of what it's doing when it explodes. > > Sharif > > [0]: https://perf.wiki.kernel.org/index.php/Tutorial > > -- > You received this message because you are subscribed to the Google Groups > "Commercial Haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to commercialhaskell+unsubscribe(a)googlegroups.com. > To post to this group, send email to commercialhaskell(a)googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/commercialhaskell/86ca2603-37f2-4645-9cd2… > <https://groups.google.com/d/msgid/commercialhaskell/86ca2603-37f2-4645-9cd2…> > . > > For more options, visit https://groups.google.com/d/optout. >

10 15

[ANN] relational-record - relational-algebraic query building DSL
by Kei Hibino 16 May '15

16 May '15

Hello everybody, I am happy to announce relational-record library and its project page. relational-record is domain specific language for type-safe SQL query building, and database access API with compile time schema generators. Code is avaiable on github and hackage. https://github.com/khibino/haskell-relational-record/ http://hackage.haskell.org/package/relational-record/ Tutorial, examples and documentations are available from project page links. http://khibino.github.io/haskell-relational-record/ Supported features are below, * Type safe query building. * Composable query. * Outer join. * Aggregation. * Compile time compile code generation along with RDBMS schema. * Schema support of ProsgreSQL, SQLite3, MySQL, IBM DB2, MicroSoft SQL Server, and Oracle. Any comments, any questions about this library are welcome. -- Kei Hibino ex8k.hibino at gmail.com https://github.com/khibino/

6 12

all for Contributions - Haskell Communities and Activities Report, May 2015 edition (28th edition)
by Mihai Maruseac 13 May '15

13 May '15

Dear all, We would like to collect contributions for the 28th edition of the ============================================================ Haskell Communities & Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 17 May 2015 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) ============================================================ This is the short story (one extra point to the story added from previous editions): * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell us, so that we can contact the project leaders and ask them to submit an entry. * **NEW**: If you are working on a project that is looking for contributors, please write a short entry and submit it, mentioning that your are looking for contributors. The final report might have an index with such projects, provided we get enough such submissions. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the previous edition --- you will find interesting projects described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Mihai Maruseac and Alejandro Serrano Mena FAQ: Q: What format should I write in? A: The required format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/05-2015/template.tex There is also a LaTeX style file at http://haskell.org/communities/05-2015/hcar.sty that you can use to preview your entry. If you do not know LaTeX, then use plain text. If you modify an old entry that you have written for an earlier edition of the report, you should soon receive your old entry as a template (provided we have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include Haskell code? A: Yes. Please use lhs2tex syntax (http://www.andres-loeh.de/lhs2tex/) The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg or .png format, then, PNG being preferred for simplicity. Q: Should I send files in .zip archives or similar? A: No, plain file attachements are the way. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or "historic" overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also simply ask us. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use HCAR to ask for more contributors to your project, it is a good way to gain visibility and traction. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell us that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. Q: Will I get confirmation if I send an entry? How do I know whether my email has even reached its destination, and not ended up in a spam folder? A: Prior to publication of the final report, we will send a draft to all contributors, for possible corrections. So if you do not hear from us within two weeks after the deadline, it is safer to send another mail and check whether your first one was received. -- Mihai Maruseac (MM) "If you don't know, the thing to do is not to get scared, but to learn." -- Atlas Shrugged.

1 1

status of deb.haskell.org?
by Jeremy 08 May '15

08 May '15

The haskell status page says that deb.haskell.org has been down since mid-February. Are there any plans to bring it back up? -- View this message in context: http://haskell.1045720.n5.nabble.com/status-of-deb-haskell-org-tp5768430.ht… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

3 3

Cannot run GHC-7.10.1 tests
by Jeremy Henty 07 May '15

07 May '15

I successfully built GHC-7.10.1 but I cannot run the tests (at least not when I follow the instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests) "make fast" fails like this: ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final fast make[1]: *** No rule to make target `fast'. Stop. make: *** [fast] Error 2 "make testfast" fails in exactly the same way, except that the broken make target is "testfast" instead of fast. "make test" and "make fulltest" fail like this: make -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt fast make[1]: Entering directory `/data/build.d/6.8/ghc-7.10.1/testsuite/tests' ../mk/boilerplate.mk:168: ../mk/ghcconfig_data_build.d_6.8_ghc-7.10.1_inplace_bin_ghc-stage2.mk: No such file or directory ../mk/ghc-config "/data/build.d/6.8/ghc-7.10.1/inplace/bin/ghc-stage2" >"../mk/ghcconfig_data_build.d_6.8_ghc-7.10.1_inplace_bin_ghc-stage2.mk"; if [ $? != 0 ]; then rm -f "../mk/ghcconfig_data_build.d_6.8_ghc-7.10.1_inplace_bin_ghc-stage2.mk"; exit 1; fi /bin/sh: ../mk/ghc-config: cannot execute binary file make[1]: *** [../mk/ghcconfig_data_build.d_6.8_ghc-7.10.1_inplace_bin_ghc-stage2.mk] Error 1 make[1]: Leaving directory `/data/build.d/6.8/ghc-7.10.1/testsuite/tests' make: *** [test] Error 2 Interestingly, for GHC-7.8.4 "make fast" and "make testfast" fail in exactly the same way but "make test" and "make fulltest" both work. So, how do I test GHC-7.10.1 ? Regards, Jeremy Henty

3 5

Re: [Haskell-cafe] Improvements to package hosting and security
by Mathieu Boespflug 05 May '15

05 May '15

This is a valid concern. One that I should have addressed explicitly in the proposal. Git is fairly well supported on Windows these days and installs easily. It could conceivably be included as part of MinGHC. There are many alternatives, but I doubt we'll need them: statically linking a C implementation (libgit2 or another), or a simple native implementation of the git protocol (the protocol is quite straightforward and is documented) and basic disk format. The same is true about GnuPG, via gpg4win, though note that under this proposal GnuPG wouldn't be a requirement for `cabal update` to work. Just an additional optional dependency which you'll want to have installed if you want to protect yourself from the attacks listed in the proposal. By the way, one side note about this Git proposal: it sides steps the discussion around how to add SSL support to cabal-install entirely. Since Git understands (among others) HTTPS natively, so we can outsource our support for that to Git. In any case SSL no longer becomes a necessity for protecting against MITM (the commit signing takes care of that), only a nice-to-have for privacy. On 28 April 2015 at 19:46, <radix(a)twistedmatrix.com> wrote: > To me, the elephant in the room is how the dependency on Git will be > handled. I'm not a Windows user, but how much more painful will it be to set > up a Haskell environment on Windows with a new dependency on Git? Will users > need to install it separately, or do you suggest embedding Git into the > relevant tools? Should the Haskell Platform bundle it? What about MinGHC? > Oh, and I guess the same question can be asked about GnuPG. > > I personally use a Mac and Homebrew, so it's pretty easy for me to install > those dependencies, and I'm sure the same is true on Linux. But also, not > everyone uses Homebrew (in fact, I'm sure most programmers on Macs don't use > it), so it's also worth considering whether the requisite tools should be > embedded in the "GHC for Mac OS X" distribution. > > On Linux this probably isn't an issue because pretty much everyone has a > decent dependency-tracking package manager. > > I don't know if you care personally about these issues, but I think any > proposal which introduces new dependencies to the core development > environment of Haskell should take it into consideration. Very few people > have Git and GPG already installed, and I think the new-user experience > should be considered, and I'm surprised nobody has mentioned it in this > entire thread (unless I missed it). > > -- radix (Christopher Armstrong) > > P.S. I'm very excited to see this work, including the emphasis on using the > well-researched TUF. Thanks to you and other people working on this. :) > > On Tuesday, April 28, 2015 at 5:07:56 AM UTC-5, Mathieu Boespflug wrote: >> >> Hi all, >> >> last week, I found some time to write up a very simple proposal that >> addresses the following goals simultaneously: >> >> - maintain a difficult to forge public audit log of Hackage updates; >> - make downloads from Hackage mirrors just as trustworthy as >> downloading from Hackage itself; >> - guarantee that `cabal update` is always pulling the freshest package >> index (called "snapshots" in the proposal), and detect when this might >> not be the case; >> - implement the first half of TUF (namely the index signing part >> discussed in Duncan's blog post, not the author package signing part) >> with fewer metadata files and in a way that reuses existing tooling; >> - get low-implementation-cost, straightforward and incremental `cabal >> update`. >> >> After a preliminary review from a few colleagues and friends in the >> community, here is the proposal, in the form of Commercial Haskell >> wiki page: >> >> >> https://github.com/commercialhaskell/commercialhaskell/wiki/Git-backed-Hack… >> >> The design constraints here are: >> >> - stay backwards compatible where the cost for doing so is low. >> - reuse existing tooling and mechanisms, especially when it comes to >> key management, snapshot identity, and distributing signatures. >> - Focus on the above 5 goals only, because they happen to all be >> solvable by changing a single piece of mechanism. But strive to reuse >> whatever mechanism others are proposing to solve other goals (e.g. >> certification of provenance using author package signing, as Chris >> Done has already proposed). >> >> To that effect, the tl;dr is that I'm proposing that we just use Git >> for maintaining the Hackage package index, that we use Git for >> synchronizing this locally, and that we use Git commit signatures for >> implementing the first half of TUF. The Git tooling currently assumes >> GnuPG keys for signatures, so I'm proposing that we use GnuPG keys for >> signing, and that we manage key revocation and any trust delegation >> between keys using GnuPG and its existing infrasture. >> >> I estimate the total effort necessary here to be the equivalent of 5-6 >> full time days overall. However, I have not pooled the necessary >> resources to carry that out yet. I'd like to get feedback first before >> going ahead with this, but in meantime, >> >> ** if there are any volunteers that would like to signal their intent >> to help with the implementation effort then please add your name at >> the bottom of the wiki page. ** >> >> Best, >> >> Mathieu >> >> On 18 April 2015 at 20:11, Michael Snoyman <mic...(a)snoyman.com> wrote: >> > >> > >> > On Sat, Apr 18, 2015 at 12:20 AM Bardur Arantsson >> > <sp...(a)scientician.net> >> > wrote: >> >> >> >> On 17-04-2015 10:17, Michael Snoyman wrote: >> >> > This is a great idea, thank you both for raising it. I was discussing >> >> > something similar with others in a text chat earlier this morning. >> >> > I've >> >> > gone ahead and put together a page to cover this discussion: >> >> > >> >> > >> >> > >> >> > https://github.com/commercialhaskell/commercialhaskell/blob/master/proposal… >> >> > >> >> > The document definitely needs more work, this is just meant to get >> >> > the >> >> > ball >> >> > rolling. As usual with the commercialhaskell repo, if anyone wants >> >> > edit >> >> > access, just request it on the issue tracker. Or most likely, send a >> >> > PR >> >> > and >> >> > you'll get a commit bit almost magically ;) >> >> >> >> Thank you. Just to make sure that I understand -- is this page only >> >> meant to cover the original "strawman proposal" at the start of this >> >> thread, or...? >> >> >> >> Maybe you intend for this to be extended in a detailed way under the >> >> "Long-term solutions" heading? >> >> >> >> I was imagining a wiki page which could perhaps start out by collecting >> >> all the currently identified possible threats in a table, and then all >> >> "participants" could perhaps fill in how their suggestion addresses >> >> those threats (or tell us why we shouldn't care about this particular >> >> threat). Of course other relevent non-threat considerations might be >> >> relevant to add to such a table, such as: how prevalent is the >> >> software/idea we're basing this on? does this have any prior >> >> implementation (e.g. the append-to-tar and expect that web servers will >> >> behave sanely thing)? etc. >> >> >> >> (I realize that I'm asking for a lot of work, but I think it's going to >> >> be necessary, at least if there's going to be consensus and not just a >> >> de-facto "winner".) >> >> >> >> >> > >> > Hi Bardur, >> > >> > >> > I don't think I have any different intention for this page than you've >> > identified. In fact, I thought that I had clearly said exactly what you >> > described when I said: >> > >> >> There are various ideas at play already. The bullets are not intended >> >> to >> >> be full representations of the proposals, but rather high level >> >> summaries. >> >> We should continue to expand this page with more details going forward. >> > >> > If this is unclear somehow, please tell me. But my intention absolutely >> > is >> > that many people can edit this page to add their ideas and we can flesh >> > out >> > a complete solution. >> > >> > Michael >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskel...(a)haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskel...(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

7 14

Improvements to package hosting and security
by Michael Snoyman 03 May '15

03 May '15

Many of you saw the blog post Mathieu wrote[1] about having more composable community infrastructure, which in particular focused on improvements to Hackage. I've been discussing some of these ideas with both Mathieu and others in the community working on some similar thoughts. I've also separately spent some time speaking with Chris about package signing[2]. Through those discussions, it's become apparent to me that there are in fact two core pieces of functionality we're relying on Hackage for today: * A centralized location for accessing package metadata (i.e., the cabal files) and the package contents themselves (i.e., the sdist tarballs) * A central authority for deciding who is allowed to make releases of packages, and make revisions to cabal files In my opinion, fixing the first problem is in fact very straightforward to do today using existing tools. FP Complete already hosts a full Hackage mirror[3] backed by S3, for instance, and having the metadata mirrored to a Git repository as well is not a difficult technical challenge. This is the core of what Mathieu was proposing as far as composable infrastructure, corresponding to next actions 1 and 3 at the end of his blog post (step 2, modifying Hackage, is not a prerequesite). In my opinion, such a system would far surpass in usability, reliability, and extensibility our current infrastructure, and could be rolled out in a few days at most. However, that second point- the central authority- is the more interesting one. As it stands, our entire package ecosystem is placing a huge level of trust in Hackage, without any serious way to vet what's going on there. Attack vectors abound, e.g.: * Man in the middle attacks: as we are all painfully aware, cabal-install does not support HTTPS, so a MITM attack on downloads from Hackage is trivial * A breach of the Hackage Server codebase would allow anyone to upload nefarious code[4] * Any kind of system level vulnerability could allow an attacker to compromise the server in the same way Chris's package signing work addresses most of these vulnerabilities, by adding a layer of cryptographic signatures on top of Hackage as the central authority. I'd like to propose taking this a step further: removing Hackage as the central authority, and instead relying entirely on cryptographic signatures to release new packages. I wrote up a strawman proposal last week[5] which clearly needs work to be a realistic option. My question is: are people interested in moving forward on this? If there's no interest, and everyone is satisfied with continuing with the current Hackage-central-authority, then we can proceed with having reliable and secure services built around Hackage. But if others- like me- would like to see a more secure system built from the ground up, please say so and let's continue that conversation. [1] https://www.fpcomplete.com/blog/2015/03/composable-community-infrastructure [2] https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing… [3] https://www.fpcomplete.com/blog/2015/03/hackage-mirror [4] I don't think this is just a theoretical possibility for some point in the future. I have reported an easily trigerrable DoS attack on the current Hackage Server codebase, which has been unresolved for 1.5 months now [5] https://gist.github.com/snoyberg/732aa47a5dd3864051b9

14 42

Re: [Haskell-cafe] Improvements to package hosting and security
by Mathieu Boespflug 03 May '15

03 May '15

Define "superior"? As argued in the proposal, the salient features are that by devolving practically everything to Git+GPG, we end up with less code to maintain in our tooling, less code to maintain in our infrastructure (namely hackage-server), a more reliable service, and a smaller chance of buggering up security related activities (such as signing and managing trust). We're not introducing dependencies on dynamically linked system libraries that makes tooling hard to distribute. We're not asking users to install anything new that isn't already a staple of most developer desktops, and not asking users, Hackage trustees and Hackage admins to manage new identities with new key formats that aren't the existing ones they already have (namely GnuPG). Further, users can still opt-out of signature verification if they want to. Compared to alternative approaches - there has been a proposal to get incremental updates à la Git differently by growing (potentially infinitely) the end of a tar file served by the server via HTTP. This means grabbing the history for new package revisions cannot be opted out from easily. With Git, you get this for free, since users can `git clone --depth=1` and still be able to do a `git pull` later and verify signatures. You further get the advantage of being able to directly mine the history of changes, using standard tools, something that can't be done directly on the tar file without more custom tooling (or post conversion to Git). On 28 April 2015 at 23:33, Bardur Arantsson <spam(a)scientician.net> wrote: > On 28-04-2015 23:09, Mathieu Boespflug wrote: > > [removing erroneous haskell-cafe(a)googlegroups.com from To list.] > > (I'm not the person you're responing to. From the mail-headers, I can't > see the person(s) you're responding to, but so be it.) > > Do you have evidence that your approach is superior, and could you > please cite it? [Or, alternatively provide negative evidence for > $OTHER_APPROACH.]) > > Regards, > > -- > You received this message because you are subscribed to the Google Groups > "Commercial Haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to commercialhaskell+unsubscribe(a)googlegroups.com. > To post to this group, send email to commercialhaskell(a)googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/commercialhaskell/mhouaf%24it2%241%40ger.… > . > For more options, visit https://groups.google.com/d/optout. >

5 6

Is it acceptable if Applicative behave not like a Monad
by Alexey Uimanov 02 May '15

02 May '15

Hello, I have such a question: assume you have some type `T` which has Applicative and Monad instances. Is it ok if code like this: foo :: Int -> T String bar :: Int -> T Int (,) <$> foo 10 <*> bar "20" behaves not like this code: foobar = do x <- foo 10 y <- bar "20" return (x, y) The word "behaves" I mean not just returning value but the effect performed also.

10 10