From rickdzekman at gmail.com Thu Oct 1 00:46:30 2015 From: rickdzekman at gmail.com (Rick Dzekman) Date: Thu, 1 Oct 2015 10:46:30 +1000 Subject: [Haskell-cafe] SURVEY: How do you use Hackage? Message-ID: I recently posted some criticisms of the Haskell User Experience on my site. Afterwards Greshom B. and I had a brief chat over email about any recommendations I had. I suggested that the first step in improving the User Experience of any product is research. I think Hackage is something that needs looking at and we agreed that getting some qualitative data was really important. This survey is an attempt to find out how different people use Hackage. If you're able to participate in the survey, you can either submit a response on this webform or submit a response on Reddit . If you have any questions or comments please feel free to email: haskell-usability-survey at haskell.org Thanks, Rick Dzekman -------------- next part -------------- An HTML attachment was scrubbed... URL: From achudnov at gmail.com Thu Oct 1 00:51:09 2015 From: achudnov at gmail.com (Andrey Chudnov) Date: Wed, 30 Sep 2015 20:51:09 -0400 Subject: [Haskell-cafe] =?utf-8?q?ANNOUNCE=3A_Megaparsec_=E2=80=93_an_impr?= =?utf-8?q?oved_and_actively_maintained_fork_of_Parsec?= In-Reply-To: References: <560ADBAF.3060006@artyom.me> <560AEA9E.9050502@gmail.com> <4A1D0740-3F67-41F9-9766-F9E06311D93B@gmail.com> Message-ID: <560C837D.8060404@gmail.com> I think the easiest way might be adding Mark Karpov (the author of megaparsec) as the maintainer of parsec and let him run with it. (Assuming he would like that too.) As a package trustee, Carter, you probably have the best chance of making that happen. Although, I'd love to hear from the 4 (sic!) parsec maintainers regarding the state of the library, their commitment to maintenance and their opinion of megaparsec. Request for comment from Antoine Latter, Derek Elkins, Ian Lynagh and Roman Cheplyaka. On 09/30/2015 03:32 PM, Carter Schonwald wrote: > Agreed. Great work, and if we can find a path to this being a > foundation for or inspiring parsec 4.0, that would probably be a net > win for everyone. > > On Wednesday, September 30, 2015, Nicola Gigante > > wrote: > > > > Il giorno 29/set/2015, alle ore 21:46, Andrey Chudnov > > ha scritto: > > > > (Artyom, I hope you can forward the following to the original > author and, ideally, have them subscribe to the mailing list) > > > > As a heavy user of parsec, I have to say this is simply awesome. > I've read through the announcement and the changelog, and I have > to say the changes seem to be spot on and scratch so many old > itches I have personally struggled with when using parsec. I'm at > the point where I am seriously considering porting all my code to > megaparsec; however, lack of compatibility with GHC <7.10 is a bit > of a deal-breaker at this point. > > > > I'd like to discuss the decision to fork parsec. Now, I'm not > judging: as long as the license permits it, whether to fork or not > is really up to the forker. > > > > However, it seems the author of megaparsec would like it to > become the new standard parsing library (see "How you can help"). > I'd like that too. However, I don't think that forking is the best > way to achieve that. Of the two reasons that were given here, the > first (stagnant development and maintenance) is a good reason to > become either a co-maintainer, or a new maintainer. There seems to > be a pretty smooth process for that now, and it doesn't raise any > eyebrows when someone requests to be the new maintainer having > good reasons for it (like willingness to contribute time and > effort to the package). > > > > The second reason is backwards compatibility. It's true the > changes might break some code, but that's why we have major > versions. And the overall architecture and interface is still in > line with parsec. So, to me it makes perfect sense to call > megaparsec a parsec-4.0.0.0 and get some continuity from the older > library. That way megaparsec becomes the default just by inheritance. > > > > So, if the author of megaparsec is open to becoming a maintainer > of parsec, I'm sure the Hackage Trustees would be willing to help. > If not, I'm personally willing to champion that. > > > > /Andrey > > > > +1 > > Megaparsec seems awesome to me, especially the monad transformers > issue > is exactly what I missed in using Parsec. > > As someone that often teaches a bit of haskell, I would also like > it to become > "Parsec 4.0? if that?s possible. That would save a lot of > boilerplate in docs and > tutorials about why I?m talking about megaparsec while it seems > the most used > library is parsec and explain the reasons of the fork etc.. every > time. > > To megaparsec?s author: great work! > > > Bye, > Nicola > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Thu Oct 1 04:37:48 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 1 Oct 2015 06:37:48 +0200 Subject: [Haskell-cafe] =?utf-8?q?ANNOUNCE=3A_Megaparsec_=E2=80=93_an_impr?= =?utf-8?q?oved_and_actively_maintained_fork_of_Parsec?= In-Reply-To: <560C837D.8060404@gmail.com> References: <560ADBAF.3060006@artyom.me> <560AEA9E.9050502@gmail.com> <4A1D0740-3F67-41F9-9766-F9E06311D93B@gmail.com> <560C837D.8060404@gmail.com> Message-ID: <20151001043748.GB2476@casa.casa> On Wed, Sep 30, 2015 at 08:51:09PM -0400, Andrey Chudnov wrote: > I think the easiest way might be adding Mark Karpov (the author of > megaparsec) as the maintainer of parsec and let him run with it. (Assuming > he would like that too.) As a package trustee, Carter, you probably have the > best chance of making that happen. > > Although, I'd love to hear from the 4 (sic!) parsec maintainers regarding > the state of the library, their commitment to maintenance and their opinion > of megaparsec. > > Request for comment from Antoine Latter, Derek Elkins, Ian Lynagh and Roman > Cheplyaka. Maybe they aren't subscribed to the ML, courtesy ping to Antoine Latter. From gershomb at gmail.com Thu Oct 1 05:04:41 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 1 Oct 2015 01:04:41 -0400 Subject: [Haskell-cafe] Candidate Haskell Platform 7.10.2-a for use with OS X El Capitan Message-ID: The new OS X El Capitan release (out today) broke the method that Haskell Platform uses to install itself, due to new security features. In fact, if you upgrade your OS, you are also likely to (slightly) break your existing install. There is now a candidate new installer, available at http://downloads.haskell.org/~platform/7.10.2/Haskell%20Platform%207.10.2-a1%2064bit-unsigned.pkg Note that it is unsigned and you will have to give it permission to run, the usual way, by right clicking on it, and choosing "open" then explicitly allowing it to run. The central difference between this and the prior installer is just that it installs symlinks to ghc tools in the /usr/local tree rather than the /usr tree since the latter is now off limits due to new OS X security features. If you have a prior install and just want to "fix" it after your OS upgrade, no need to reinstall the whole platform. Just download and run the activate-hs shellscript from here: https://github.com/mzero/haskell-platform/blob/master/hptool/os-extras/osx/bin/activate-hs Again, after a bit more testing we'll get this signed and released as the new official platform installer for OS X, but in the meantime, I wanted to make sure people were in the loop. Regards, Gershom From roma at ro-che.info Thu Oct 1 07:17:36 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 1 Oct 2015 10:17:36 +0300 Subject: [Haskell-cafe] =?utf-8?q?ANNOUNCE=3A_Megaparsec_=E2=80=93_an_impr?= =?utf-8?q?oved_and_actively_maintained_fork_of_Parsec?= In-Reply-To: <560C837D.8060404@gmail.com> References: <560ADBAF.3060006@artyom.me> <560AEA9E.9050502@gmail.com> <4A1D0740-3F67-41F9-9766-F9E06311D93B@gmail.com> <560C837D.8060404@gmail.com> Message-ID: <560CDE10.8090201@ro-che.info> On 10/01/2015 03:51 AM, Andrey Chudnov wrote: > I think the easiest way might be adding Mark Karpov (the author of > megaparsec) as the maintainer of parsec and let him run with it. > (Assuming he would like that too.) As a package trustee, Carter, you > probably have the best chance of making that happen. > > Although, I'd love to hear from the 4 (sic!) parsec maintainers > regarding the state of the library, their commitment to maintenance and > their opinion of megaparsec. > > Request for comment from Antoine Latter, Derek Elkins, Ian Lynagh and > Roman Cheplyaka. Indeed four of us happen to have hackage upload rights for parsec, but I believe the only actual maintainer is Antoine. For what it's worth, I've been long dissatisfied with the state of parsec and would love to see it evolve. But let's hear from Antoine. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ollie at ocharles.org.uk Thu Oct 1 09:01:10 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 01 Oct 2015 09:01:10 +0000 Subject: [Haskell-cafe] Merging the OpenGLRaw and gl packages In-Reply-To: References: Message-ID: On Wed, Sep 30, 2015 at 6:38 PM Sven Panne wrote: > IMHO using pattern synonyms vs. plain old Haskell values is to a large > part just bikeshedding, at least in the trivial case at hand where we talk > about simple integral values. It basically boils down to the question: Is > > foo x = case x of > GL_BAR -> expr1 > GL_BAZ -> expr2 > _ -> expr3 > > really so much better than > > foo x > | x == GL_BAR = expr1 > | x == GL_BAZ = expr2 > | otherwise = expr3 > Yes, because the first approach is an expression that you can use anywhere. Sure, there's little difference when you do it at the "top" of a function definition, as you're doing. However, it's a lot more significant if you want to do something like: foo x = doSomething (case x of ...) Without pattern synonyms, you either have foo x = doSomething x' where x' | x == ... = ... or {-# LANGUAGE MultiWayIf #-} foo x = doSomething (if | x == ... -> ...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aditya.siram at gmail.com Thu Oct 1 14:51:28 2015 From: aditya.siram at gmail.com (aditya siram) Date: Thu, 1 Oct 2015 09:51:28 -0500 Subject: [Haskell-cafe] 7.10.2 : Compilation slowdown. In-Reply-To: References: Message-ID: I unfortunately don't have time to pare it down to a small example, but fortunately I found that the latest HList on Hackage exhibits the same approximate behavior. When building the tests for HList-0.4.1.0, on 7.10.2 the module `Properties.LengthDependentSplice` ( http://hackage.haskell.org/package/HList-0.4.1.0/src/examples/Properties/LengthDependentSplice.hs) takes 2m30secs to compile. The same file takes ~50secs on 7.8.4. Thanks! -deech On Wed, Sep 30, 2015 at 6:22 PM, David Kraeutmann wrote: > Can you post a minimal example that exhibits the compile time increase? > > On Thu, Oct 1, 2015 at 12:25 AM, aditya siram > wrote: > > I'm not using any -O* flags and I'm not using Template Haskell. Not sure > if > > this means anything but I do have the context-stack set to 220. > > > > Thanks! > > -deech > > > > On Wed, Sep 30, 2015 at 8:47 AM, Carter Schonwald > > wrote: > >> > >> Have you checked how changing the optimization level affects build > times? > >> Are you using template Haskell? > >> > >> > >> On Tuesday, September 29, 2015, aditya siram > >> wrote: > >>> > >>> Hi all, > >>> Since upgrading to 7.10.2 from 7.8.4 I'm seeing a significant increase > in > >>> compilation time. I understand this is a known issue but since I'm > seeing > >>> something like a 3x slowdown but not across the board, I thought I'd > ask. > >>> > >>> Compilation time for the library I'm writing has remained about the > same. > >>> I am seeing the slowdown when compiling executables that use the > library. > >>> There are no other dependencies except base so I'm guessing it > something in > >>> my library causing the issue. > >>> > >>> I lean heavily on the FFI, OverlappingInstances and HList style > >>> programming in my library which leads me to believe that one of these > is > >>> causing it. I am seeing no difference in compilation speeds by adding > the > >>> per instance OVERLAPPING pragmas. > >>> > >>> Can anyone advise or instruct me on how to profile the compiler? > >>> > >>> Thanks! > >>> -deech > >>> > >>> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Thu Oct 1 16:54:42 2015 From: svenpanne at gmail.com (Sven Panne) Date: Thu, 1 Oct 2015 18:54:42 +0200 Subject: [Haskell-cafe] Merging the OpenGLRaw and gl packages In-Reply-To: References: Message-ID: 2015-10-01 11:01 GMT+02:00 Oliver Charles : > [...] However, it's a lot more significant if you want to do something > like: > > foo x = doSomething (case x of ...) > > Without pattern synonyms, you either have > > foo x = doSomething x' > where x' | x == ... = ... > > or > > {-# LANGUAGE MultiWayIf #-} > > foo x = doSomething (if | x == ... -> ...) > Or simply in plain old Haskell (basically the desugaring of the multi-way-if): foo x = doSomething (case () of _ | x == gl_BAR -> expr1 | x == gl_BAZ -> expr2 | otherwise -> expr3) Compared to: foo x = doSomething (case x of GL_BAR -> expr1 GL_BAZ -> expr2 _ .> expr3) it doesn't really look *that* much different IMHO, given the high price one has to pay for a tiny improvement in readability. But that's my personal, more conservative view of things, and I'm here to see what other people prefer.Alas, up to now, this is not very conclusive... :-/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From defigueiredo at ucdavis.edu Thu Oct 1 19:04:53 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Thu, 1 Oct 2015 13:04:53 -0600 Subject: [Haskell-cafe] Could we make Haskell Modules "location independent"? In-Reply-To: References: Message-ID: <560D83D5.2000105@ucdavis.edu> Haskell is a fantastic language for refactoring, but I find the module system gets in the way when I need to reorganize my files or am trying to use git submodules. My problem is that each module needs to "know where it is" relative to the global source paths in the cabal file. For example, if you have an import statement like ``` module Main where import SomeDirectory.SomeModule ``` the file SomeModule.hs must "know" that it is in a subdirectory as it is called because its name must have the "SomeDirectory" path as a prefix: module SomeDirectory.SomeModule where ... this would not work module SomeModule where ... To avoid having to add the SomeDirectory prefix, I end up putting *all* directories in the .cabal file. Question: Why does GHC require an exact match between the modulename and the complete path? Is there a way to relax this? Thanks, Dimitri From martin.drautzburg at web.de Fri Oct 2 07:23:25 2015 From: martin.drautzburg at web.de (martin) Date: Fri, 2 Oct 2015 09:23:25 +0200 Subject: [Haskell-cafe] Concept for "equal but unknown" Message-ID: <560E30ED.2000503@web.de> Hello all, there is a problem which popped up a number of times recently and I wondered if there is a general concept to tackle this kind of problems. It goes like this: I book a hotel room. At this time it becomes known that the hotel has one fewer room available, but it is not known which room it is. Likewise I know, that I have a reservation for "a room", but I don't know which one it is. It is however known, that the room in my reservation is the same room the hotel has removed from the list of available rooms. Another example: In air-cargo the cargo company has reserverd space in an aircraft for two containers. One for high-priority parcels and one for low-priority parcels. In the cargo hub, they plan to pack these two containers. At this point in time it is only known that there will be two containers one labelled "high-prio" and the other labelled "low-prio" but their physical identity is not known. Only when you actually do the packing you have a physical container at hand, which has identity. At this moment it becomes clear to which physical containers the reservations refer to and which physical containers are used for packing. I think I can handle this in an imparative style using an extra indirection (think pointers), though even there I would be happy if someone told me something like "this is an example of covariant unification" or something like this. But in haskell I cannot see a solution at all? So: how can I express that two things are equal to each other without knowing the exact value and how do I manage to make both assume a value once one of them becomes known. Do these kind of problems have a name? From alan.zimm at gmail.com Fri Oct 2 13:00:51 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 2 Oct 2015 15:00:51 +0200 Subject: [Haskell-cafe] Haskell Tooling Infrastructure In-Reply-To: References: Message-ID: As a follow-up to this[1], I have written a post[2] detailing how ghc-mod provides the downwards (BIOS) functions for the next version of HaRe[3]. [1] https://github.com/RefactoringTools/HaRe/wiki/Requirements-for-IDE-GHC-interfacing [2] http://alanz.github.io/haskell%20refactorer/2015/10/02/ghc-mod-for-tooling/ [3] https://github.com/alanz/HaRe/tree/wip Alan On Sun, Jun 7, 2015 at 2:02 PM, Alan & Kim Zimmerman wrote: > Now that I am finally turning back to HaRe, the question of infrastructure > again comes up. > > Basically I woudl like to focus in the tool itself, but it can only be > useful if it can deal with real world environments. > > This means properly managing all the different project and compiler > environments, and being integrated into IDEs. > > The current version uses ghc-mod for the lower level interface, and a > simple command line interface for the IDE integration. > > But I have a definite sense that as a community every tool maker is > solving the same problems over and over, from ghc-mod to ide-backend to > ghci-ng, and onwards. > > To start a discussion around some kind of architeccture that tool writers > can develop agains, ide's can integrat against and ghc/cabal can eventually > internalise, I have put some basic points down at > > > https://github.com/RefactoringTools/HaRe/wiki/Requirements-for-IDE-GHC-interfacing > > Regards > Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efasckenoth at gmail.com Fri Oct 2 14:02:57 2015 From: efasckenoth at gmail.com (Stefan =?iso-8859-1?Q?H=F6ck?=) Date: Fri, 2 Oct 2015 16:02:57 +0200 Subject: [Haskell-cafe] Concept for "equal but unknown" In-Reply-To: <560E30ED.2000503@web.de> References: <560E30ED.2000503@web.de> Message-ID: <20151002140257.GA1136@hunter.iway.ch> > how can I express that two things are equal to each other without knowing the exact value and > > how do I manage to make both assume a value once one of them becomes known. I'm sure there are fancier ways to express such things, but you could use a placeholder (an Integer for instance, wrapped in a newtype) for the room reservation, together with a Map from Integer to Room to look up the room assigned to each reservation. As long as no room is assigned to a reservation number, a lookup in the map yields Nothing. Once a room is assigned, a lookup yields the room. All this should probably be wrapped up in the State Monad (the Map with the reservations being the state), so you don't have to carry around the Map explicitly. Hope this is helps. From mihai.maruseac at gmail.com Fri Oct 2 14:11:42 2015 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Fri, 2 Oct 2015 10:11:42 -0400 Subject: [Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, November 2015 edition (29th edition) Message-ID: 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: 30 October 2015 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format, both are equally accepted) ============================================================ This is the short story: * 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. * 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 usual 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. _However_, if you don't want/have time to format the entry for LaTeX, you can submit it in any other format possible and we will be happy to convert it for the final report. 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 can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya From martin.drautzburg at web.de Fri Oct 2 14:37:16 2015 From: martin.drautzburg at web.de (martin) Date: Fri, 2 Oct 2015 16:37:16 +0200 Subject: [Haskell-cafe] Concept for "equal but unknown" In-Reply-To: <20151002140257.GA1136@hunter.iway.ch> References: <560E30ED.2000503@web.de> <20151002140257.GA1136@hunter.iway.ch> Message-ID: <560E969C.4020302@web.de> Am 10/02/2015 um 04:02 PM schrieb Stefan H?ck: >> how can I express that two things are equal to each other without knowing the exact value and >> >> how do I manage to make both assume a value once one of them becomes known. > > I'm sure there are fancier ways to express such things, but you could > use a placeholder (an Integer for instance, wrapped in a newtype) > for the room reservation, together with a Map from Integer to Room to look > up the room assigned to each reservation. As long as no room is assigned > to a reservation number, a lookup in the map yields Nothing. Once a room > is assigned, a lookup yields the room. All this should probably be > wrapped up in the State Monad (the Map with the reservations being > the state), so you don't have to carry around the Map explicitly. Yes, this is what I would have done in imperative code and from your suggestion I understand that in haskell I'll have to carry that map around. So far so good. Here is another thought: In math it is terribly easy to express what I am after a simple "x=y" states that x and y are equal, but unknown. As soon as I add x=25, there is no more choice on the value of y. I guess I am after values which become more and more defined in the course of computation. From marcin.jan.mrotek at gmail.com Fri Oct 2 14:45:58 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Fri, 2 Oct 2015 16:45:58 +0200 Subject: [Haskell-cafe] Concept for "equal but unknown" In-Reply-To: <560E969C.4020302@web.de> References: <560E30ED.2000503@web.de> <20151002140257.GA1136@hunter.iway.ch> <560E969C.4020302@web.de> Message-ID: Hello, Do you mean something like variable unification in Prolog or Oz? Maybe something like this could help you: https://hackage.haskell.org/package/monad-unify-0.2.2/docs/Control-Monad-Unify.html or https://hackage.haskell.org/package/unification-fd Disclaimer: I've never used either of those packages. Best regards, Marcin Mrotek From olf at aatal-apotheke.de Fri Oct 2 15:36:50 2015 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 2 Oct 2015 17:36:50 +0200 Subject: [Haskell-cafe] Concept for "equal but unknown" Message-ID: To me this sounds like the Reader monad: You have a value that depends on something that is yet to be decided upon. data SomeCargo = SomeCargo { decide_attribute1 :: ContainerID -> Attr1 decide_attribute2 :: ContainerID -> Attr2 ... } data ConcreteCargo = ConcreteCargo { attribute1 :: Attr1 attribute2 :: Attr2 } withID :: SomeCargo -> ContainerID -> ConcreteCargo If the type ContainerID is searchable [1] then you can have an Eq instance even for the SomeCargo type. That is, two containers are equal if whenever the same ID gets assigned, they have the same properties. The technical term would be "indistinguishable in all contexts". -- Olaf [1] http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-finite-time/ From adam at bergmark.nl Fri Oct 2 15:55:50 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Fri, 2 Oct 2015 17:55:50 +0200 Subject: [Haskell-cafe] [PATCH] Interpret missing link relation in Atom as "alternate" In-Reply-To: <1443543161-21716-1-git-send-email-fr33domlover@riseup.net> References: <1443543161-21716-1-git-send-email-fr33domlover@riseup.net> Message-ID: D?ne! http://hackage.haskell.org/package/feed-0.3.10.2 Thank you, Adam On Tue, Sep 29, 2015 at 6:12 PM, wrote: > From: fr33domlover > > The Atom RFC says that when a link element doesn't > specify the "rel" attribute, i.e. link relation, it > should be interpreted as an "alternate" relation. > This commit makes the feed and item query functions > treat a missing relation as "alternate". > --- > feed.cabal | 5 +- > src/Text/Feed/Query.hs | 11 +- > tests/Main.hs | 9 +- > tests/Text/Atom/Tests.hs | 39 + > tests/files/atom.xml | 6733 > ++++++++++++++++++++++++++++++++++++++++++++++ > 5 files changed, 6789 insertions(+), 8 deletions(-) > create mode 100644 tests/Text/Atom/Tests.hs > create mode 100644 tests/files/atom.xml > > diff --git a/feed.cabal b/feed.cabal > index b22dfed..8c04444 100644 > --- a/feed.cabal > +++ b/feed.cabal > @@ -17,7 +17,9 @@ homepage: https://github.com/bergmark/feed > bug-reports: https://github.com/bergmark/feed/issues > cabal-version: >= 1.8 > build-type: Simple > -data-files: tests/files/rss20.xml > +data-files: > + tests/files/rss20.xml > + tests/files/atom.xml > extra-source-files: > README.md > CHANGELOG.md > @@ -68,6 +70,7 @@ test-suite tests > main-is: Main.hs > type: exitcode-stdio-1.0 > other-modules: > + Text.Atom.Tests > Text.RSS.Equals > Text.RSS.Export.Tests > Text.RSS.Import.Tests > diff --git a/src/Text/Feed/Query.hs b/src/Text/Feed/Query.hs > index 970d17b..0a599c7 100644 > --- a/src/Text/Feed/Query.hs > +++ b/src/Text/Feed/Query.hs > @@ -129,7 +129,9 @@ getFeedHTML ft = > Just e1 -> fmap XML.strContent $ findElement (unqual "link") e1 > Nothing -> Nothing > where > - isSelf lr = toStr (Atom.linkRel lr) == "alternate" && isHTMLType > (linkType lr) > + isSelf lr = > + let rel = Atom.linkRel lr > + in (isNothing rel || toStr rel == "alternate") && isHTMLType > (linkType lr) > > isHTMLType (Just str) = "lmth" `isPrefixOf` (reverse str) > isHTMLType _ = True -- if none given, assume html. > @@ -243,13 +245,16 @@ getItemTitle it = > getItemLink :: ItemGetter String > getItemLink it = > case it of > - -- look up the 'alternate' HTML link relation on the entry: > + -- look up the 'alternate' HTML link relation on the entry, or one > + -- without link relation since that is equivalent to 'alternate': > Feed.AtomItem i -> fmap Atom.linkHref $ listToMaybe $ filter isSelf $ > Atom.entryLinks i > Feed.RSSItem i -> RSS.rssItemLink i > Feed.RSS1Item i -> Just (RSS1.itemLink i) > Feed.XMLItem i -> fmap (\ ei -> XML.strContent ei) $ findElement > (unqual "link") i > where > - isSelf lr = toStr (Atom.linkRel lr) == "alternate" && isHTMLType > (linkType lr) > + isSelf lr = > + let rel = Atom.linkRel lr > + in (isNothing rel || toStr rel == "alternate") && isHTMLType > (linkType lr) > > isHTMLType (Just str) = "lmth" `isPrefixOf` (reverse str) > isHTMLType _ = True -- if none given, assume html. > diff --git a/tests/Main.hs b/tests/Main.hs > index 6aa492a..e55e42f 100644 > --- a/tests/Main.hs > +++ b/tests/Main.hs > @@ -2,9 +2,10 @@ module Main (main) where > > import Test.Framework (defaultMain) > import Text.RSS.Tests (rssTests) > - > +import Text.Atom.Tests (atomTests) > > main :: IO () > -main = defaultMain [ > - rssTests > - ] > +main = defaultMain > + [ rssTests > + , atomTests > + ] > diff --git a/tests/Text/Atom/Tests.hs b/tests/Text/Atom/Tests.hs > new file mode 100644 > index 0000000..96a8dae > --- /dev/null > +++ b/tests/Text/Atom/Tests.hs > @@ -0,0 +1,39 @@ > +module Text.Atom.Tests where > + > +import Data.Maybe (isJust) > +import Test.Framework (Test, mutuallyExclusive, testGroup) > +import Test.HUnit (Assertion, assertBool) > +import Test.Framework.Providers.HUnit (testCase) > +import Text.Atom.Feed > +import Text.Feed.Export > +import Text.Feed.Import > +import Text.Feed.Query > +import Text.Feed.Types > +import Text.XML.Light > + > +import Paths_feed > + > +atomTests :: Test > +atomTests = testGroup "Text.Atom" > + [ mutuallyExclusive $ testGroup "Atom" > + [ testFullAtomParse > + , testAtomAlternate > + ] > + ] > + > +testFullAtomParse :: Test > +testFullAtomParse = testCase "parse a complete atom file" testAtom > + where > + testAtom :: Assertion > + testAtom = do > + putStrLn . ppTopElement . xmlFeed =<< parseFeedFromFile =<< > getDataFileName "tests/files/atom.xml" > + assertBool "OK" True > + > +testAtomAlternate :: Test > +testAtomAlternate = testCase "*unspecified* link relation means > 'alternate'" testAlt > + where > + testAlt :: Assertion > + testAlt = > + let nullent = nullEntry "" (TextString "") "" > + item = AtomItem nullent { entryLinks = [nullLink ""] } > + in assertBool "unspecified means alternate" $ isJust $ getItemLink > item > diff --git a/tests/files/atom.xml b/tests/files/atom.xml > new file mode 100644 > index 0000000..c58181b > --- /dev/null > +++ b/tests/files/atom.xml > @@ -0,0 +1,6733 @@ > + > + > + > +RecentChanges > + > + type="application/atom+xml"/> > + > + > +Rel4tion > + > + > + > + > + > + > +http://www.rel4tion.org/recentchanges/ > + > +Rel4tion > +ikiwiki > +2015-09-27T20:04:22Z > + > + change to people/fr33domlover on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_c989bafb33d2bdcd8f01b408f63b7981e62110a9/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-27T20:04:22Z > + 2015-09-27T20:04:22Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-c989bafb33d2bdcd8f01b408f63b7981e62110a9" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover.mdwn;h=70e87c497caca5f004d5434a7d6e52b48c01d4f3;hp=2230d818ac803844191d7842bcb24fa4d5e45e14;hb=c989bafb33d2bdcd8f01b408f63b7981e62110a9;hpb=44148b1572c22c8d979bd90a75f82dbe444530df" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">people/fr33domlover</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">08:04:22 PM 09/27/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=c989bafb33d2bdcd8f01b408f63b7981e62110a9&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +me: update paragraph about the open tickets list<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_44148b1572c22c8d979bd90a75f82dbe444530df/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-27T19:58:19Z > + 2015-09-27T19:58:19Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-44148b1572c22c8d979bd90a75f82dbe444530df" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot.mdwn;h=ff14943d3018d85e80703df32c9ca2c65c13c83a;hp=d75dd79bb2e9c594f78de4f5897ea7e60d554433;hb=44148b1572c22c8d979bd90a75f82dbe444530df;hpb=1c5f47be50411f5bbcf5b2373d20f6095aeb078f" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot" > rel="nofollow">projects/funbot</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:58:19 PM 09/27/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=44148b1572c22c8d979bd90a75f82dbe444530df" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: mention the helper packages<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to access/paste on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_1c5f47be50411f5bbcf5b2373d20f6095aeb078f/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-21T17:04:36Z > + 2015-09-21T17:04:36Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-1c5f47be50411f5bbcf5b2373d20f6095aeb078f" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=access/paste.mdwn;h=118bdeb612c6b61cf5b59c8bd5b8ea7072a61ae8;hp=978504f51469a8aa3ad45c5d55be22ba0503e4ef;hb=1c5f47be50411f5bbcf5b2373d20f6095aeb078f;hpb=681de3e0ea89f8597ea39766be861e70f947793f" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=access%2Fpaste" > rel="nofollow">access/paste</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">05:04:36 PM 09/21/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=1c5f47be50411f5bbcf5b2373d20f6095aeb078f" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +access: update URL of paste server code<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/guide on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_681de3e0ea89f8597ea39766be861e70f947793f/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-18T21:39:54Z > + 2015-09-18T21:39:54Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-681de3e0ea89f8597ea39766be861e70f947793f" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=80ec023c5699abad621d01b1818d39db78ccaed0;hp=da0633c981be6cf4f16c67dea4bf1cba63d2f827;hb=681de3e0ea89f8597ea39766be861e70f947793f;hpb=1e55bf1839b514e0524a294fa62ce0eed46ad3e1" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Fguide" > rel="nofollow">projects/funbot/guide</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:39:54 PM 09/18/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=681de3e0ea89f8597ea39766be861e70f947793f" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: mention new dependency, funbot-ext-events<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_1e55bf1839b514e0524a294fa62ce0eed46ad3e1/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-17T19:44:49Z > + 2015-09-17T19:44:49Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-1e55bf1839b514e0524a294fa62ce0eed46ad3e1" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot.mdwn;h=d75dd79bb2e9c594f78de4f5897ea7e60d554433;hp=f563f5208d711e1946624f45b58eb19e1c8fd688;hb=1e55bf1839b514e0524a294fa62ce0eed46ad3e1;hpb=9abd0dcfc30145da75cd2b246eac79fdd250a57f" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot&amp;do=goto" > rel="nofollow">projects/funbot</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:44:49 PM 09/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=1e55bf1839b514e0524a294fa62ce0eed46ad3e1" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: remove dummy text<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_9abd0dcfc30145da75cd2b246eac79fdd250a57f/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-17T19:43:38Z > + 2015-09-17T19:43:38Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-9abd0dcfc30145da75cd2b246eac79fdd250a57f" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot.mdwn;h=f563f5208d711e1946624f45b58eb19e1c8fd688;hp=4648b803378bdbf71232640adf24429bf1e0bf59;hb=9abd0dcfc30145da75cd2b246eac79fdd250a57f;hpb=8b70f13be1209a55b3d31122cba2a8a8a31539ab" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot" > rel="nofollow">projects/funbot</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:43:38 PM 09/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=9abd0dcfc30145da75cd2b246eac79fdd250a57f&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: minor update and some dummy test text<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to shortcuts on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_8b70f13be1209a55b3d31122cba2a8a8a31539ab/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-17T19:22:22Z > + 2015-09-17T19:22:22Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-8b70f13be1209a55b3d31122cba2a8a8a31539ab" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=shortcuts.mdwn;h=96adf1fbd8cb6601d15184bd5ec1854e262c003b;hp=848c9edfe10d412737a37883ff955dbee20089cb;hb=8b70f13be1209a55b3d31122cba2a8a8a31539ab;hpb=4811a57e33da708175ddd6d016e78bd410f4d1ea" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=shortcuts&amp;do=goto" > rel="nofollow">shortcuts</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:22:22 PM 09/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=8b70f13be1209a55b3d31122cba2a8a8a31539ab" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +fix notabug shortcut, it shouldn&#39;t url-encode<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/5 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_4811a57e33da708175ddd6d016e78bd410f4d1ea/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-17T13:28:45Z > + 2015-09-17T13:28:45Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-4811a57e33da708175ddd6d016e78bd410f4d1ea" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/5.mdwn;h=f3c6b11312ebf91ef89c077beb98b475f5f7760c;hp=993dac4b04ed6e9cfc0796f09a90ee568106b193;hb=4811a57e33da708175ddd6d016e78bd410f4d1ea;hpb=07e5d7d13fc364c06ed1bda3f21fa6a493276859" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F5" > rel="nofollow">projects/funbot/tickets/5</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">01:28:45 PM 09/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=4811a57e33da708175ddd6d016e78bd410f4d1ea&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: close memo ticket<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/2 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_07e5d7d13fc364c06ed1bda3f21fa6a493276859/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-17T13:22:05Z > + 2015-09-17T13:22:05Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-07e5d7d13fc364c06ed1bda3f21fa6a493276859" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=58c609b1cc1ffb88ad01aa39806bb43d166f67f9;hp=2cc56bb7968465ca690ebcbed6ed5a5213fb8a0c;hb=07e5d7d13fc364c06ed1bda3f21fa6a493276859;hpb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F2" > rel="nofollow">projects/funbot/tickets/2</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">01:22:05 PM 09/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=07e5d7d13fc364c06ed1bda3f21fa6a493276859&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: close persistence ticket, we have json-state now<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects projects/json-state > projects/json-state/decisions projects/json-state/forum > projects/json-state/news projects/json-state/releases > projects/json-state/tickets on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-17T13:01:04Z > + 2015-09-17T13:01:04Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=345421854fa54c60f59686d3908fe58dd4789069;hp=10ae06877f9882b6bd6f3bb1c5b9dd3c7ab032c1;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;do=goto" > rel="nofollow">projects</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state.mdwn;h=41137012211445b4f3f48fc8e1c036ababdab2b9;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fjson-state&amp;do=goto" > rel="nofollow">projects/json-state</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/decisions.mdwn;h=87e40f15dec6533bbeebf666fa4d2761c0d5adad;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fjson-state%2Fdecisions" > rel="nofollow">projects/json-state/decisions</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/forum.mdwn;h=cdc6c618a5af5e908dc00cabeed27a4f4d5c9125;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fjson-state%2Fforum" > rel="nofollow">projects/json-state/forum</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/news.mdwn;h=c463308444ec8f91a1bfae7dfda2e5fe3d183863;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fjson-state%2Fnews" > rel="nofollow">projects/json-state/news</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/releases.mdwn;h=e4dcf00f9501d98e461c4a6ccd75818cc54b71fc;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fjson-state%2Freleases&amp;do=goto" > rel="nofollow">projects/json-state/releases</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/json-state/tickets.mdwn;h=df2d37627427fe3d89829ad503c725de72c7d762;hp=0000000000000000000000000000000000000000;hb=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe;hpb=8271123effea28344517c121ee596eb7217e28e2" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fjson-state%2Ftickets" > rel="nofollow">projects/json-state/tickets</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">01:01:04 PM 09/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=5f6c2df9dfec2c3303dedfbd4712f616e7dd5ebe&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +json-state: new project<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/settings projects/settings/releases on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_8271123effea28344517c121ee596eb7217e28e2/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-17T12:59:24Z > + 2015-09-17T12:59:24Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-8271123effea28344517c121ee596eb7217e28e2" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings.mdwn;h=be444e1b1ee23712cdb25e2d3fa155319dd04b38;hp=b7f5ffc7ee35f85a7a7d5094fdc02c578122825e;hb=8271123effea28344517c121ee596eb7217e28e2;hpb=9bd1e350a4f81d79b820eb5a1ab3e644a280399a" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings&amp;do=goto" > rel="nofollow">projects/settings</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/releases.mdwn;h=4c6c784b8ea0ca05ff9fd5232a2a195159aa4cae;hp=e4efd9b315242da6e04f9e94546ed3522bdaac68;hb=8271123effea28344517c121ee596eb7217e28e2;hpb=9bd1e350a4f81d79b820eb5a1ab3e644a280399a" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fsettings%2Freleases" > rel="nofollow">projects/settings/releases</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:59:24 PM 09/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=8271123effea28344517c121ee596eb7217e28e2" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +settings: update repo link<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/15 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_9bd1e350a4f81d79b820eb5a1ab3e644a280399a/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-17T11:51:13Z > + 2015-09-17T11:51:13Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-9bd1e350a4f81d79b820eb5a1ab3e644a280399a" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=a6aef60136eb5939cd49fe3dff12a23214f96914;hp=37a1b5e2695ce312b8f1b8e37078dd4cdbc90898;hb=9bd1e350a4f81d79b820eb5a1ab3e644a280399a;hpb=edabc8116457185ce07d1f61737fa2ce8518bd4b" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;do=goto" > rel="nofollow">projects/funbot/tickets/15</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">11:51:13 AM 09/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=9bd1e350a4f81d79b820eb5a1ab3e644a280399a" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: settings system is finally complete<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/manual on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_edabc8116457185ce07d1f61737fa2ce8518bd4b/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-16T19:04:22Z > + 2015-09-16T19:04:22Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-edabc8116457185ce07d1f61737fa2ce8518bd4b" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=d098b5370a8cbf0e60f80e37f23276dda4f2afd1;hp=56ff43060cd3eecca2eb10237bc7303d1ecc8652;hb=edabc8116457185ce07d1f61737fa2ce8518bd4b;hpb=37ec11668e6a6a9418209c5411508d018592519d" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Fmanual" > rel="nofollow">projects/funbot/manual</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:04:22 PM 09/16/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=edabc8116457185ce07d1f61737fa2ce8518bd4b&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: update manual with recent changes<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to people/fr33domlover/blog/love-of-wisdom on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_37ec11668e6a6a9418209c5411508d018592519d/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-12T13:12:06Z > + 2015-09-12T13:12:06Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-37ec11668e6a6a9418209c5411508d018592519d" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/blog/love-of-wisdom.mdwn;h=a9bfd88c473fc20270af0a83570f8a4b70d12691;hp=0000000000000000000000000000000000000000;hb=37ec11668e6a6a9418209c5411508d018592519d;hpb=29d3a9e5554fb2ea6987f31f968578cc2647e8f3" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover%2Fblog%2Flove-of-wisdom" > rel="nofollow">people/fr33domlover/blog/love-of-wisdom</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">01:12:06 PM 09/12/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=37ec11668e6a6a9418209c5411508d018592519d&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +me: another blog post...<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to news/break on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_29d3a9e5554fb2ea6987f31f968578cc2647e8f3/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-10T22:01:02Z > + 2015-09-10T22:01:02Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-29d3a9e5554fb2ea6987f31f968578cc2647e8f3" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=news/break.mdwn;h=5eb7a858b10923cf2973d7b6004cb2c1783bea45;hp=0000000000000000000000000000000000000000;hb=29d3a9e5554fb2ea6987f31f968578cc2647e8f3;hpb=34a21b40a95051a6bee7f3c89223b868ebcb64ac" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=news%2Fbreak&amp;do=goto" > rel="nofollow">news/break</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">10:01:02 PM 09/10/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=29d3a9e5554fb2ea6987f31f968578cc2647e8f3&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +news: break<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to index on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_34a21b40a95051a6bee7f3c89223b868ebcb64ac/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-10T21:50:12Z > + 2015-09-10T21:50:12Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-34a21b40a95051a6bee7f3c89223b868ebcb64ac" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=index.mdwn;h=c68cb36b6224504f98fe4811e08c49a1b07f2df0;hp=126fe28b2815f6a3d4a3095dd5e11485cebb8086;hb=34a21b40a95051a6bee7f3c89223b868ebcb64ac;hpb=ed2a95c268ef060d9dddae5a24b4672911491c72" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=index" > rel="nofollow">index</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:50:12 PM 09/10/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=34a21b40a95051a6bee7f3c89223b868ebcb64ac&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +index: remove feedback box<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/manual on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_ed2a95c268ef060d9dddae5a24b4672911491c72/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-10T18:46:34Z > + 2015-09-10T18:46:34Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-ed2a95c268ef060d9dddae5a24b4672911491c72" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=56ff43060cd3eecca2eb10237bc7303d1ecc8652;hp=44c3d463280d7e275a6f93bd9633289f0872b686;hb=ed2a95c268ef060d9dddae5a24b4672911491c72;hpb=d3cdcea02b8dedede9d590ff8a730cac95a10c58" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;do=goto" > rel="nofollow">projects/funbot/manual</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">06:46:34 PM 09/10/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=ed2a95c268ef060d9dddae5a24b4672911491c72" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: revise manual<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/5 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_d3cdcea02b8dedede9d590ff8a730cac95a10c58/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-09-10T13:16:52Z > + 2015-09-10T13:16:52Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-d3cdcea02b8dedede9d590ff8a730cac95a10c58" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/5.mdwn;h=993dac4b04ed6e9cfc0796f09a90ee568106b193;hp=606f28657913248cbfe3204aa6f0ffebec656b55;hb=d3cdcea02b8dedede9d590ff8a730cac95a10c58;hpb=1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F5&amp;do=goto" > rel="nofollow">projects/funbot/tickets/5</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">01:16:52 PM 09/10/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=d3cdcea02b8dedede9d590ff8a730cac95a10c58" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: document work on memos<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/18 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-31T17:35:31Z > + 2015-08-31T17:35:31Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/18.mdwn;h=92ddfe617ac1113a7b96d24857c5e783f55432aa;hp=d9fbdf7bd75e3ce0638d56f2bae98e47270b7baa;hb=1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2;hpb=74c8029879813f445632d74c6b0233496729a757" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F18&amp;do=goto" > rel="nofollow">projects/funbot/tickets/18</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">05:35:31 PM 08/31/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=1a05dfe95cd5a544f09ef39d5187f6ecf75af3b2&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: document progress on friendly command access<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/18 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_74c8029879813f445632d74c6b0233496729a757/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-30T16:31:13Z > + 2015-08-30T16:31:13Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-74c8029879813f445632d74c6b0233496729a757" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/18.mdwn;h=d9fbdf7bd75e3ce0638d56f2bae98e47270b7baa;hp=f717e312738110e9fa51874c4efa2b918dca6c43;hb=74c8029879813f445632d74c6b0233496729a757;hpb=2f15a1e3784ca2c076afb2654bb313723de8592e" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F18" > rel="nofollow">projects/funbot/tickets/18</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">04:31:13 PM 08/30/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=74c8029879813f445632d74c6b0233496729a757&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: plan API for friendly command access<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/guide on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_2f15a1e3784ca2c076afb2654bb313723de8592e/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-28T21:39:21Z > + 2015-08-28T21:39:21Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-2f15a1e3784ca2c076afb2654bb313723de8592e" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=da0633c981be6cf4f16c67dea4bf1cba63d2f827;hp=bb59f3668fc21acdb2072022cb65808df5becebd;hb=2f15a1e3784ca2c076afb2654bb313723de8592e;hpb=60f4a8590a34861a966b85ad8d7e6c9c8daa7ace" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Fguide" > rel="nofollow">projects/funbot/guide</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:39:21 PM 08/28/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=2f15a1e3784ca2c076afb2654bb313723de8592e" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: update guide to explain new state files<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/15 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_60f4a8590a34861a966b85ad8d7e6c9c8daa7ace/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-24T19:45:05Z > + 2015-08-24T19:45:05Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-60f4a8590a34861a966b85ad8d7e6c9c8daa7ace" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=37a1b5e2695ce312b8f1b8e37078dd4cdbc90898;hp=a466fadce2c88cde0347c164e7a49c97e32e1b13;hb=60f4a8590a34861a966b85ad8d7e6c9c8daa7ace;hpb=d0ab67c9ff7643ac75e918e3cb295288003e47e4" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;do=goto" > rel="nofollow">projects/funbot/tickets/15</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:45:05 PM 08/24/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=60f4a8590a34861a966b85ad8d7e6c9c8daa7ace&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: settings now support exploration<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/18 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_d0ab67c9ff7643ac75e918e3cb295288003e47e4/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-23T22:01:20Z > + 2015-08-23T22:01:20Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-d0ab67c9ff7643ac75e918e3cb295288003e47e4" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/18.mdwn;h=f717e312738110e9fa51874c4efa2b918dca6c43;hp=0000000000000000000000000000000000000000;hb=d0ab67c9ff7643ac75e918e3cb295288003e47e4;hpb=6e90ed1b9fa935727054984b9252bd79a5dbef6b" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F18&amp;do=goto" > rel="nofollow">projects/funbot/tickets/18</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">10:01:20 PM 08/23/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=d0ab67c9ff7643ac75e918e3cb295288003e47e4" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: new ticket: intuitive UI<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/settings/tickets/1 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_6e90ed1b9fa935727054984b9252bd79a5dbef6b/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-23T21:49:11Z > + 2015-08-23T21:49:11Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-6e90ed1b9fa935727054984b9252bd79a5dbef6b" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=e666ba63a41d9c574d63f73f8e85316a165aa6f9;hp=1212dbea4050efc9f0e06f61ea832babb70099ed;hb=6e90ed1b9fa935727054984b9252bd79a5dbef6b;hpb=9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Ftickets%2F1&amp;do=goto" > rel="nofollow">projects/settings/tickets/1</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:49:11 PM 08/23/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=6e90ed1b9fa935727054984b9252bd79a5dbef6b" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +settings: close #1, callbacks and save/load added<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/guide on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-23T19:23:22Z > + 2015-08-23T19:23:22Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=bb59f3668fc21acdb2072022cb65808df5becebd;hp=70eb2c6b749d1499807a21e0bc4a6ef2614f90a4;hb=9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa;hpb=6f734bfda528f1afb249d33bb438a7a5638f3ad1" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fguide&amp;do=goto" > rel="nofollow">projects/funbot/guide</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:23:22 PM 08/23/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=9a0291a0846a9ff9cca95b6f7d23938bc2dcdefa" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: explain about settings in the guide<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/settings/tickets/1 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_6f734bfda528f1afb249d33bb438a7a5638f3ad1/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-23T09:49:55Z > + 2015-08-23T09:49:55Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-6f734bfda528f1afb249d33bb438a7a5638f3ad1" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=1212dbea4050efc9f0e06f61ea832babb70099ed;hp=83d3c27561e380877f7214159378ff806b206b2c;hb=6f734bfda528f1afb249d33bb438a7a5638f3ad1;hpb=428482ea05956bcfebaaa68abeb9cdc1105ed129" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fsettings%2Ftickets%2F1" > rel="nofollow">projects/settings/tickets/1</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:49:55 AM 08/23/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=6f734bfda528f1afb249d33bb438a7a5638f3ad1" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +settings: plan custom debounce action for saving<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to people/fr33domlover/blog/insanity2 on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_428482ea05956bcfebaaa68abeb9cdc1105ed129/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-23T09:49:16Z > + 2015-08-23T09:49:16Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-428482ea05956bcfebaaa68abeb9cdc1105ed129" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/blog/insanity2.mdwn;h=9746b62a83126b3a142ff7d067de559441e39a00;hp=0000000000000000000000000000000000000000;hb=428482ea05956bcfebaaa68abeb9cdc1105ed129;hpb=67577535d19a1fcd1c187d71f41aa012a16d65f3" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover%2Fblog%2Finsanity2&amp;do=goto" > rel="nofollow">people/fr33domlover/blog/insanity2</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:49:16 AM 08/23/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=428482ea05956bcfebaaa68abeb9cdc1105ed129&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +blog post...<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/settings/tickets/1 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_67577535d19a1fcd1c187d71f41aa012a16d65f3/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-22T00:42:25Z > + 2015-08-22T00:42:25Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-67577535d19a1fcd1c187d71f41aa012a16d65f3" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=83d3c27561e380877f7214159378ff806b206b2c;hp=6a63447c56eaeca30431fad77cb1945230f73ac7;hb=67577535d19a1fcd1c187d71f41aa012a16d65f3;hpb=f4aaab3a133c556a0db208924e86bbb312879319" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fsettings%2Ftickets%2F1" > rel="nofollow">projects/settings/tickets/1</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:42:25 AM 08/22/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=67577535d19a1fcd1c187d71f41aa012a16d65f3" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +settings: work on callbacks and persistence<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/settings/tickets/1 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_f4aaab3a133c556a0db208924e86bbb312879319/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-21T14:20:30Z > + 2015-08-21T14:20:30Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-f4aaab3a133c556a0db208924e86bbb312879319" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets/1.mdwn;h=6a63447c56eaeca30431fad77cb1945230f73ac7;hp=0000000000000000000000000000000000000000;hb=f4aaab3a133c556a0db208924e86bbb312879319;hpb=2e457435020f1ab3b5836e8efb3cc1228c6b595c" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Ftickets%2F1&amp;do=goto" > rel="nofollow">projects/settings/tickets/1</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">02:20:30 PM 08/21/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=f4aaab3a133c556a0db208924e86bbb312879319&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +settings: new ticket: scope and features<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects projects/feed-collect > projects/feed-collect/decisions projects/feed-collect/forum > projects/feed-collect/news projects/feed-collect/releases > projects/feed-collect/tickets on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_2e457435020f1ab3b5836e8efb3cc1228c6b595c/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-19T10:02:40Z > + 2015-08-19T10:02:40Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-2e457435020f1ab3b5836e8efb3cc1228c6b595c" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=10ae06877f9882b6bd6f3bb1c5b9dd3c7ab032c1;hp=898655fcc20c4302682ffe196aa54e3afeb59b36;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;do=goto" > rel="nofollow">projects</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect.mdwn;h=6c574d38ef834e36a9a9be69bfcff3a6598fe461;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect&amp;do=goto" > rel="nofollow">projects/feed-collect</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/decisions.mdwn;h=ae1b64118c25d3e7236d3f239dfb9c423225532a;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffeed-collect%2Fdecisions" > rel="nofollow">projects/feed-collect/decisions</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/forum.mdwn;h=21ae61a8f6c6c15ac9fc7d1776599bddbb66bd39;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Fforum&amp;do=goto" > rel="nofollow">projects/feed-collect/forum</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/news.mdwn;h=b7a2df9ac1e94ba97e0bfbcc56d346a153ad78f1;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Fnews&amp;do=goto" > rel="nofollow">projects/feed-collect/news</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/releases.mdwn;h=1bf09d72d75f6bce0cf32b591d5fb6245c99d4c9;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Freleases&amp;do=goto" > rel="nofollow">projects/feed-collect/releases</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/feed-collect/tickets.mdwn;h=99f8e90067ef5c1404674843969b71e2184721aa;hp=0000000000000000000000000000000000000000;hb=2e457435020f1ab3b5836e8efb3cc1228c6b595c;hpb=e127857268e2b2c8181245b6693205c98f371648" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffeed-collect%2Ftickets&amp;do=goto" > rel="nofollow">projects/feed-collect/tickets</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">10:02:40 AM 08/19/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=2e457435020f1ab3b5836e8efb3cc1228c6b595c" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +feed-collect: new project (actually about to release)<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/6 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_e127857268e2b2c8181245b6693205c98f371648/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-18T17:06:48Z > + 2015-08-18T17:06:48Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-e127857268e2b2c8181245b6693205c98f371648" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/6.mdwn;h=572dde578082b3005aa3534ed3c0a7f92f21f7b3;hp=bffd53261a36337edc4988f732b733d1996f6e5c;hb=e127857268e2b2c8181245b6693205c98f371648;hpb=1f86b06ce5d3930dc77991312d02cba3193084f6" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F6&amp;do=goto" > rel="nofollow">projects/funbot/tickets/6</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">05:06:48 PM 08/18/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=e127857268e2b2c8181245b6693205c98f371648" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +fix invalid link<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/6 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_1f86b06ce5d3930dc77991312d02cba3193084f6/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-18T14:54:20Z > + 2015-08-18T14:54:20Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-1f86b06ce5d3930dc77991312d02cba3193084f6" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/6.mdwn;h=bffd53261a36337edc4988f732b733d1996f6e5c;hp=685bde0ac57f25f9a469350985154c13330ccf1e;hb=1f86b06ce5d3930dc77991312d02cba3193084f6;hpb=d2bcaf67089dbb1b92c2128b23134e48597ed455" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F6&amp;do=goto" > rel="nofollow">projects/funbot/tickets/6</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">02:54:20 PM 08/18/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=1f86b06ce5d3930dc77991312d02cba3193084f6" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: update status of freepost integration<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/4 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_d2bcaf67089dbb1b92c2128b23134e48597ed455/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-18T14:02:57Z > + 2015-08-18T14:02:57Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-d2bcaf67089dbb1b92c2128b23134e48597ed455" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/4.mdwn;h=ff2a4540311b77cfbad57c95b57a2090b7eedb9b;hp=071cb7e64ae57c211834ee5cc7e80132209a6bc2;hb=d2bcaf67089dbb1b92c2128b23134e48597ed455;hpb=b61f7736931f2801c6fdd401f29f6fc78b2d900a" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F4&amp;do=goto" > rel="nofollow">projects/funbot/tickets/4</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">02:02:57 PM 08/18/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=d2bcaf67089dbb1b92c2128b23134e48597ed455" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: notes on coding of logging system<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/16 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_b61f7736931f2801c6fdd401f29f6fc78b2d900a/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-17T09:12:02Z > + 2015-08-17T09:12:02Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-b61f7736931f2801c6fdd401f29f6fc78b2d900a" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/16.mdwn;h=1197b4650734456f81f92dfd314c5a076bb5762c;hp=15bbe0cb556feb7ed9000c36bb42a8396fb12921;hb=b61f7736931f2801c6fdd401f29f6fc78b2d900a;hpb=a9301fc50b752e55af343255a0b54b990646bd43" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F16&amp;do=goto" > rel="nofollow">projects/funbot/tickets/16</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:12:02 AM 08/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=b61f7736931f2801c6fdd401f29f6fc78b2d900a&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: close #16, feed reader implemented<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/17 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_a9301fc50b752e55af343255a0b54b990646bd43/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-17T09:09:36Z > + 2015-08-17T09:09:36Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-a9301fc50b752e55af343255a0b54b990646bd43" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/17.mdwn;h=7502e27ea78f3f9667ccdad47b77914d283502d2;hp=70f51944ac387924b6f8bf7433631a3baeb038a4;hb=a9301fc50b752e55af343255a0b54b990646bd43;hpb=360a6d980da581e86d5fe7a80c1fa059b668ab93" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F17&amp;do=goto" > rel="nofollow">projects/funbot/tickets/17</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:09:36 AM 08/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=a9301fc50b752e55af343255a0b54b990646bd43" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: close #17, the bot should spam less now<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/10 > projects/irc-fun-bot/tickets/3 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_360a6d980da581e86d5fe7a80c1fa059b668ab93/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-17T00:39:34Z > + 2015-08-17T00:39:34Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-360a6d980da581e86d5fe7a80c1fa059b668ab93" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/10.mdwn;h=f267e06c2e4ba2d221a5e8b493e7d83954a86b98;hp=2dfa6c5aa076d72de618c647a17774e23cacf78f;hb=360a6d980da581e86d5fe7a80c1fa059b668ab93;hpb=f7b4fd5b731cb17a6489352f10a735368f34d46d" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F10" > rel="nofollow">projects/funbot/tickets/10</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/3.mdwn;h=ca2600e82be6faed8128f2e92e37f7941fc25415;hp=cf324dd4a0534fb640a72e516a58205b01917e28;hb=360a6d980da581e86d5fe7a80c1fa059b668ab93;hpb=f7b4fd5b731cb17a6489352f10a735368f34d46d" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F3&amp;do=goto" > rel="nofollow">projects/irc-fun-bot/tickets/3</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:39:34 AM 08/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=360a6d980da581e86d5fe7a80c1fa059b668ab93&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: close tickets done with<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/guide projects/funbot/manual on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_f7b4fd5b731cb17a6489352f10a735368f34d46d/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-16T22:15:37Z > + 2015-08-16T22:15:37Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-f7b4fd5b731cb17a6489352f10a735368f34d46d" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=70eb2c6b749d1499807a21e0bc4a6ef2614f90a4;hp=85e000a7ff584f162078086dd4c4a2a4fd960028;hb=f7b4fd5b731cb17a6489352f10a735368f34d46d;hpb=599eada420921192ceae6cb687f8a9950022044f" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fguide&amp;do=goto" > rel="nofollow">projects/funbot/guide</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=44c3d463280d7e275a6f93bd9633289f0872b686;hp=b67467c06eb95e96e22c9645100359f147b32ad1;hb=f7b4fd5b731cb17a6489352f10a735368f34d46d;hpb=599eada420921192ceae6cb687f8a9950022044f" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;do=goto" > rel="nofollow">projects/funbot/manual</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">10:15:37 PM 08/16/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=f7b4fd5b731cb17a6489352f10a735368f34d46d" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: update docs<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/15 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_599eada420921192ceae6cb687f8a9950022044f/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-16T18:43:49Z > + 2015-08-16T18:43:49Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-599eada420921192ceae6cb687f8a9950022044f" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=a466fadce2c88cde0347c164e7a49c97e32e1b13;hp=9fde6e22407a2eff47b1a666b3d3c274e5e19859;hb=599eada420921192ceae6cb687f8a9950022044f;hpb=2bf9de01bb378e4c9ed11cb7799ee03f12aed21b" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;do=goto" > rel="nofollow">projects/funbot/tickets/15</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">06:43:49 PM 08/16/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=599eada420921192ceae6cb687f8a9950022044f&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: the settings system needs callbacks<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/17 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_2bf9de01bb378e4c9ed11cb7799ee03f12aed21b/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-15T10:34:40Z > + 2015-08-15T10:34:40Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-2bf9de01bb378e4c9ed11cb7799ee03f12aed21b" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/17.mdwn;h=70f51944ac387924b6f8bf7433631a3baeb038a4;hp=0000000000000000000000000000000000000000;hb=2bf9de01bb378e4c9ed11cb7799ee03f12aed21b;hpb=0e840edc3dd9ec79ee219ba94cd63866eed668ea" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F17" > rel="nofollow">projects/funbot/tickets/17</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">10:34:40 AM 08/15/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=2bf9de01bb378e4c9ed11cb7799ee03f12aed21b" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: new ticket: avoid spamming with multi-commit pushes<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/16 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_0e840edc3dd9ec79ee219ba94cd63866eed668ea/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-13T16:57:09Z > + 2015-08-13T16:57:09Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-0e840edc3dd9ec79ee219ba94cd63866eed668ea" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/16.mdwn;h=15bbe0cb556feb7ed9000c36bb42a8396fb12921;hp=e62242d40f027b0491185be804ed929dc5a4ac7f;hb=0e840edc3dd9ec79ee219ba94cd63866eed668ea;hpb=f8d63be6c0d9119296673fb426e4a67f514397e0" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F16" > rel="nofollow">projects/funbot/tickets/16</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">04:57:09 PM 08/13/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=0e840edc3dd9ec79ee219ba94cd63866eed668ea&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: list existing feed related packages to review<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/16 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_f8d63be6c0d9119296673fb426e4a67f514397e0/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-13T07:23:09Z > + 2015-08-13T07:23:09Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-f8d63be6c0d9119296673fb426e4a67f514397e0" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/16.mdwn;h=e62242d40f027b0491185be804ed929dc5a4ac7f;hp=0000000000000000000000000000000000000000;hb=f8d63be6c0d9119296673fb426e4a67f514397e0;hpb=5b11daceee3ab50b30197cfa2ab5385b24a8dc73" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F16&amp;do=goto" > rel="nofollow">projects/funbot/tickets/16</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:23:09 AM 08/13/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=f8d63be6c0d9119296673fb426e4a67f514397e0" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: new ticket: announce RSS feeds<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to people/fr33domlover/veganism on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_5b11daceee3ab50b30197cfa2ab5385b24a8dc73/ > > + > + > + > + mm > + > + > + > + > + > + 2015-08-13T03:23:02Z > + 2015-08-13T03:23:02Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-5b11daceee3ab50b30197cfa2ab5385b24a8dc73" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/veganism.mdwn;h=b129c47a62a42f0e7094ea66ab4120c70bbf2956;hp=531aa72c9aa9be7cec113b57f7cd0792bd873cc4;hb=5b11daceee3ab50b30197cfa2ab5385b24a8dc73;hpb=bb1d1469396d107bdbbe314e87d3666cf530d297" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover%2Fveganism&amp;do=goto" > rel="nofollow">people/fr33domlover/veganism</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Fmm" > rel="nofollow">mm</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">web</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">03:23:02 AM 08/13/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=5b11daceee3ab50b30197cfa2ab5385b24a8dc73&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects projects/vcs-web-hook-parse > projects/vcs-web-hook-parse/tickets on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_bb1d1469396d107bdbbe314e87d3666cf530d297/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-10T13:29:45Z > + 2015-08-10T13:29:45Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-bb1d1469396d107bdbbe314e87d3666cf530d297" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=898655fcc20c4302682ffe196aa54e3afeb59b36;hp=8dc1b5dc39e41e5367ca9ba74882e13effdd2e49;hb=bb1d1469396d107bdbbe314e87d3666cf530d297;hpb=a815429ee204e00c48a0d72cc17456246e6040de" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects" > rel="nofollow">projects</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/vcs-web-hook-parse.mdwn;h=5128a0066c64cf95ed693d43e4b463adad27e2cb;hp=0000000000000000000000000000000000000000;hb=bb1d1469396d107bdbbe314e87d3666cf530d297;hpb=a815429ee204e00c48a0d72cc17456246e6040de" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fvcs-web-hook-parse" > rel="nofollow">projects/vcs-web-hook-parse</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/vcs-web-hook-parse/tickets.mdwn;h=5dea4f6f5c1bd6d7879c5773f8015c408511e55f;hp=0000000000000000000000000000000000000000;hb=bb1d1469396d107bdbbe314e87d3666cf530d297;hpb=a815429ee204e00c48a0d72cc17456246e6040de" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fvcs-web-hook-parse%2Ftickets&amp;do=goto" > rel="nofollow">projects/vcs-web-hook-parse/tickets</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">01:29:45 PM 08/10/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=bb1d1469396d107bdbbe314e87d3666cf530d297&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +vcs-web-hook-parse: new project, added dummy pages<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/guide projects/irc-fun-bot > projects/irc-fun-client projects/irc-fun-messages on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_a815429ee204e00c48a0d72cc17456246e6040de/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-09T14:20:44Z > + 2015-08-09T14:20:44Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-a815429ee204e00c48a0d72cc17456246e6040de" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=85e000a7ff584f162078086dd4c4a2a4fd960028;hp=fe77d4628d012fbba69fb4186054141ac9386e1e;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Fguide" > rel="nofollow">projects/funbot/guide</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot.mdwn;h=d16135bd1e6a372261567b700c147259d4e0f6af;hp=bbd523480202c43f2ad9cb96773d69fa16a29819;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-bot" > rel="nofollow">projects/irc-fun-bot</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-client.mdwn;h=cdac524a07d2eb092f858de8d4d8d8a0cfc0e8d7;hp=052a1471d2b01e04b9a250bd3ce5efda48e973e8;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-client&amp;do=goto" > rel="nofollow">projects/irc-fun-client</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages.mdwn;h=b793f23214f70270ed7da5b3699ad9efdabb5e77;hp=8a037a6b3176f58e7585d9442b98292313fca511;hb=a815429ee204e00c48a0d72cc17456246e6040de;hpb=63c70b3be856df4c006fabdafb301f9f47fa0b42" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-messages&amp;do=goto" > rel="nofollow">projects/irc-fun-messages</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">02:20:44 PM 08/09/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=a815429ee204e00c48a0d72cc17456246e6040de&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: update repo links after move to dev.<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/rel4tion/roadmap/release-00 on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_63c70b3be856df4c006fabdafb301f9f47fa0b42/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-09T12:25:39Z > + 2015-08-09T12:25:39Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-63c70b3be856df4c006fabdafb301f9f47fa0b42" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/rel4tion/roadmap/release-00.mdwn;h=ce02ef19c8176eb80c1fd5ca77cacfd6ef42a296;hp=b0297d9c7d79acf1fb70bf3029570491f97470c0;hb=63c70b3be856df4c006fabdafb301f9f47fa0b42;hpb=4114d7f291fe124c5169e1588bf3ba8828ea1955" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Frel4tion%2Froadmap%2Frelease-00&amp;do=goto" > rel="nofollow">projects/rel4tion/roadmap/release-00</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:25:39 PM 08/09/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=63c70b3be856df4c006fabdafb301f9f47fa0b42&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +rel4tion: update roadmap with recent work<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/rmtask on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_4114d7f291fe124c5169e1588bf3ba8828ea1955/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-09T11:34:25Z > + 2015-08-09T11:34:25Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-4114d7f291fe124c5169e1588bf3ba8828ea1955" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/rmtask.mdwn;h=e8a5548bd50de46c670e181aa5ab4af0b53336a5;hp=8081803ab94e9f415a0b16ddd06345163bda3541;hb=4114d7f291fe124c5169e1588bf3ba8828ea1955;hpb=a388b2d06814991f93f52276b8dfe18cd1627ef1" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=templates%2Frmtask" > rel="nofollow">templates/rmtask</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">11:34:25 AM 08/09/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=4114d7f291fe124c5169e1588bf3ba8828ea1955&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +templates: tweak rmtask colors<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/guide projects/funbot/manual > projects/funbot/tickets/7 projects/irc-fun-bot/tickets/3 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_a388b2d06814991f93f52276b8dfe18cd1627ef1/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-08T22:47:46Z > + 2015-08-08T22:47:46Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-a388b2d06814991f93f52276b8dfe18cd1627ef1" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=fe77d4628d012fbba69fb4186054141ac9386e1e;hp=6234c5babf562a6e0554c81171beb169c721b6de;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fguide&amp;do=goto" > rel="nofollow">projects/funbot/guide</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=b67467c06eb95e96e22c9645100359f147b32ad1;hp=4fb784a3bbd9efa372438f998917e996c95946d6;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;do=goto" > rel="nofollow">projects/funbot/manual</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/7.mdwn;h=24801b7b18518348ed77f49239ab071f106fe4ab;hp=edc5905349f54c32ce471d98c1434723aca026d5;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F7" > rel="nofollow">projects/funbot/tickets/7</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/3.mdwn;h=cf324dd4a0534fb640a72e516a58205b01917e28;hp=7ad03fd86056bf4892a412a1fc7c85838a36d170;hb=a388b2d06814991f93f52276b8dfe18cd1627ef1;hpb=5f028255a061f5e1405aae1f4bcf911086ddc4d9" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-bot%2Ftickets%2F3" > rel="nofollow">projects/irc-fun-bot/tickets/3</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">10:47:46 PM 08/08/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=a388b2d06814991f93f52276b8dfe18cd1627ef1&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: ticket and doc updates<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/2 > projects/http-listen/tickets/2 projects/irc-fun-bot/tickets/3 on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_5f028255a061f5e1405aae1f4bcf911086ddc4d9/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-06T13:37:56Z > + 2015-08-06T13:37:56Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-5f028255a061f5e1405aae1f4bcf911086ddc4d9" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=2cc56bb7968465ca690ebcbed6ed5a5213fb8a0c;hp=2db571641ae6d30d6d74d401e2e96015b833b811;hb=5f028255a061f5e1405aae1f4bcf911086ddc4d9;hpb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F2" > rel="nofollow">projects/funbot/tickets/2</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/tickets/2.mdwn;h=083e030badb159f80bb13af5c2ec169c24e4874e;hp=0000000000000000000000000000000000000000;hb=5f028255a061f5e1405aae1f4bcf911086ddc4d9;hpb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fhttp-listen%2Ftickets%2F2" > rel="nofollow">projects/http-listen/tickets/2</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/3.mdwn;h=7ad03fd86056bf4892a412a1fc7c85838a36d170;hp=9a3b0698a4094f4fdc31af182d9233e45bdd5928;hb=5f028255a061f5e1405aae1f4bcf911086ddc4d9;hpb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F3&amp;do=goto" > rel="nofollow">projects/irc-fun-bot/tickets/3</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">01:37:56 PM 08/06/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=5f028255a061f5e1405aae1f4bcf911086ddc4d9" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +some ticket updates<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/http-listen/tickets/1 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_c5b0bd2d44344346599c272f5f9f089cff3cd0cf/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-05T09:52:09Z > + 2015-08-05T09:52:09Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-c5b0bd2d44344346599c272f5f9f089cff3cd0cf" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/tickets/1.mdwn;h=0798820f782a817d904c7c077c4a2395ec33c171;hp=0000000000000000000000000000000000000000;hb=c5b0bd2d44344346599c272f5f9f089cff3cd0cf;hpb=abccb345fea04b01b45eed2a0f56c3c88988ebf0" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Ftickets%2F1&amp;do=goto" > rel="nofollow">projects/http-listen/tickets/1</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:52:09 AM 08/05/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=c5b0bd2d44344346599c272f5f9f089cff3cd0cf&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +http-listen: ope ticket about timeouts<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects projects/http-listen > projects/http-listen/decisions projects/http-listen/forum > projects/http-listen/news projects/http-listen/releases > projects/http-listen/tickets shortcuts on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_abccb345fea04b01b45eed2a0f56c3c88988ebf0/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-05T09:23:20Z > + 2015-08-05T09:23:20Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-abccb345fea04b01b45eed2a0f56c3c88988ebf0" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=8dc1b5dc39e41e5367ca9ba74882e13effdd2e49;hp=8a382bc0b1a8668b14aad89aa4bc16711a1ed84a;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects" > rel="nofollow">projects</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen.mdwn;h=7034ea4798f3d24ebcebd4c02cdd3865c245924d;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen&amp;do=goto" > rel="nofollow">projects/http-listen</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/decisions.mdwn;h=1a96e79ec55bb6bb817136a2ee3c333e4bbf4c36;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fhttp-listen%2Fdecisions" > rel="nofollow">projects/http-listen/decisions</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/forum.mdwn;h=b4032d88892110263de936a7f9ef6c7f8f7d755b;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Fforum&amp;do=goto" > rel="nofollow">projects/http-listen/forum</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/news.mdwn;h=a52d3fd6fc03f44418a4db0ccd745b3f53d6d81d;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fhttp-listen%2Fnews" > rel="nofollow">projects/http-listen/news</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/releases.mdwn;h=36687b2803485acb11d99138e4b5d9b1d40a177a;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Freleases&amp;do=goto" > rel="nofollow">projects/http-listen/releases</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/http-listen/tickets.mdwn;h=36e5aefaceccf9996d9dcf98239267d20c895455;hp=0000000000000000000000000000000000000000;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fhttp-listen%2Ftickets&amp;do=goto" > rel="nofollow">projects/http-listen/tickets</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=shortcuts.mdwn;h=848c9edfe10d412737a37883ff955dbee20089cb;hp=955fe6213cd0b74a022cb19d9a82986422a5ac7c;hb=abccb345fea04b01b45eed2a0f56c3c88988ebf0;hpb=3807c6e1a57de56dd0e0502a1fe7020d089048c5" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=shortcuts&amp;do=goto" > rel="nofollow">shortcuts</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:23:20 AM 08/05/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=abccb345fea04b01b45eed2a0f56c3c88988ebf0" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +http-listen: new project<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/kiwi/data/idan-files/todo.idan on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_3807c6e1a57de56dd0e0502a1fe7020d089048c5/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-01T21:21:43Z > + 2015-08-01T21:21:43Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-3807c6e1a57de56dd0e0502a1fe7020d089048c5" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/kiwi/data/idan-files/todo.idan;h=ccb6b70db2f4b5da7fa5d3a70c1ddc8cd9f1a33e;hp=eace9d20f6dd5d83087bc751aead7446aca7e575;hb=3807c6e1a57de56dd0e0502a1fe7020d089048c5;hpb=dd747340fffdb41ba4ff5066356b22dbffd73c98" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fkiwi%2Fdata%2Fidan-files%2Ftodo.idan&amp;do=goto" > rel="nofollow">projects/kiwi/data/idan-files/todo.idan</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:21:43 PM 08/01/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=3807c6e1a57de56dd0e0502a1fe7020d089048c5&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +kiwi: tasks-tui requires new entities<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to news/darcs-hub-new on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_dd747340fffdb41ba4ff5066356b22dbffd73c98/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-08-01T11:35:10Z > + 2015-08-01T11:35:10Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-dd747340fffdb41ba4ff5066356b22dbffd73c98" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=news/darcs-hub-new.mdwn;h=d1cbc5d5d35452c5272006db744779409c9b8505;hp=0000000000000000000000000000000000000000;hb=dd747340fffdb41ba4ff5066356b22dbffd73c98;hpb=65c40fbb77b5f797a67493716418ed0115a160cf" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=news%2Fdarcs-hub-new" > rel="nofollow">news/darcs-hub-new</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">11:35:10 AM 08/01/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=dd747340fffdb41ba4ff5066356b22dbffd73c98" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +news: new darcs hub<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/vocabularies-hs on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_65c40fbb77b5f797a67493716418ed0115a160cf/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-31T08:44:15Z > + 2015-07-31T08:44:15Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-65c40fbb77b5f797a67493716418ed0115a160cf" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/vocabularies-hs.mdwn;h=a21d0e3f8540fe73f4e9591a313c911aed6e6252;hp=c56d2d47ee0fe9de02ef44b045edc516cfe756e6;hb=65c40fbb77b5f797a67493716418ed0115a160cf;hpb=f0986cdfd3174159052ac1d3da6e1180dfb9a644" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fvocabularies-hs&amp;do=goto" > rel="nofollow">projects/vocabularies-hs</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">08:44:15 AM 07/31/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=65c40fbb77b5f797a67493716418ed0115a160cf" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +vocabularies-hs: list the new vocabulary-todo<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/kiwi/data/idan-files/todo.idan on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_f0986cdfd3174159052ac1d3da6e1180dfb9a644/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-29T23:28:20Z > + 2015-07-29T23:28:20Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-f0986cdfd3174159052ac1d3da6e1180dfb9a644" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/kiwi/data/idan-files/todo.idan;h=eace9d20f6dd5d83087bc751aead7446aca7e575;hp=9dd53e5a54d1add44987b39afc376c6d16a2e467;hb=f0986cdfd3174159052ac1d3da6e1180dfb9a644;hpb=c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fkiwi%2Fdata%2Fidan-files%2Ftodo.idan" > rel="nofollow">projects/kiwi/data/idan-files/todo.idan</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">11:28:20 PM 07/29/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=f0986cdfd3174159052ac1d3da6e1180dfb9a644&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +kiwi: manually add uids needed for coding<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/task-management on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-29T21:09:24Z > + 2015-07-29T21:09:24Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management.mdwn;h=852b193c67147e825e7426c09906641acf1dc5fa;hp=1f188daada9a5897e3bd452afbf20e11b08a9c01;hb=c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da;hpb=696ceb85012bff250079824aa5ccf4b526031427" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ftask-management" > rel="nofollow">projects/task-management</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:09:24 PM 07/29/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=c2ec1d098f1cc5a41435ed5c28bf87fe8f6057da" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +task-management: update project status<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/task-management/tickets/1 > projects/task-management/tickets/1/operations > projects/task-management/tickets/1/possible-features > projects/task-management/tickets/1/ui > projects/task-management/tickets/1/views projects/tui on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_696ceb85012bff250079824aa5ccf4b526031427/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-29T06:51:46Z > + 2015-07-29T06:51:46Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-696ceb85012bff250079824aa5ccf4b526031427" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1.mdwn;h=e1a899675f53d52ee329abd44daf3a99c7f10cad;hp=1e660face13843a722026d94ec4c2f51b2160069;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ftask-management%2Ftickets%2F1&amp;do=goto" > rel="nofollow">projects/task-management/tickets/1</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/operations.mdwn;h=6aa5582ae854c858059089ce638194a861d92b72;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ftask-management%2Ftickets%2F1%2Foperations&amp;do=goto" > rel="nofollow">projects/task-management/tickets/1/operations</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/possible-features.mdwn;h=78a47438fe2c9d00a0ab47f99c0b64c7a801eb0f;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ftask-management%2Ftickets%2F1%2Fpossible-features" > rel="nofollow">projects/task-management/tickets/1/possible-features</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/ui.mdwn;h=debe4c625183ab3fce85cb2aa7b371e08fb2d29e;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ftask-management%2Ftickets%2F1%2Fui&amp;do=goto" > rel="nofollow">projects/task-management/tickets/1/ui</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1/views.mdwn;h=4c3f149808ad74fba579947f393b4f6a21e62bab;hp=0000000000000000000000000000000000000000;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ftask-management%2Ftickets%2F1%2Fviews" > rel="nofollow">projects/task-management/tickets/1/views</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/tui.mdwn;h=707ea3237ed79a556340a96e60094beb969f0403;hp=ed4986fab9a9c1d0a320e0aebbd548e2046f94a8;hb=696ceb85012bff250079824aa5ccf4b526031427;hpb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ftui" > rel="nofollow">projects/tui</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">06:51:46 AM 07/29/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=696ceb85012bff250079824aa5ccf4b526031427&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +task-management: more plans<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/task-management/tickets/1 on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-28T12:58:05Z > + 2015-07-28T12:58:05Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/task-management/tickets/1.mdwn;h=1e660face13843a722026d94ec4c2f51b2160069;hp=30461446304a9c48ebbcdf9004b5e046abf60f39;hb=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e;hpb=16c22f6a025e24ca916e8312b3b5fe9146858523" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ftask-management%2Ftickets%2F1" > rel="nofollow">projects/task-management/tickets/1</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:58:05 PM 07/28/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=acf45a5f2a24ba04a35e9f0d8d590bf0a41c0f3e" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +minor edit<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects projects/tui on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_16c22f6a025e24ca916e8312b3b5fe9146858523/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-28T12:56:11Z > + 2015-07-28T12:56:11Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-16c22f6a025e24ca916e8312b3b5fe9146858523" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=8a382bc0b1a8668b14aad89aa4bc16711a1ed84a;hp=ec5984beb457557cddbd8d1ea7df80db9d42a705;hb=16c22f6a025e24ca916e8312b3b5fe9146858523;hpb=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;do=goto" > rel="nofollow">projects</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/tui.mdwn;h=ed4986fab9a9c1d0a320e0aebbd548e2046f94a8;hp=0000000000000000000000000000000000000000;hb=16c22f6a025e24ca916e8312b3b5fe9146858523;hpb=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ftui" > rel="nofollow">projects/tui</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:56:11 PM 07/28/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=16c22f6a025e24ca916e8312b3b5fe9146858523" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +tui: research project<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/10 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-27T22:30:00Z > + 2015-07-27T22:30:00Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/10.mdwn;h=2dfa6c5aa076d72de618c647a17774e23cacf78f;hp=7db97bbee99f558e4dc6164e60ef81504d4afe24;hb=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c;hpb=3d15ff1b8068e97901410a3d210227036bf528c5" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F10&amp;do=goto" > rel="nofollow">projects/funbot/tickets/10</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">10:30:00 PM 07/27/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=c8f6c3fca3796e7b4ee0148cab287d6ba5866f6c&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: update status of hello replies<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/15 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_3d15ff1b8068e97901410a3d210227036bf528c5/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-27T21:43:34Z > + 2015-07-27T21:43:34Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-3d15ff1b8068e97901410a3d210227036bf528c5" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=9fde6e22407a2eff47b1a666b3d3c274e5e19859;hp=8409ef6dc3f7697857b7aacdfc1d0d03ebd8e97b;hb=3d15ff1b8068e97901410a3d210227036bf528c5;hpb=2af6df1680072d6e73f4bdb07fae2c88a59c76aa" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;do=goto" > rel="nofollow">projects/funbot/tickets/15</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:43:34 PM 07/27/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=3d15ff1b8068e97901410a3d210227036bf528c5&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: update status of settings system<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/guide projects/funbot/manual on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_2af6df1680072d6e73f4bdb07fae2c88a59c76aa/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-27T21:33:18Z > + 2015-07-27T21:33:18Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-2af6df1680072d6e73f4bdb07fae2c88a59c76aa" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=6234c5babf562a6e0554c81171beb169c721b6de;hp=9d46ed7be13811c424111b5f29dc6ef641e5754a;hb=2af6df1680072d6e73f4bdb07fae2c88a59c76aa;hpb=617249a360c6973ce7f42ad010f1276c552fbaf1" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Fguide" > rel="nofollow">projects/funbot/guide</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=4fb784a3bbd9efa372438f998917e996c95946d6;hp=f179ef3cc7731f76ad0bae8b31a4e64a3f8d6871;hb=2af6df1680072d6e73f4bdb07fae2c88a59c76aa;hpb=617249a360c6973ce7f42ad010f1276c552fbaf1" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Fmanual&amp;do=goto" > rel="nofollow">projects/funbot/manual</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:33:18 PM 07/27/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=2af6df1680072d6e73f4bdb07fae2c88a59c76aa" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: update docs to match the newly added settings system<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects projects/funbot/tickets/15 > projects/settings projects/settings/decisions projects/settings/forum > projects/settings/news projects/settings/releases projects/settings/tickets > on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_617249a360c6973ce7f42ad010f1276c552fbaf1/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-22T09:46:41Z > + 2015-07-22T09:46:41Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-617249a360c6973ce7f42ad010f1276c552fbaf1" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=ec5984beb457557cddbd8d1ea7df80db9d42a705;hp=9d82d759e2e847c0b174cf1bbe7f57d75c14474f;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects" > rel="nofollow">projects</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=8409ef6dc3f7697857b7aacdfc1d0d03ebd8e97b;hp=a19cd36f2568480158c63ddec2185754cab96f30;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F15" > rel="nofollow">projects/funbot/tickets/15</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings.mdwn;h=b7f5ffc7ee35f85a7a7d5094fdc02c578122825e;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fsettings" > rel="nofollow">projects/settings</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/decisions.mdwn;h=7fa56d100854163543f12f83cc1408ae417f9f7e;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Fdecisions&amp;do=goto" > rel="nofollow">projects/settings/decisions</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/forum.mdwn;h=c3b79bd4409643fdbc11a700b29898f904b315b7;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fsettings%2Fforum" > rel="nofollow">projects/settings/forum</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/news.mdwn;h=837c8697a653db420eada75ea57630492eb8338e;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Fnews&amp;do=goto" > rel="nofollow">projects/settings/news</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/releases.mdwn;h=e4efd9b315242da6e04f9e94546ed3522bdaac68;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Fsettings%2Freleases" > rel="nofollow">projects/settings/releases</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/settings/tickets.mdwn;h=e9398e875cda45921bd91361adb0716986869a15;hp=0000000000000000000000000000000000000000;hb=617249a360c6973ce7f42ad010f1276c552fbaf1;hpb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsettings%2Ftickets&amp;do=goto" > rel="nofollow">projects/settings/tickets</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:46:41 AM 07/22/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=617249a360c6973ce7f42ad010f1276c552fbaf1" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +settings: *another* new project...<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/15 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_5f4444298ebe3f674b73a843dfc7bbef7a1703e7/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-21T10:47:23Z > + 2015-07-21T10:47:23Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-5f4444298ebe3f674b73a843dfc7bbef7a1703e7" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=a19cd36f2568480158c63ddec2185754cab96f30;hp=038b445accf173eee423a1a03eab722fe86ef030;hb=5f4444298ebe3f674b73a843dfc7bbef7a1703e7;hpb=76a709cf4777cf20cf18b62c3e557f380b98a145" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F15" > rel="nofollow">projects/funbot/tickets/15</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">10:47:23 AM 07/21/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=5f4444298ebe3f674b73a843dfc7bbef7a1703e7" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: notes about settings system<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/15 > projects/funbot/tickets/4 projects/irc-fun-client/tickets/2 on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_76a709cf4777cf20cf18b62c3e557f380b98a145/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-20T12:22:27Z > + 2015-07-20T12:22:27Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-76a709cf4777cf20cf18b62c3e557f380b98a145" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/15.mdwn;h=038b445accf173eee423a1a03eab722fe86ef030;hp=0000000000000000000000000000000000000000;hb=76a709cf4777cf20cf18b62c3e557f380b98a145;hpb=f65b75264b89071970cf00ff16776aa9d5969437" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F15&amp;do=goto" > rel="nofollow">projects/funbot/tickets/15</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/4.mdwn;h=071cb7e64ae57c211834ee5cc7e80132209a6bc2;hp=7665ef7035b4387f9ceb84ca9cd79130b81d4d48;hb=76a709cf4777cf20cf18b62c3e557f380b98a145;hpb=f65b75264b89071970cf00ff16776aa9d5969437" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F4" > rel="nofollow">projects/funbot/tickets/4</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-client/tickets/2.mdwn;h=ae578674d3cceaaa6cbe726d632bc3c4e87bfd55;hp=0000000000000000000000000000000000000000;hb=76a709cf4777cf20cf18b62c3e557f380b98a145;hpb=f65b75264b89071970cf00ff16776aa9d5969437" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-client%2Ftickets%2F2&amp;do=goto" > rel="nofollow">projects/irc-fun-client/tickets/2</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:22:27 PM 07/20/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=76a709cf4777cf20cf18b62c3e557f380b98a145" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: more tickets...<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/irc-fun-messages/tickets/2 on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_f65b75264b89071970cf00ff16776aa9d5969437/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-20T09:12:23Z > + 2015-07-20T09:12:23Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-f65b75264b89071970cf00ff16776aa9d5969437" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/2.mdwn;h=e4e35c75ededb220d4ee788abd52f17ab0510352;hp=b97c3b915afa5aee1527549c97939c20979e11ba;hb=f65b75264b89071970cf00ff16776aa9d5969437;hpb=b0d2b4a707f9b0bbe5373a5ad960487b66142b41" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-messages%2Ftickets%2F2" > rel="nofollow">projects/irc-fun-messages/tickets/2</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:12:23 AM 07/20/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=f65b75264b89071970cf00ff16776aa9d5969437" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +irc-fun-messages: rearrangemet done<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/my-open-tickets on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_b0d2b4a707f9b0bbe5373a5ad960487b66142b41/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-20T09:09:43Z > + 2015-07-20T09:09:43Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-b0d2b4a707f9b0bbe5373a5ad960487b66142b41" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/my-open-tickets.mdwn;h=d5fc4b5cd9696f21ab75842518f2b7a4f5fd2ebc;hp=6508a11cf60dd90ba71b998848e829d385c495d2;hb=b0d2b4a707f9b0bbe5373a5ad960487b66142b41;hpb=7bc4f88b58f7f0deadb8a79a9823a564cf399b03" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fmy-open-tickets&amp;do=goto" > rel="nofollow">templates/my-open-tickets</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:09:43 AM 07/20/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=b0d2b4a707f9b0bbe5373a5ad960487b66142b41" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +fix template typo<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to people/fr33domlover on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_7bc4f88b58f7f0deadb8a79a9823a564cf399b03/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-20T09:06:01Z > + 2015-07-20T09:06:01Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-7bc4f88b58f7f0deadb8a79a9823a564cf399b03" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover.mdwn;h=2230d818ac803844191d7842bcb24fa4d5e45e14;hp=f28b90121dbd2ea1427b476ec65ac299d5a362a7;hb=7bc4f88b58f7f0deadb8a79a9823a564cf399b03;hpb=e970fbaa161547af8a7b378220a602c00c128b20" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">people/fr33domlover</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:06:01 AM 07/20/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=7bc4f88b58f7f0deadb8a79a9823a564cf399b03&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +me: use the new template for personal tickets<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/my-open-tickets templates/ticket > tickets on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_e970fbaa161547af8a7b378220a602c00c128b20/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-20T09:02:35Z > + 2015-07-20T09:02:35Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-e970fbaa161547af8a7b378220a602c00c128b20" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/my-open-tickets.mdwn;h=6508a11cf60dd90ba71b998848e829d385c495d2;hp=0000000000000000000000000000000000000000;hb=e970fbaa161547af8a7b378220a602c00c128b20;hpb=f650bd6d11c9f12fa342e32a1112e0326f5983a0" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fmy-open-tickets&amp;do=goto" > rel="nofollow">templates/my-open-tickets</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket.mdwn;h=69a8e86734dca4aec465f6d7fc4f7d6b958e9a51;hp=7adaf50d169a1a3e068b272427c5ccd010b304ea;hb=e970fbaa161547af8a7b378220a602c00c128b20;hpb=f650bd6d11c9f12fa342e32a1112e0326f5983a0" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket&amp;do=goto" > rel="nofollow">templates/ticket</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=tickets.mdwn;h=3b3e0f3959d65e0100c507940f20921dbad4220a;hp=b28306347b2b49e222ec75f0610cfceff8ff7598;hb=e970fbaa161547af8a7b378220a602c00c128b20;hpb=f650bd6d11c9f12fa342e32a1112e0326f5983a0" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=tickets" > rel="nofollow">tickets</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:02:35 AM 07/20/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=e970fbaa161547af8a7b378220a602c00c128b20&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +new template my-open-tickets<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to tickets on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_f650bd6d11c9f12fa342e32a1112e0326f5983a0/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-20T07:58:09Z > + 2015-07-20T07:58:09Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-f650bd6d11c9f12fa342e32a1112e0326f5983a0" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=tickets.mdwn;h=b28306347b2b49e222ec75f0610cfceff8ff7598;hp=bfc33e243c877bdc29e26067fcccf60865b950f8;hb=f650bd6d11c9f12fa342e32a1112e0326f5983a0;hpb=62e6b115766812a8b7dc1661af21071b300ecf9d" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=tickets&amp;do=goto" > rel="nofollow">tickets</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:58:09 AM 07/20/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=f650bd6d11c9f12fa342e32a1112e0326f5983a0&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +tickets: add some notes and hints<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/2 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_62e6b115766812a8b7dc1661af21071b300ecf9d/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-20T07:26:24Z > + 2015-07-20T07:26:24Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-62e6b115766812a8b7dc1661af21071b300ecf9d" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=2db571641ae6d30d6d74d401e2e96015b833b811;hp=ddf42fa6367bcebe483831befd8a9739a418eb69;hb=62e6b115766812a8b7dc1661af21071b300ecf9d;hpb=d1a178ecde1695f74f21132068fa479443fd364f" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Ffunbot%2Ftickets%2F2&amp;do=goto" > rel="nofollow">projects/funbot/tickets/2</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:26:24 AM 07/20/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=62e6b115766812a8b7dc1661af21071b300ecf9d" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: list options for persistence<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/2 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_d1a178ecde1695f74f21132068fa479443fd364f/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-19T21:12:25Z > + 2015-07-19T21:12:25Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-d1a178ecde1695f74f21132068fa479443fd364f" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/2.mdwn;h=ddf42fa6367bcebe483831befd8a9739a418eb69;hp=767aaad5c981d66c8cc3f76b8ffd0b8a172c5840;hb=d1a178ecde1695f74f21132068fa479443fd364f;hpb=9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F2" > rel="nofollow">projects/funbot/tickets/2</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:12:25 PM 07/19/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=d1a178ecde1695f74f21132068fa479443fd364f&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: notes on persistent state<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to people/fr33domlover/blog/insanity on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-19T20:28:42Z > + 2015-07-19T20:28:42Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover/blog/insanity.mdwn;h=ebaa53ca277a0e595b242642aeed217a2d596b54;hp=0000000000000000000000000000000000000000;hb=9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a;hpb=6f2e5495944f200e1e6dd231d85ecbdfbb1aa372" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover%2Fblog%2Finsanity&amp;do=goto" > rel="nofollow">people/fr33domlover/blog/insanity</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">08:28:42 PM 07/19/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=9aacf3255d7b2d65ff1a4a3e564e0cc35df5864a" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +me: some blog post...<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/ticket-depends-on on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_6f2e5495944f200e1e6dd231d85ecbdfbb1aa372/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-19T09:26:58Z > + 2015-07-19T09:26:58Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-6f2e5495944f200e1e6dd231d85ecbdfbb1aa372" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=f83eb1c67a3ccac4e181ab4fba9a9dff0a6b6a80;hp=a7f05948f92be66460fa39f2d7ac61c863886994;hb=6f2e5495944f200e1e6dd231d85ecbdfbb1aa372;hpb=b3db4bb425ef79edc4269c0ad57e47685eb888b7" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;do=goto" > rel="nofollow">templates/ticket-depends-on</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:26:58 AM 07/19/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=6f2e5495944f200e1e6dd231d85ecbdfbb1aa372&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +if failing, at least fail explicitly<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/ticket-depends-on on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_b3db4bb425ef79edc4269c0ad57e47685eb888b7/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-19T09:15:03Z > + 2015-07-19T09:15:03Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-b3db4bb425ef79edc4269c0ad57e47685eb888b7" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=a7f05948f92be66460fa39f2d7ac61c863886994;hp=0279afa3d1b2bb1796ba9e32955894c6e8436c5e;hb=b3db4bb425ef79edc4269c0ad57e47685eb888b7;hpb=5b2a8e163184284378d48d2419134d6f5e4fabbe" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=templates%2Fticket-depends-on" > rel="nofollow">templates/ticket-depends-on</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:15:03 AM 07/19/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=b3db4bb425ef79edc4269c0ad57e47685eb888b7&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +last try, I have no idea about those variables<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/ticket-depends-on on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_5b2a8e163184284378d48d2419134d6f5e4fabbe/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-19T09:00:55Z > + 2015-07-19T09:00:55Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-5b2a8e163184284378d48d2419134d6f5e4fabbe" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=0279afa3d1b2bb1796ba9e32955894c6e8436c5e;hp=6e5d9e5744a8b7f07502689526a0bb398df695a6;hb=5b2a8e163184284378d48d2419134d6f5e4fabbe;hpb=476809c178ec0873f4580309443add856c64f339" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;do=goto" > rel="nofollow">templates/ticket-depends-on</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">09:00:55 AM 07/19/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=5b2a8e163184284378d48d2419134d6f5e4fabbe" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +try again<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/ticket-depends-on on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_476809c178ec0873f4580309443add856c64f339/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-19T08:43:09Z > + 2015-07-19T08:43:09Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-476809c178ec0873f4580309443add856c64f339" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=6e5d9e5744a8b7f07502689526a0bb398df695a6;hp=f83eb1c67a3ccac4e181ab4fba9a9dff0a6b6a80;hb=476809c178ec0873f4580309443add856c64f339;hpb=42242ce1aeb36d653d3312ee46603ca1baeb5f78" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;do=goto" > rel="nofollow">templates/ticket-depends-on</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">08:43:09 AM 07/19/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=476809c178ec0873f4580309443add856c64f339&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +try to fix local ticket dependency template<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/irc-fun-bot/tickets/5 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_42242ce1aeb36d653d3312ee46603ca1baeb5f78/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-19T00:52:24Z > + 2015-07-19T00:52:24Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-42242ce1aeb36d653d3312ee46603ca1baeb5f78" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=b9debec3ded1ba8f5151f21acfc3ce6f340f9d06;hp=0e5a1030b7c2ef5dbd1c505352d9172e94bf04d3;hb=42242ce1aeb36d653d3312ee46603ca1baeb5f78;hpb=bd0e46e488bbeb8b216f6ab1aefd98083ec61f16" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F5&amp;do=goto" > rel="nofollow">projects/irc-fun-bot/tickets/5</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:52:24 AM 07/19/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=42242ce1aeb36d653d3312ee46603ca1baeb5f78&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +fix typo<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/irc-fun-bot/tickets/5 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_bd0e46e488bbeb8b216f6ab1aefd98083ec61f16/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-19T00:48:08Z > + 2015-07-19T00:48:08Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-bd0e46e488bbeb8b216f6ab1aefd98083ec61f16" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=0e5a1030b7c2ef5dbd1c505352d9172e94bf04d3;hp=fac452baf181d140dfd541dd3e348b03f4387a1a;hb=bd0e46e488bbeb8b216f6ab1aefd98083ec61f16;hpb=e048d2ba90a4e6f94784c809618051f00a863627" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F5&amp;do=goto" > rel="nofollow">projects/irc-fun-bot/tickets/5</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:48:08 AM 07/19/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=bd0e46e488bbeb8b216f6ab1aefd98083ec61f16&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +irc-fun-bot: close ticket 5, user tracking works<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/tktref on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_e048d2ba90a4e6f94784c809618051f00a863627/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-18T16:18:02Z > + 2015-07-18T16:18:02Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-e048d2ba90a4e6f94784c809618051f00a863627" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/tktref.mdwn;h=a0c97a7571758f0b9ecbdd87da123ddc23e3add3;hp=fc64ea4a97b82588f1cb5c72d9875cbedc196f6b;hb=e048d2ba90a4e6f94784c809618051f00a863627;hpb=64fc69565cd08b8438d34b6453840eec6c328677" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Ftktref&amp;do=goto" > rel="nofollow">templates/tktref</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">04:18:02 PM 07/18/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=e048d2ba90a4e6f94784c809618051f00a863627&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +try to fix tktlink rendering<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/irc-fun-bot/tickets/5 > projects/irc-fun-messages/tickets/1 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_64fc69565cd08b8438d34b6453840eec6c328677/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-18T16:13:16Z > + 2015-07-18T16:13:16Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-64fc69565cd08b8438d34b6453840eec6c328677" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=fac452baf181d140dfd541dd3e348b03f4387a1a;hp=c3fda7dceeea8bd5b28f491e969db289e813a59a;hb=64fc69565cd08b8438d34b6453840eec6c328677;hpb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-bot%2Ftickets%2F5" > rel="nofollow">projects/irc-fun-bot/tickets/5</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/1.mdwn;h=b591bb5228526e4e0c28619d1d51642bd35db0ca;hp=9ef221af24707831f812d2a735fcfa1ed60c2188;hb=64fc69565cd08b8438d34b6453840eec6c328677;hpb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-messages%2Ftickets%2F1&amp;do=goto" > rel="nofollow">projects/irc-fun-messages/tickets/1</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">04:13:16 PM 07/18/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=64fc69565cd08b8438d34b6453840eec6c328677&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +irc-fun-*: reply analysis added, now track nicknames<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects projects/irc-fun-color > projects/irc-fun-color/decisions projects/irc-fun-color/forum > projects/irc-fun-color/news projects/irc-fun-color/releases > projects/irc-fun-color/tickets on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-18T15:08:45Z > + 2015-07-18T15:08:45Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects.mdwn;h=9d82d759e2e847c0b174cf1bbe7f57d75c14474f;hp=2f60c659996eb1080d7af967e9041d62d77d84c9;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects&amp;do=goto" > rel="nofollow">projects</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color.mdwn;h=55a94ef29608a2cf99061cfff38117975ad31fa3;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-color" > rel="nofollow">projects/irc-fun-color</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/decisions.mdwn;h=86674bf28a1eac5aa6a8f6bf02a5f3611fae5afe;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-color%2Fdecisions&amp;do=goto" > rel="nofollow">projects/irc-fun-color/decisions</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/forum.mdwn;h=f297d56c4a7e9099c511dafd8deeec28222e3e17;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-color%2Fforum" > rel="nofollow">projects/irc-fun-color/forum</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/news.mdwn;h=330c55f6fd7f2c4a010044249adcb5456d9658a3;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-color%2Fnews&amp;do=goto" > rel="nofollow">projects/irc-fun-color/news</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/releases.mdwn;h=57e5729d6313d999900ce903adcc35389f4686bb;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-color%2Freleases&amp;do=goto" > rel="nofollow">projects/irc-fun-color/releases</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-color/tickets.mdwn;h=707729b4f5edb530c7493f701639e14441ece6fb;hp=0000000000000000000000000000000000000000;hb=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8;hpb=3d1ea877911070c0d95bb46c10568bde7b956ae6" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-color%2Ftickets" > rel="nofollow">projects/irc-fun-color/tickets</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">03:08:45 PM 07/18/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=9cf06f38584d7b9c6e9a1c29a8fde5ff7a1836b8&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +irc-fun-color: new project<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/ticket-depends-on on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_3d1ea877911070c0d95bb46c10568bde7b956ae6/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-17T12:13:32Z > + 2015-07-17T12:13:32Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-3d1ea877911070c0d95bb46c10568bde7b956ae6" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=f83eb1c67a3ccac4e181ab4fba9a9dff0a6b6a80;hp=36db3bfac2156cf7980068af0606bf464cd5b6ec;hb=3d1ea877911070c0d95bb46c10568bde7b956ae6;hpb=5361eae41a1dbd74b511f97df16687a0278063d6" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;do=goto" > rel="nofollow">templates/ticket-depends-on</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:13:32 PM 07/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=3d1ea877911070c0d95bb46c10568bde7b956ae6" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +template: try to make ticket-depends-on render as a single line<br > /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/tktref on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_5361eae41a1dbd74b511f97df16687a0278063d6/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-17T12:07:39Z > + 2015-07-17T12:07:39Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-5361eae41a1dbd74b511f97df16687a0278063d6" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/tktref.mdwn;h=fc64ea4a97b82588f1cb5c72d9875cbedc196f6b;hp=cc3d879c0f434325cf3e0a35768810a4d4c40cb3;hb=5361eae41a1dbd74b511f97df16687a0278063d6;hpb=8acf634f485a70e7f54faa48d5ceaff705849359" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=templates%2Ftktref" > rel="nofollow">templates/tktref</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:07:39 PM 07/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=5361eae41a1dbd74b511f97df16687a0278063d6" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +templates: fix typo in tktref<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/ticket-dependants templates/ticket on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_8acf634f485a70e7f54faa48d5ceaff705849359/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-17T11:59:11Z > + 2015-07-17T11:59:11Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-8acf634f485a70e7f54faa48d5ceaff705849359" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-dependants.mdwn;h=8996711ad0b53f3acc95eb2fb577260f56f99589;hp=0000000000000000000000000000000000000000;hb=8acf634f485a70e7f54faa48d5ceaff705849359;hpb=4826e57427eb5fdc542b22534276401ef0e0a6bb" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=templates%2Fticket-dependants" > rel="nofollow">templates/ticket-dependants</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket.mdwn;h=7adaf50d169a1a3e068b272427c5ccd010b304ea;hp=cc70c7b4bcf5718cf457b8bc8f9760c3c2dec296;hb=8acf634f485a70e7f54faa48d5ceaff705849359;hpb=4826e57427eb5fdc542b22534276401ef0e0a6bb" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket&amp;do=goto" > rel="nofollow">templates/ticket</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">11:59:11 AM 07/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=8acf634f485a70e7f54faa48d5ceaff705849359&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +add ticket reverse dependencies using tags<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/10 > projects/funbot/tickets/3 projects/funbot/tickets/5 projects/idan/tickets/4 > projects/irc-fun-bot/tickets/5 > projects/sif/tickets/Remove_doxy_references_to_nonfree_browsers > projects/sif/tickets/Remove_unused_doxy_images templates/ticket-depends-on > on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_4826e57427eb5fdc542b22534276401ef0e0a6bb/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-17T11:27:55Z > + 2015-07-17T11:27:55Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-4826e57427eb5fdc542b22534276401ef0e0a6bb" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/10.mdwn;h=7db97bbee99f558e4dc6164e60ef81504d4afe24;hp=f679a8578818b1b59ef502b4e83d972a2696ba2a;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F10" > rel="nofollow">projects/funbot/tickets/10</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/3.mdwn;h=111efa1b015906623afc28c27ee52742a7cddbd8;hp=09da3b9886f12272ba40bde42dcb4ebbd0846de9;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F3" > rel="nofollow">projects/funbot/tickets/3</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/5.mdwn;h=606f28657913248cbfe3204aa6f0ffebec656b55;hp=f605f0ecc0227205dad3b5d4b16c4fdb85df5eb5;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F5" > rel="nofollow">projects/funbot/tickets/5</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/idan/tickets/4.mdwn;h=a4e6bd9fb63289481b2ebea90b374aa0236a604a;hp=e4f1d49482e7e2c66e404a9a0efcdc0bfb29950d;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fidan%2Ftickets%2F4&amp;do=goto" > rel="nofollow">projects/idan/tickets/4</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=c3fda7dceeea8bd5b28f491e969db289e813a59a;hp=215a25f288dfeb80ea06314a6c1b860a1476622e;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-bot%2Ftickets%2F5" > rel="nofollow">projects/irc-fun-bot/tickets/5</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/sif/tickets/Remove_doxy_references_to_nonfree_browsers.mdwn;h=944fb3a116e57ee64af34d891fa43327468b0228;hp=5b6919b3d065d46f997e6abb1f63130978a5e9af;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsif%2Ftickets%2FRemove_doxy_references_to_nonfree_browsers&amp;do=goto" > rel="nofollow">projects/sif/tickets/Remove doxy references to > nonfree browsers</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/sif/tickets/Remove_unused_doxy_images.mdwn;h=7f4205dd1dd777bbbf86e08147e73c427c66d984;hp=c54d10be8cc161461d2d1b535b29043cdbdb9fb6;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Fsif%2Ftickets%2FRemove_unused_doxy_images&amp;do=goto" > rel="nofollow">projects/sif/tickets/Remove unused doxy > images</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/ticket-depends-on.mdwn;h=36db3bfac2156cf7980068af0606bf464cd5b6ec;hp=55583bce2cd010f8cf8b3271621428169d3b57a2;hb=4826e57427eb5fdc542b22534276401ef0e0a6bb;hpb=2a4c41ea9590cd73e0aec952e93f745172a32217" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Fticket-depends-on&amp;do=goto" > rel="nofollow">templates/ticket-depends-on</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">11:27:55 AM 07/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=4826e57427eb5fdc542b22534276401ef0e0a6bb" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +templates: hopefully improve ticket-depends-on<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/irc-fun-bot/tickets/5 > projects/irc-fun-messages/tickets/1 projects/irc-fun-messages/tickets/2 on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_2a4c41ea9590cd73e0aec952e93f745172a32217/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-17T10:45:46Z > + 2015-07-17T10:45:46Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-2a4c41ea9590cd73e0aec952e93f745172a32217" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=215a25f288dfeb80ea06314a6c1b860a1476622e;hp=9c3b99793d6df15691e519bd472b674b37b871a6;hb=2a4c41ea9590cd73e0aec952e93f745172a32217;hpb=8fb78e1a159821745b973337a7267635a536f3fc" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-bot%2Ftickets%2F5" > rel="nofollow">projects/irc-fun-bot/tickets/5</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/1.mdwn;h=9ef221af24707831f812d2a735fcfa1ed60c2188;hp=0000000000000000000000000000000000000000;hb=2a4c41ea9590cd73e0aec952e93f745172a32217;hpb=8fb78e1a159821745b973337a7267635a536f3fc" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-messages%2Ftickets%2F1" > rel="nofollow">projects/irc-fun-messages/tickets/1</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-messages/tickets/2.mdwn;h=b97c3b915afa5aee1527549c97939c20979e11ba;hp=0000000000000000000000000000000000000000;hb=2a4c41ea9590cd73e0aec952e93f745172a32217;hpb=8fb78e1a159821745b973337a7267635a536f3fc" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-messages%2Ftickets%2F2&amp;do=goto" > rel="nofollow">projects/irc-fun-messages/tickets/2</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">10:45:46 AM 07/17/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=2a4c41ea9590cd73e0aec952e93f745172a32217&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +irc-fun-messages: open tickets for work being done<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/14 > projects/irc-fun-bot/tickets/6 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_8fb78e1a159821745b973337a7267635a536f3fc/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-16T12:50:22Z > + 2015-07-16T12:50:22Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-8fb78e1a159821745b973337a7267635a536f3fc" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/14.mdwn;h=ec589115c87f1e070cf74a0e74bd88fa16320fd5;hp=0000000000000000000000000000000000000000;hb=8fb78e1a159821745b973337a7267635a536f3fc;hpb=18355348f643f521d5172530761ce01abe472ed9" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F14" > rel="nofollow">projects/funbot/tickets/14</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/6.mdwn;h=dc30d1b5dbb1e84f25aebe68f2a00c626870469b;hp=0000000000000000000000000000000000000000;hb=8fb78e1a159821745b973337a7267635a536f3fc;hpb=18355348f643f521d5172530761ce01abe472ed9" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F6&amp;do=goto" > rel="nofollow">projects/irc-fun-bot/tickets/6</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Ffr33domlover&amp;do=goto" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:50:22 PM 07/16/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=8fb78e1a159821745b973337a7267635a536f3fc&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: tickets for Tox and OTR support<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/irc-fun-bot/tickets/5 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_18355348f643f521d5172530761ce01abe472ed9/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-15T12:43:41Z > + 2015-07-15T12:43:41Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-18355348f643f521d5172530761ce01abe472ed9" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/5.mdwn;h=9c3b99793d6df15691e519bd472b674b37b871a6;hp=17f55a86e0f23d45f9b2edb4f6daec60c2dc0d82;hb=18355348f643f521d5172530761ce01abe472ed9;hpb=143590cacdab92492eb6a14e53c9810f4432cd4b" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-bot%2Ftickets%2F5" > rel="nofollow">projects/irc-fun-bot/tickets/5</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:43:41 PM 07/15/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=18355348f643f521d5172530761ce01abe472ed9&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +irc-fun-bot: notes on online user tracking<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/irc-fun-bot/tickets/4 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_143590cacdab92492eb6a14e53c9810f4432cd4b/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-15T12:28:53Z > + 2015-07-15T12:28:53Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-143590cacdab92492eb6a14e53c9810f4432cd4b" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/4.mdwn;h=de50db2d43720e278918b08a15a70fb01065310c;hp=861efebe845edc70875723113005c9292a8181a6;hb=143590cacdab92492eb6a14e53c9810f4432cd4b;hpb=1d7deccdc53477739f5f644a14ddfc08276eb330" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-bot%2Ftickets%2F4" > rel="nofollow">projects/irc-fun-bot/tickets/4</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:28:53 PM 07/15/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=143590cacdab92492eb6a14e53c9810f4432cd4b" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +irc-fun-bot: close ticket 4, event handling implemented<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/commit templates/record on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_1d7deccdc53477739f5f644a14ddfc08276eb330/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-15T12:28:19Z > + 2015-07-15T12:28:19Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-1d7deccdc53477739f5f644a14ddfc08276eb330" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/commit.mdwn;h=2216a0ee714109c1860d714832f0a8e1935bdc0a;hp=e715dab0360f63da76233aa8d6018cb5511dd183;hb=1d7deccdc53477739f5f644a14ddfc08276eb330;hpb=74e38e99ab317f66273387b40a96f3817a9a269f" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=templates%2Fcommit" > rel="nofollow">templates/commit</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/record.mdwn;h=b6d048ab252338b6994ea0ee8b04b73db7a4a778;hp=cf2916d42321a35e788ca8121243e4e3e9a1ca3c;hb=1d7deccdc53477739f5f644a14ddfc08276eb330;hpb=74e38e99ab317f66273387b40a96f3817a9a269f" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Frecord&amp;do=goto" > rel="nofollow">templates/record</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:28:19 PM 07/15/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=1d7deccdc53477739f5f644a14ddfc08276eb330" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +templates: update record template link text<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to templates/commit templates/record on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_74e38e99ab317f66273387b40a96f3817a9a269f/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-15T11:38:43Z > + 2015-07-15T11:38:43Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-74e38e99ab317f66273387b40a96f3817a9a269f" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/commit.mdwn;h=e715dab0360f63da76233aa8d6018cb5511dd183;hp=0000000000000000000000000000000000000000;hb=74e38e99ab317f66273387b40a96f3817a9a269f;hpb=54fd05dc71003ad59211bf218528dd21f1386759" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=templates%2Fcommit" > rel="nofollow">templates/commit</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=templates/record.mdwn;h=cf2916d42321a35e788ca8121243e4e3e9a1ca3c;hp=0000000000000000000000000000000000000000;hb=74e38e99ab317f66273387b40a96f3817a9a269f;hpb=54fd05dc71003ad59211bf218528dd21f1386759" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=templates%2Frecord&amp;do=goto" > rel="nofollow">templates/record</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">11:38:43 AM 07/15/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=74e38e99ab317f66273387b40a96f3817a9a269f&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +templates: add git/darcs record templates<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/guide on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_54fd05dc71003ad59211bf218528dd21f1386759/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-15T11:38:19Z > + 2015-07-15T11:38:19Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-54fd05dc71003ad59211bf218528dd21f1386759" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/guide.mdwn;h=9d46ed7be13811c424111b5f29dc6ef641e5754a;hp=ac4c2f5842f1194f7e20148f70c265952cb990f9;hb=54fd05dc71003ad59211bf218528dd21f1386759;hpb=07d23f596ab3b6281acdd9f80768ab64b014bd49" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Fguide" > rel="nofollow">projects/funbot/guide</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">11:38:19 AM 07/15/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=54fd05dc71003ad59211bf218528dd21f1386759&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: add list of API features to the guide<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/irc-fun-bot/tickets/4 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_07d23f596ab3b6281acdd9f80768ab64b014bd49/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-15T00:24:59Z > + 2015-07-15T00:24:59Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-07d23f596ab3b6281acdd9f80768ab64b014bd49" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/4.mdwn;h=861efebe845edc70875723113005c9292a8181a6;hp=4cda87eb8f895f7dee560b8df646d1c7d5e4601a;hb=07d23f596ab3b6281acdd9f80768ab64b014bd49;hpb=2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Firc-fun-bot%2Ftickets%2F4" > rel="nofollow">projects/irc-fun-bot/tickets/4</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:24:59 AM 07/15/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=07d23f596ab3b6281acdd9f80768ab64b014bd49&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +irc-fun-bot: more notes on ticket 4: events types<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/13 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-15T00:04:20Z > + 2015-07-15T00:04:20Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/13.mdwn;h=b6905577f100cfddf71d2589136637129d7016a1;hp=0000000000000000000000000000000000000000;hb=2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a;hpb=efaad54e5facfab7d5048a058407a733b987f877" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F13" > rel="nofollow">projects/funbot/tickets/13</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">12:04:20 AM 07/15/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=2f5ca460f67dbbb1503a8bcf0a0f1a815f90ed9a" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: new ticket: collecting quotes<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/irc-fun-bot/tickets/4 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_efaad54e5facfab7d5048a058407a733b987f877/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-14T23:48:18Z > + 2015-07-14T23:48:18Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-efaad54e5facfab7d5048a058407a733b987f877" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/irc-fun-bot/tickets/4.mdwn;h=4cda87eb8f895f7dee560b8df646d1c7d5e4601a;hp=d3eb459357a0fe4b6922f45adfaabf25f6753d68;hb=efaad54e5facfab7d5048a058407a733b987f877;hpb=ca1c11f89649f6d8e2ee1e875edf2c4232447c92" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Firc-fun-bot%2Ftickets%2F4&amp;do=goto" > rel="nofollow">projects/irc-fun-bot/tickets/4</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">11:48:18 PM 07/14/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=efaad54e5facfab7d5048a058407a733b987f877" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +irc-fun-bot: thoughts on ticket 4<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to people/fr33domlover on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_ca1c11f89649f6d8e2ee1e875edf2c4232447c92/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-13T19:56:20Z > + 2015-07-13T19:56:20Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-ca1c11f89649f6d8e2ee1e875edf2c4232447c92" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=people/fr33domlover.mdwn;h=f28b90121dbd2ea1427b476ec65ac299d5a362a7;hp=6f209d9fe79aaea43836b9e010f6879ef7428cbc;hb=ca1c11f89649f6d8e2ee1e875edf2c4232447c92;hpb=6d3a6ade9202b71c87723db5d8d99f95625995d0" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">people/fr33domlover</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">07:56:20 PM 07/13/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=ca1c11f89649f6d8e2ee1e875edf2c4232447c92" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +me: not anymore<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/manual projects/funbot/tickets/9 > on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_6d3a6ade9202b71c87723db5d8d99f95625995d0/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-13T16:31:31Z > + 2015-07-13T16:31:31Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-6d3a6ade9202b71c87723db5d8d99f95625995d0" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/manual.mdwn;h=f179ef3cc7731f76ad0bae8b31a4e64a3f8d6871;hp=c664554baaa6d752bb6412372ae3e03c25f88691;hb=6d3a6ade9202b71c87723db5d8d99f95625995d0;hpb=75eade8953e45278446e742d970840fd5686a759" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Fmanual" > rel="nofollow">projects/funbot/manual</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/9.mdwn;h=f3728f733ee4e81e0cf9e6aa40df787378449c85;hp=1dcfa08f772cc596392b61eaed26d494b37f4e17;hb=6d3a6ade9202b71c87723db5d8d99f95625995d0;hpb=75eade8953e45278446e742d970840fd5686a759" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F9" > rel="nofollow">projects/funbot/tickets/9</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">04:31:31 PM 07/13/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=6d3a6ade9202b71c87723db5d8d99f95625995d0" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +funbot: finish manual and close ticket 9, Jookia&#39;s patch applied > - thanks!<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/funbot/tickets/9 on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_75eade8953e45278446e742d970840fd5686a759/ > > + > + > + > + jookia > + > + > + > + > + > + 2015-07-13T15:29:57Z > + 2015-07-13T15:29:57Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-75eade8953e45278446e742d970840fd5686a759" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/9.mdwn;h=1dcfa08f772cc596392b61eaed26d494b37f4e17;hp=b5300d432f0b164e9ddd5cf70630ec04caca47c6;hb=75eade8953e45278446e742d970840fd5686a759;hpb=660f57dbd862851e014100f04657b9b9f20bd8dd" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F9" > rel="nofollow">projects/funbot/tickets/9</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Fjookia" > rel="nofollow">jookia</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">web</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">03:29:57 PM 07/13/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=75eade8953e45278446e742d970840fd5686a759&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > +</div> > + > + > + > + > + > + > + > + > + > + change to > projects/funbot/tickets/9/0001-info-Add-copying-information.patch on > Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_660f57dbd862851e014100f04657b9b9f20bd8dd/ > > + > + > + > + jookia > + > + > + > + > + > + 2015-07-13T15:25:55Z > + 2015-07-13T15:25:55Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-660f57dbd862851e014100f04657b9b9f20bd8dd" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/funbot/tickets/9/0001-info-Add-copying-information.patch;h=1c6b87a3543f57c62bc123bc441be563c0a18a75;hp=0000000000000000000000000000000000000000;hb=660f57dbd862851e014100f04657b9b9f20bd8dd;hpb=69a4b71b5f5359915ae8a9c17cd12778e577267b" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=projects%2Ffunbot%2Ftickets%2F9%2F0001-info-Add-copying-information.patch" > rel="nofollow">projects/funbot/tickets/9/0001-info-Add-copying-information.patch</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=people%2Fjookia&amp;do=goto" > rel="nofollow">jookia</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">web</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">03:25:55 PM 07/13/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?rev=660f57dbd862851e014100f04657b9b9f20bd8dd&amp;do=revert" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +attachment upload<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + change to projects/libravatar projects/libravatar/tickets/1 > projects/libravatar/tickets/Please_provide_sample_code on Rel4tion > + > + > http://www.rel4tion.org/recentchanges/change_69a4b71b5f5359915ae8a9c17cd12778e577267b/ > > + > + > + > + fr33domlover > + > + > + > + > + > + 2015-07-13T14:57:10Z > + 2015-07-13T14:57:10Z > + > + > + > + > + > + > + > + > + > + > + > +<div id="change-69a4b71b5f5359915ae8a9c17cd12778e577267b" > class="metadata"> > +<span class="desc"><br />Changed pages:</span> > +<span class="pagelinks"> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/libravatar.mdwn;h=da1600f753365123dc129bbbb8d306aa48b76e04;hp=a462742b8577f6ceedb5ce392b9b5fd7a56c97af;hb=69a4b71b5f5359915ae8a9c17cd12778e577267b;hpb=af63fb6ef0b0df0490b806b41ca018701e7eb586" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Flibravatar&amp;do=goto" > rel="nofollow">projects/libravatar</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/libravatar/tickets/1.mdwn;h=be178d41ce929dd13f79a42efdce42814cfd781c;hp=0000000000000000000000000000000000000000;hb=69a4b71b5f5359915ae8a9c17cd12778e577267b;hpb=af63fb6ef0b0df0490b806b41ca018701e7eb586" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Flibravatar%2Ftickets%2F1&amp;do=goto" > rel="nofollow">projects/libravatar/tickets/1</a> > + > + > +<a href=" > http://git.rel4tion.org/?p=wiki.git;a=blobdiff;f=projects/libravatar/tickets/Please_provide_sample_code.mdwn;h=0000000000000000000000000000000000000000;hp=e2ef3abcf2e8dc5bb11d3a0d367fc01a4892123d;hb=69a4b71b5f5359915ae8a9c17cd12778e577267b;hpb=af63fb6ef0b0df0490b806b41ca018701e7eb586" > title="diff" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/diff.png" > alt="diff" /></a><a href=" > http://www.rel4tion.org/ikiwiki.cgi?page=projects%2Flibravatar%2Ftickets%2FPlease_provide_sample_code&amp;do=goto" > rel="nofollow">projects/libravatar/tickets/Please provide > sample code</a> > + > + > +</span> > +<span class="desc"><br />Changed by:</span> > +<span class="committer"> > + > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=goto&amp;page=people%2Ffr33domlover" > rel="nofollow">fr33domlover</a> > + > +</span> > +<span class="desc"><br />Commit type:</span> > +<span class="committype">git</span> > +<span class="desc"><br />Date:</span> > +<span class="changedate"><span > class="date">02:57:10 PM 07/13/2015</span></span> > +<span class="desc"><br /></span> > +<span class="revert"> > +<a href=" > http://www.rel4tion.org/ikiwiki.cgi?do=revert&amp;rev=69a4b71b5f5359915ae8a9c17cd12778e577267b" > title="revert" rel="nofollow"><img src=" > http://www.rel4tion.org/recentchanges/../wikiicons/revert.png" > alt="revert" /></a> > +</span> > +</div> > +<div class="changelog"> > + > + > +libravatar: reply on ticket 1<br /> > + > + > +</div> > + > + > + > + > + > + > + > + > + > + > -- > 1.9.1 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.drautzburg at web.de Fri Oct 2 17:08:45 2015 From: martin.drautzburg at web.de (martin) Date: Fri, 2 Oct 2015 19:08:45 +0200 Subject: [Haskell-cafe] Concept for "equal but unknown" In-Reply-To: References: <560E30ED.2000503@web.de> <20151002140257.GA1136@hunter.iway.ch> <560E969C.4020302@web.de> Message-ID: <560EBA1D.70601@web.de> Am 10/02/2015 um 04:45 PM schrieb Marcin Mrotek: > Hello, > > Do you mean something like variable unification in Prolog or Oz? Maybe > something like this could help you: > https://hackage.haskell.org/package/monad-unify-0.2.2/docs/Control-Monad-Unify.html > or https://hackage.haskell.org/package/unification-fd Disclaimer: I've > never used either of those packages. Well it was no coincidence that I invented the joke term "covariant unification", because I had a hunch that this has something to do with unification. Thanks for the links. From althainz at gmail.com Sat Oct 3 22:09:56 2015 From: althainz at gmail.com (Peter Althainz) Date: Sun, 4 Oct 2015 00:09:56 +0200 Subject: [Haskell-cafe] HGamer3D 0.6.2 Message-ID: Dear All, HGamer3D has some new features with version 0.6.2, see www.hgamer3d.org. Builds on Windows and Linux. with version 0.6 a switch was made towards a simpler structure and a new 3d library. regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintonmead at gmail.com Sun Oct 4 07:15:11 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Sun, 4 Oct 2015 18:15:11 +1100 Subject: [Haskell-cafe] Approach to generalising Functor, is it worth pursuing? Message-ID: I've been thinking about generalising Functor, as I had something which was "Functor like" but didn't seem to fit into the existing definition. The example I'll present isn't the problem I was trying to solve, but it probably illustrates the solution better. The questions I have is: 1. Is this useful? 2. Has this been done? If the answers are Yes and No, I'll continue on into making this into a package. Anyway, here's what I've done: As we know, the type signature of fmap is the following: fmap :: Functor f => (a -> b) -> (f a -> f b) I've put brackets around the last two arguments to show that fmap can be also seen as a function which takes a function and returns a new function, in a different "space", for want of a better word. fmap should also follow this rule: fmap (f . g) == (fmap f . fmap g) So we can map an ordinary function into the "Maybe" space, but in a way that composing functions in the putting them in the space is the same as putting them in the space then composing them. I thought it would be nice if we could fmap to Kleisli Arrows, like so: fmap :: Monad m => (a -> b) -> Kleisli m a b Of course this is just "arr". But "arr" follows fmap's rules, so I thought it would be nice to make it a functor. So I was looking for more generalised versions of "Functor", and I found the 'categories' package, which had the following definition: class (Category r, Category t) => Functor f r t | f r -> t, f t -> r where fmap :: r a b -> t (f a) (f b) This solves half my problem, as now I can set r = (->) and t = Kleisli m and I've got the categories right. But it forces the "output" category to have a data constructor. So: fmap :: Monad m => (a -> b) -> Kleisli m a b Just won't fit. I'd need to make it: fmap :: Monad m => (a -> b) -> Kleisli m (Id a) (Id b) and then unwrap the results. I found this ugly though. So I've gone with another approached. I've linked the code here: http://ideone.com/TEg4MN and also included it inline at the bottom of this mail. Defining functors now becomes a bit wordy, but basically what I've defined is two functor instances. The first is just a copy of the existing functor instances to maintain the status quo behaviour. But secondly I've defined the Kleisli instance as discussed above. The "main" line, does two calls to fmap. The outermost (on the left) is just an ordinary fmap call on lists. The innermost, fmaps the function "triple" into a Kleisli Arrow, allowing it to be composed with the the Kleisli arrow already defined, 'evenOrNothing'. Type inference works this all out magically without signatures being required. Like I said, is approach new and useful? Improvements would be appreciated also, I'm only over the last few months really started focusing on learning Haskell properly (after leaving my previous job of 8 years), so I'm sure I'm still doing plenty of things not quite right. Thanks, Clinton --- {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} module Main ( main ) where import qualified Control.Arrow import Prelude hiding (Functor, fmap, (.)) import Control.Category (Category, (.)) import qualified Data.Functor import qualified Control.Arrow import Control.Arrow (Kleisli(Kleisli), runKleisli) type family F (r :: (* -> * -> *)) (t :: (* -> * -> *)) x type family InputParam f x type family ResultParam f x type family InputCategory f :: (* -> * -> *) type family ResultCategory f :: (* -> * -> *) class Functor f where fmap :: ( Category r, Category t, f ~ F r t c, f ~ F r t d, r ~ InputCategory f, t ~ ResultCategory f, a ~ InputParam f c, b ~ InputParam f d, c ~ ResultParam f a, d ~ ResultParam f b ) => r a b -> t c d data OrdinaryFunctor :: (* -> *) -> * type instance F (->) (->) (f a) = OrdinaryFunctor f type instance InputParam (OrdinaryFunctor f) (f a) = a type instance ResultParam (OrdinaryFunctor f) a = f a type instance InputCategory (OrdinaryFunctor f) = (->) type instance ResultCategory (OrdinaryFunctor f) = (->) instance (Data.Functor.Functor f) => Functor (OrdinaryFunctor f) where fmap = Data.Functor.fmap data KleisliFunctor :: (* -> *) -> * type instance F (->) (Kleisli m) a = KleisliFunctor m type instance InputParam (KleisliFunctor f) a = a type instance ResultParam (KleisliFunctor m) a = a type instance InputCategory (KleisliFunctor m) = (->) type instance ResultCategory (KleisliFunctor m) = Kleisli m instance (Monad m) => Functor (KleisliFunctor m) where fmap = Control.Arrow.arr triple = (*3) evenOrNothing = Kleisli (\x -> if (even x) then Just x else Nothing) main = print $ fmap (runKleisli (evenOrNothing . fmap triple)) [3..6] -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Oct 4 20:05:27 2015 From: david.feuer at gmail.com (David Feuer) Date: Sun, 4 Oct 2015 16:05:27 -0400 Subject: [Haskell-cafe] Approach to generalising Functor, is it worth pursuing? In-Reply-To: References: Message-ID: I don't understand what F is supposed to represent. All the other type families should surely be associated families of Functor rather than independent families. On Sun, Oct 4, 2015 at 3:15 AM, Clinton Mead wrote: > I've been thinking about generalising Functor, as I had something which was > "Functor like" but didn't seem to fit into the existing definition. The > example I'll present isn't the problem I was trying to solve, but it > probably illustrates the solution better. The questions I have is: > 1. Is this useful? > 2. Has this been done? > > If the answers are Yes and No, I'll continue on into making this into a > package. > > Anyway, here's what I've done: > > As we know, the type signature of fmap is the following: > > fmap :: Functor f => (a -> b) -> (f a -> f b) > > I've put brackets around the last two arguments to show that fmap can be > also seen as a function which takes a function and returns a new function, > in a different "space", for want of a better word. > > fmap should also follow this rule: > > fmap (f . g) == (fmap f . fmap g) > > So we can map an ordinary function into the "Maybe" space, but in a way that > composing functions in the putting them in the space is the same as putting > them in the space then composing them. > > I thought it would be nice if we could fmap to Kleisli Arrows, like so: > > fmap :: Monad m => (a -> b) -> Kleisli m a b > > Of course this is just "arr". But "arr" follows fmap's rules, so I thought > it would be nice to make it a functor. > > So I was looking for more generalised versions of "Functor", and I found the > 'categories' package, which had the following definition: > > > class (Category r, Category t) => Functor f r t | f r -> t, f t -> r where > fmap :: r a b -> t (f a) (f b) > > This solves half my problem, as now I can set r = (->) and t = Kleisli m and > I've got the categories right. But it forces the "output" category to have a > data constructor. > > So: > > fmap :: Monad m => (a -> b) -> Kleisli m a b > > Just won't fit. I'd need to make it: > > fmap :: Monad m => (a -> b) -> Kleisli m (Id a) (Id b) > > and then unwrap the results. I found this ugly though. > > So I've gone with another approached. I've linked the code here: > http://ideone.com/TEg4MN and also included it inline at the bottom of this > mail. > > Defining functors now becomes a bit wordy, but basically what I've defined > is two functor instances. The first is just a copy of the existing functor > instances to maintain the status quo behaviour. But secondly I've defined > the Kleisli instance as discussed above. > > The "main" line, does two calls to fmap. The outermost (on the left) is just > an ordinary fmap call on lists. The innermost, fmaps the function "triple" > into a Kleisli Arrow, allowing it to be composed with the the Kleisli arrow > already defined, 'evenOrNothing'. Type inference works this all out > magically without signatures being required. > > Like I said, is approach new and useful? Improvements would be appreciated > also, I'm only over the last few months really started focusing on learning > Haskell properly (after leaving my previous job of 8 years), so I'm sure I'm > still doing plenty of things not quite right. > > Thanks, > > Clinton > > --- > > > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE FlexibleContexts #-} > > module Main ( > main > ) where > > import qualified Control.Arrow > import Prelude hiding (Functor, fmap, (.)) > import Control.Category (Category, (.)) > import qualified Data.Functor > import qualified Control.Arrow > import Control.Arrow (Kleisli(Kleisli), runKleisli) > > type family F (r :: (* -> * -> *)) (t :: (* -> * -> *)) x > type family InputParam f x > type family ResultParam f x > type family InputCategory f :: (* -> * -> *) > type family ResultCategory f :: (* -> * -> *) > > class Functor f where > fmap :: > ( > Category r, Category t, > f ~ F r t c, f ~ F r t d, > r ~ InputCategory f, t ~ ResultCategory f, > a ~ InputParam f c, b ~ InputParam f d, > c ~ ResultParam f a, d ~ ResultParam f b > ) => > r a b -> t c d > > > data OrdinaryFunctor :: (* -> *) -> * > type instance F (->) (->) (f a) = OrdinaryFunctor f > type instance InputParam (OrdinaryFunctor f) (f a) = a > type instance ResultParam (OrdinaryFunctor f) a = f a > type instance InputCategory (OrdinaryFunctor f) = (->) > type instance ResultCategory (OrdinaryFunctor f) = (->) > > instance (Data.Functor.Functor f) => Functor (OrdinaryFunctor f) where > fmap = Data.Functor.fmap > > data KleisliFunctor :: (* -> *) -> * > type instance F (->) (Kleisli m) a = KleisliFunctor m > type instance InputParam (KleisliFunctor f) a = a > type instance ResultParam (KleisliFunctor m) a = a > type instance InputCategory (KleisliFunctor m) = (->) > type instance ResultCategory (KleisliFunctor m) = Kleisli m > > instance (Monad m) => Functor (KleisliFunctor m) where > fmap = Control.Arrow.arr > > triple = (*3) > evenOrNothing = Kleisli (\x -> if (even x) then Just x else Nothing) > > main = print $ fmap (runKleisli (evenOrNothing . fmap triple)) [3..6] > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From alan.zimm at gmail.com Sun Oct 4 20:18:52 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sun, 4 Oct 2015 22:18:52 +0200 Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer Message-ID: I'm pleased to announce the release of HaRe 0.8, available on hackage [1] What's new? =========== Everything, and nothing. Everything in the sense that it has been completely reworked internally to make use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint [3] library. Nothing in the sense that the functionality in this version is/should be identical to that in 0.7.2.8 Limitations =========== HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation. Compiling HaRe with 7.10.2 and then using it against projects using an earlier compiler will not work, as HaRe needs to be able to invoke GHC to the type checker stage on the project using GHC 7.10.2. What is it? =========== HaRe makes changes to working code, so that it still works once the change is made. Refactorings it can do are * demote Take a declaration from the level where it is defined and move it down to the place where it is used. This only works if it is used in one place only. * dupdef Duplicate a definition with a new name. * iftocase Convert an if declaration to a case declaration. * liftOneLevel Move a declaration one level up, adding parameters as needed to pass in locally declared variables. * liftToTopLevel Move a declaration to the top level, adding parameters as needed to pass in locally declared variables. * rename Change a name throughout the project. This makes use of the GHC renamed source so will not change other names that just happen to be lexically identical, but are in fact different names. It currently has an emacs integration only, assistance in supporting other environnments welcome. [1] https://hackage.haskell.org/package/HaRe [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations [3] https://hackage.haskell.org/package/ghc-exactprint Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From wren at community.haskell.org Sun Oct 4 23:39:49 2015 From: wren at community.haskell.org (wren romano) Date: Sun, 4 Oct 2015 19:39:49 -0400 Subject: [Haskell-cafe] Concept for "equal but unknown" In-Reply-To: <560E30ED.2000503@web.de> References: <560E30ED.2000503@web.de> Message-ID: In the context of logic, the usual way to capture these sorts of things is to introduce some notion of an event/eventuality which you can use to index everything by. Then you can say that there exists some index (e.g., hotel reservation) with such and such properties (e.g., consumes a free room, provides the same room to the reservation holder, etc). The connection between this semantic model and how you write your program is, of course, up to you. Both the pointer-indirection approach and the unification-variable approach can be seen as ways of implementing this semantics. As for a general concept, you may want to look into "constraint satisfaction"/"constraint programming" (e.g., ECLPS Prolog ). The big idea here is that you can give each variable a domain of possible values (which need not be the same for all variables), and then you introduce a set of constraints on what those values can be. This allows for capturing things like "I have three reservations X, Y, and Z for three rooms A, B, and C such that no room is booked twice and no reservation takes more than one room". -- Live well, ~wren From ky3 at atamo.com Mon Oct 5 01:16:07 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Mon, 5 Oct 2015 08:16:07 +0700 Subject: [Haskell-cafe] Concept for "equal but unknown" In-Reply-To: <560E969C.4020302@web.de> References: <560E30ED.2000503@web.de> <20151002140257.GA1136@hunter.iway.ch> <560E969C.4020302@web.de> Message-ID: On Fri, Oct 2, 2015 at 9:37 PM, martin wrote: > I guess I am after values which become more and more defined in the course > of computation. One way to simulate incremental binding is by extending with multiple Maybes: Nothing would mean 'no reservation' Just Nothing -> 'reservation but unassigned room' Just (Room 123) -> 'reservation with assigned room' The type used is Maybe (Maybe Room). -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From zocca.marco at gmail.com Mon Oct 5 05:50:29 2015 From: zocca.marco at gmail.com (Marco Zocca) Date: Mon, 5 Oct 2015 07:50:29 +0200 Subject: [Haskell-cafe] [ANN] PETSc Haskell bindings Message-ID: Dear all, development of the Haskell bindings for the PETSc scientific computation library is now public; the repository can be found at https://github.com/ocramz/petsc-hs The interface is still very much experimental and in a state of flow but a number of basic functions are working. I look forward to all feedback; Kind regards, Marco Zocca From andrew.gibiansky at gmail.com Mon Oct 5 06:07:35 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Sun, 4 Oct 2015 23:07:35 -0700 Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer In-Reply-To: References: Message-ID: Alan, This is awesome. I can't express how excited I am to see this develop further. I'll gladly start working on Vim support. Could you describe how it works with emacs? -- Andrew On Sun, Oct 4, 2015 at 1:18 PM, Alan & Kim Zimmerman wrote: > I'm pleased to announce the release of HaRe 0.8, available on hackage [1] > > What's new? > =========== > > Everything, and nothing. > > Everything in the sense that it has been completely reworked internally to > make > use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint > [3] > library. > > Nothing in the sense that the functionality in this version is/should be > identical to that in 0.7.2.8 > > Limitations > =========== > > HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation. > Compiling > HaRe with 7.10.2 and then using it against projects using an earlier > compiler > will not work, as HaRe needs to be able to invoke GHC to the type checker > stage > on the project using GHC 7.10.2. > > What is it? > =========== > > HaRe makes changes to working code, so that it still works once the change > is > made. > > Refactorings it can do are > > * demote > > Take a declaration from the level where it is defined and move it down > to the > place where it is used. This only works if it is used in one place only. > > * dupdef > > Duplicate a definition with a new name. > > * iftocase > > Convert an if declaration to a case declaration. > > * liftOneLevel > > Move a declaration one level up, adding parameters as needed to pass in > locally declared variables. > > * liftToTopLevel > > Move a declaration to the top level, adding parameters as needed to pass > in > locally declared variables. > > * rename > > Change a name throughout the project. This makes use of the GHC renamed > source > so will not change other names that just happen to be lexically > identical, but > are in fact different names. > > It currently has an emacs integration only, assistance in supporting other > environnments welcome. > > [1] https://hackage.haskell.org/package/HaRe > [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations > [3] https://hackage.haskell.org/package/ghc-exactprint > > Alan > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Oct 5 06:19:24 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 5 Oct 2015 08:19:24 +0200 Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer In-Reply-To: References: Message-ID: Hi Andrew Thanks for the offer, that will be awesome. In emacs the process is to highlight in a buffer the point where a change should happen, for example place the cursor on something that needs renaming, and then press the key binding for the relevant refactoring. The elisp uses the name of the buffer, location of the cursor and/or current highlighted region to construct the parameters for a call to ghc-hare. When it is done, ghc-hare returns either (ok [files]) to indicate success and the names of the files that were changed, or (error "description of error"). HaRe does not actually change any files, it just places a new version next to to it with an extension of .refactored.hs. In emacs a (optional) series of ediff buffers are presented to review the changes. If the user accepts them the elisp copies the original files to the same name but with a date-time string as a suffix, and renames the refactored file to be the original. It should then reload the buffer, but I think that is missing right now. Alan On Mon, Oct 5, 2015 at 8:07 AM, Andrew Gibiansky wrote: > Alan, > > This is awesome. I can't express how excited I am to see this develop > further. > > I'll gladly start working on Vim support. > > Could you describe how it works with emacs? > > -- Andrew > > On Sun, Oct 4, 2015 at 1:18 PM, Alan & Kim Zimmerman > wrote: > >> I'm pleased to announce the release of HaRe 0.8, available on hackage [1] >> >> What's new? >> =========== >> >> Everything, and nothing. >> >> Everything in the sense that it has been completely reworked internally >> to make >> use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint >> [3] >> library. >> >> Nothing in the sense that the functionality in this version is/should be >> identical to that in 0.7.2.8 >> >> Limitations >> =========== >> >> HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation. >> Compiling >> HaRe with 7.10.2 and then using it against projects using an earlier >> compiler >> will not work, as HaRe needs to be able to invoke GHC to the type checker >> stage >> on the project using GHC 7.10.2. >> >> What is it? >> =========== >> >> HaRe makes changes to working code, so that it still works once the >> change is >> made. >> >> Refactorings it can do are >> >> * demote >> >> Take a declaration from the level where it is defined and move it down >> to the >> place where it is used. This only works if it is used in one place only. >> >> * dupdef >> >> Duplicate a definition with a new name. >> >> * iftocase >> >> Convert an if declaration to a case declaration. >> >> * liftOneLevel >> >> Move a declaration one level up, adding parameters as needed to pass in >> locally declared variables. >> >> * liftToTopLevel >> >> Move a declaration to the top level, adding parameters as needed to >> pass in >> locally declared variables. >> >> * rename >> >> Change a name throughout the project. This makes use of the GHC renamed >> source >> so will not change other names that just happen to be lexically >> identical, but >> are in fact different names. >> >> It currently has an emacs integration only, assistance in supporting other >> environnments welcome. >> >> [1] https://hackage.haskell.org/package/HaRe >> [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations >> [3] https://hackage.haskell.org/package/ghc-exactprint >> >> Alan >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.j.thompson at kent.ac.uk Mon Oct 5 08:47:57 2015 From: s.j.thompson at kent.ac.uk (Simon Thompson) Date: Mon, 5 Oct 2015 09:47:57 +0100 Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer In-Reply-To: References: Message-ID: Alan, Andrew, The original version of HaRe did integrate with vim. This work was done more than 10 years ago, and it may well be that the mechanisms have changed. Still, the code should be in the HaRe repo. On the other hand, may be easier to start from scratch. Kind regards, and great to hear that you?re planning to do this! Simon T. > On 5 Oct 2015, at 07:19, Alan & Kim Zimmerman wrote: > > Hi Andrew > > Thanks for the offer, that will be awesome. > > In emacs the process is to highlight in a buffer the point where a change should happen, for example place the cursor on something that needs renaming, and then press the key binding for the relevant refactoring. The elisp uses the name of the buffer, location of the cursor and/or current highlighted region to construct the parameters for a call to ghc-hare. > > When it is done, ghc-hare returns either (ok [files]) to indicate success and the names of the files that were changed, or (error "description of error"). > > HaRe does not actually change any files, it just places a new version next to to it with an extension of .refactored.hs. In emacs a (optional) series of ediff buffers are presented to review the changes. If the user accepts them the elisp copies the original files to the same name but with a date-time string as a suffix, and renames the refactored file to be the original. It should then reload the buffer, but I think that is missing right now. > > Alan > > On Mon, Oct 5, 2015 at 8:07 AM, Andrew Gibiansky > wrote: > Alan, > > This is awesome. I can't express how excited I am to see this develop further. > > I'll gladly start working on Vim support. > > Could you describe how it works with emacs? > > -- Andrew > > On Sun, Oct 4, 2015 at 1:18 PM, Alan & Kim Zimmerman > wrote: > I'm pleased to announce the release of HaRe 0.8, available on hackage [1] > > What's new? > =========== > > Everything, and nothing. > > Everything in the sense that it has been completely reworked internally to make > use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint [3] > library. > > Nothing in the sense that the functionality in this version is/should be > identical to that in 0.7.2.8 > > Limitations > =========== > > HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation. Compiling > HaRe with 7.10.2 and then using it against projects using an earlier compiler > will not work, as HaRe needs to be able to invoke GHC to the type checker stage > on the project using GHC 7.10.2. > > What is it? > =========== > > HaRe makes changes to working code, so that it still works once the change is > made. > > Refactorings it can do are > > * demote > > Take a declaration from the level where it is defined and move it down to the > place where it is used. This only works if it is used in one place only. > > * dupdef > > Duplicate a definition with a new name. > > * iftocase > > Convert an if declaration to a case declaration. > > * liftOneLevel > > Move a declaration one level up, adding parameters as needed to pass in > locally declared variables. > > * liftToTopLevel > > Move a declaration to the top level, adding parameters as needed to pass in > locally declared variables. > > * rename > > Change a name throughout the project. This makes use of the GHC renamed source > so will not change other names that just happen to be lexically identical, but > are in fact different names. > > It currently has an emacs integration only, assistance in supporting other > environnments welcome. > > [1] https://hackage.haskell.org/package/HaRe > [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations > [3] https://hackage.haskell.org/package/ghc-exactprint > > Alan > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.jan.mrotek at gmail.com Mon Oct 5 08:53:51 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Mon, 5 Oct 2015 10:53:51 +0200 Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer In-Reply-To: References: Message-ID: Hello, As for vim integration, neovim and https://github.com/neovimhaskell/nvim-hs might be the way to go. Best regards, Marcin Mrotek From alan.zimm at gmail.com Mon Oct 5 09:31:29 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 5 Oct 2015 11:31:29 +0200 Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer In-Reply-To: References: Message-ID: It is here: https://github.com/alanz/HaRe/tree/master/old/editors/Vim On Mon, Oct 5, 2015 at 10:47 AM, Simon Thompson wrote: > Alan, Andrew, > > The original version of HaRe did integrate with vim. This work was done > more than 10 years ago, and it may well be that the mechanisms have > changed. Still, the code should be in the HaRe repo. On the other hand, may > be easier to start from scratch. > > Kind regards, and great to hear that you?re planning to do this! > > Simon T. > > > On 5 Oct 2015, at 07:19, Alan & Kim Zimmerman wrote: > > Hi Andrew > > Thanks for the offer, that will be awesome. > > In emacs the process is to highlight in a buffer the point where a change > should happen, for example place the cursor on something that needs > renaming, and then press the key binding for the relevant refactoring. The > elisp uses the name of the buffer, location of the cursor and/or current > highlighted region to construct the parameters for a call to ghc-hare. > > When it is done, ghc-hare returns either (ok [files]) to indicate success > and the names of the files that were changed, or (error "description of > error"). > > HaRe does not actually change any files, it just places a new version next > to to it with an extension of .refactored.hs. In emacs a (optional) series > of ediff buffers are presented to review the changes. If the user accepts > them the elisp copies the original files to the same name but with a > date-time string as a suffix, and renames the refactored file to be the > original. It should then reload the buffer, but I think that is missing > right now. > > Alan > > On Mon, Oct 5, 2015 at 8:07 AM, Andrew Gibiansky < > andrew.gibiansky at gmail.com> wrote: > >> Alan, >> >> This is awesome. I can't express how excited I am to see this develop >> further. >> >> I'll gladly start working on Vim support. >> >> Could you describe how it works with emacs? >> >> -- Andrew >> >> On Sun, Oct 4, 2015 at 1:18 PM, Alan & Kim Zimmerman > > wrote: >> >>> I'm pleased to announce the release of HaRe 0.8, available on hackage [1] >>> >>> What's new? >>> =========== >>> >>> Everything, and nothing. >>> >>> Everything in the sense that it has been completely reworked internally >>> to make >>> use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint >>> [3] >>> library. >>> >>> Nothing in the sense that the functionality in this version is/should be >>> identical to that in 0.7.2.8 >>> >>> Limitations >>> =========== >>> >>> HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation. >>> Compiling >>> HaRe with 7.10.2 and then using it against projects using an earlier >>> compiler >>> will not work, as HaRe needs to be able to invoke GHC to the type >>> checker stage >>> on the project using GHC 7.10.2. >>> >>> What is it? >>> =========== >>> >>> HaRe makes changes to working code, so that it still works once the >>> change is >>> made. >>> >>> Refactorings it can do are >>> >>> * demote >>> >>> Take a declaration from the level where it is defined and move it down >>> to the >>> place where it is used. This only works if it is used in one place >>> only. >>> >>> * dupdef >>> >>> Duplicate a definition with a new name. >>> >>> * iftocase >>> >>> Convert an if declaration to a case declaration. >>> >>> * liftOneLevel >>> >>> Move a declaration one level up, adding parameters as needed to pass in >>> locally declared variables. >>> >>> * liftToTopLevel >>> >>> Move a declaration to the top level, adding parameters as needed to >>> pass in >>> locally declared variables. >>> >>> * rename >>> >>> Change a name throughout the project. This makes use of the GHC >>> renamed source >>> so will not change other names that just happen to be lexically >>> identical, but >>> are in fact different names. >>> >>> It currently has an emacs integration only, assistance in supporting >>> other >>> environnments welcome. >>> >>> [1] https://hackage.haskell.org/package/HaRe >>> [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations >>> [3] https://hackage.haskell.org/package/ghc-exactprint >>> >>> Alan >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > Simon Thompson | Professor of Logic and Computation > School of Computing | University of Kent | Canterbury, CT2 7NF, UK > s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.j.thompson at kent.ac.uk Mon Oct 5 09:59:46 2015 From: s.j.thompson at kent.ac.uk (Simon Thompson) Date: Mon, 5 Oct 2015 10:59:46 +0100 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> Message-ID: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Hello all. I write this to be a little provocative, but ? It?s really interesting to have this discussion, which pulls in all sorts of well-made points about orthogonality, teaching, the evolution of the language and so on, but it simply goes to show that the process of evolving Haskell is profoundly broken. Other languages do evolve, but in a managed and reflective way. Simply throwing in changes that would have a profound impact on systems that are commercially and potentially safety critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility of the Haskell community to its users and, indirectly, to its future. If we make claims - I believe rightly - that Haskell is hitting the mainstream, then we need to think about all changes in terms of the costs and benefits of each of them in the widest possible sense. There?s an old fashioned maxim that sums this up in a pithy way: ?if it ain?t broke, don?t fix it?. Simon Thompson > On 5 Oct 2015, at 10:47, Micha? J Gajda wrote: > > Hi, > > As a person who used Haskell in all three capacities (for scientific research, for commercial purpose, and to introduce others to benefits of pure and strongly typed programming), I must voice an supportive voice for this change: > 1. Orthogonal type classes are easier to explain. > 2. Gradual improvements helps us to generalize further, and this in turn makes education easier. > 3. Gradual change that break only a little help to prevent either stagnation (FORTRAN) and big breakage (py3k). That keeps us excited. > > That would also call to split TCs into their orthogonal elements: return, ap, bind having the basic TC on their own. > > So: > +1, but only if it is possible to have compatibilty mode. I believe that rebindable syntax should allow us to otherwise make our own prelude, if we want such a split. Then we could test it well before it is used by the base library. > > That said, I would appreciate Haskell2010 option just like Haskell98 wad, so that we can compile old programs without changes. Even by using some Compat version of standard library. Would that satisfy need for stability? > > PS And since all experts were beginners some time ago, I beg that we do not call them "peripheral". > -- > Best regards > Micha? > > On Monday, 5 October 2015, Malcolm Wallace > wrote: > On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be > (...) > > > -- > Pozdrawiam > Micha? > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mblazevic at stilo.com Mon Oct 5 13:11:06 2015 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Mon, 5 Oct 2015 09:11:06 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <561276EA.5030402@stilo.com> On 15-10-05 05:59 AM, Simon Thompson wrote: > Hello all. I write this to be a little provocative, but ? > > ... > Other languages do evolve, but in a managed and reflective way. Citation needed. From svenpanne at gmail.com Mon Oct 5 13:27:53 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 5 Oct 2015 15:27:53 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: 2015-10-05 11:59 GMT+02:00 Simon Thompson : > [...] It?s really interesting to have this discussion, which pulls in all > sorts of well-made points about orthogonality, teaching, the evolution of > the language and so on, but it simply goes to show that the process of > evolving Haskell is profoundly broken. [...] > I wouldn't necessarily call the process "broken", but it's a bit annoying: Because of the constant flux of minor changes in the language and the libraries, I've reached the stage where I'm totally unable to tell if my code will work for the whole GHC 7.x series. The only way I see is doing heavy testing on Travis CI and littering the code with #ifdefs after compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for keeping the #ifdefs centralized. No clue how to do that...) This is less than satisfactory IMHO, and I would really prefer some other mode for introducing such changes: Perhaps these should be bundled and released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way some stuff which belongs together (AMP, FTP, kicking out return, etc.) comes in slightly larger, but more sensible chunks. Don't get me wrong: Most of the proposed changes in itself are OK and should be done, it's only the way they are introduced should be improved... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantkiew at gsd.uwaterloo.ca Mon Oct 5 13:43:59 2015 From: mantkiew at gsd.uwaterloo.ca (mantkiew at gsd.uwaterloo.ca) Date: Mon, 05 Oct 2015 09:43:59 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> An HTML attachment was scrubbed... URL: From hvr at gnu.org Mon Oct 5 14:32:40 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 05 Oct 2015 16:32:40 +0200 Subject: [Haskell-cafe] Language Change Management (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: (Sven Panne's message of "Mon, 5 Oct 2015 15:27:53 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <87lhbhperb.fsf_-_@gnu.org> On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote: > 2015-10-05 11:59 GMT+02:00 Simon Thompson : > >> [...] It?s really interesting to have this discussion, which pulls in all >> sorts of well-made points about orthogonality, teaching, the evolution of >> the language and so on, but it simply goes to show that the process of >> evolving Haskell is profoundly broken. [...] >> > > I wouldn't necessarily call the process "broken", but it's a bit > annoying: Because of the constant flux of minor changes in the > language and the libraries, I've reached the stage where I'm totally > unable to tell if my code will work for the whole GHC 7.x series. The > only way I see is doing heavy testing on Travis CI and littering the > code with #ifdefs after compilation failures. (BTW: Fun exercise: Try > using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for > keeping the #ifdefs centralized. No clue how to do that...) This is > less than satisfactory IMHO, and I would really prefer some other mode > for introducing such changes: Perhaps these should be bundled and > released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way > some stuff which belongs together (AMP, FTP, kicking out return, etc.) > comes in slightly larger, but more sensible chunks. > > Don't get me wrong: Most of the proposed changes in itself are OK and > should be done, it's only the way they are introduced should be > improved... I think that part of the reason we have seen these changes occur in a "constant flux" rather than in bigger coordinated chunks is that faith in the Haskell Report process was (understandably) abandoned. And without the Haskell Report as some kind of "clock generator" with which to align/bundle related changes into logical units, changes occur whenever they're proposed and agreed upon (which may take several attempts as we've seen with the AMP and others). I hope that the current attempt to revive the Haskell Prime process will give us a chance to clean up the unfinished intermediate `base-4.8` situation we're left with now after AMP, FTP et al, as the next Haskell Report revision provides us with a milestone to work towards. That being said, there's also the desire to have changes field-tested by a wide audience on a wide range before integrating them into a Haskell Report. Also I'm not sure if there would be less complaints if AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all at once in e.g. `base-5.0`, breaking almost *every* single package out there at once. For language changes we have a great way to field-test new extensions before integrating them into the Report via `{-# LANGUAGE #-}` pragmas in a nicely modular and composable way (i.e. a package enabling a certain pragma doesn't require other packages to use it as well) which have proven to be quite popular. However, for the library side we lack a comparable mechanism at this point. The closest we have, for instance, to support an isolated Haskell2010 legacy environment is to use RebindableSyntax which IMO isn't good enough in its current form[1]. And then there's the question whether we want a Haskell2010 legacy environment that's isolated or rather shares the types & typeclasses w/ `base`. If we require sharing types and classes, then we may need some facility to implicitly instanciate new superclasses (e.g. implicitly define Functor and Applicative if only a Monad instance is defined). If we don't want to share types & classes, we run into the problem that we can't easily mix packages which depend on different revisions of the standard-library (e.g. one using `base-4.8` and others which depend on a legacy `haskell2010` base-API). One way to solve this could be to mutually exclude depending on both , `base-4.8` and `haskell2010`, in the same install-plan (assuming `haskell2010` doesn't depend itself on `base-4.8`) In any case, I think we will have to think hard how to address language/library change management in the future, especially if the Haskell code-base continues to grow. Even just migrating the code base between Haskell Report revisions is a problem. An extreme example is the Python 2->3 transition which the Python ecosystem is still suffering from today (afaik). Ideas welcome! [1]: IMO, we need something to be used at the definition site providing desugaring rules, rather than requiring the use-site to enable a generalised desugaring mechanism; I've been told that Agda has an interesting solution to this in its base libraries via {-# LANGUAGE BUILTIN ... #-} pragmas. Regards, H.V.Riedel From gershomb at gmail.com Mon Oct 5 14:32:21 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 5 Oct 2015 10:32:21 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote: > Hello all. I write this to be a little provocative, but ? > > It?s really interesting to have this discussion, which pulls in all sorts of well-made > points about orthogonality, teaching, the evolution of the language and so on, but it > simply goes to show that the process of evolving Haskell is profoundly broken. > > Other languages do evolve, but in a managed and reflective way. Simply throwing in changes > that would have a profound impact on systems that are commercially and potentially safety > critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility > of the Haskell community to its users and, indirectly, to its future. Hi Simon. I do in fact think this is provocative :-P I want to object here to your characterization of what has been going on as ?simply throwing in changes?. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period. I also want to object to the idea that these changes would have ?a profound impact on systems?. As it stands, and I think this is an important criteria in any change, when ?phase 2? goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior. Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind? ?Gershom P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns. From bos at serpentine.com Mon Oct 5 14:59:32 2015 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon, 5 Oct 2015 07:59:32 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: I would like to suggest that the bar for breaking all existing libraries, books, papers, and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge. This proposal falls far short of both bars, to the extent that I am astonished and disappointed it is being seriously discussed ? and to general approval, no less ? on a date other than April 1. Surely some design flaws have consequences so small that they are not worth fixing. I'll survive if it goes through, obviously, but it will commit me to a bunch of pointless make-work and compatibility ifdefs. I've previously expressed my sense that cross-version compatibility is a big tax on library maintainers. This proposal does not give me confidence that this cost is being taken seriously. Thanks, Bryan. > On Oct 5, 2015, at 7:32 AM, Gershom B wrote: > >> On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote: >> Hello all. I write this to be a little provocative, but ? >> >> It?s really interesting to have this discussion, which pulls in all sorts of well-made >> points about orthogonality, teaching, the evolution of the language and so on, but it >> simply goes to show that the process of evolving Haskell is profoundly broken. >> >> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes >> that would have a profound impact on systems that are commercially and potentially safety >> critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility >> of the Haskell community to its users and, indirectly, to its future. > > Hi Simon. I do in fact think this is provocative :-P > > I want to object here to your characterization of what has been going on as ?simply throwing in changes?. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period. > > I also want to object to the idea that these changes would have ?a profound impact on systems?. As it stands, and I think this is an important criteria in any change, when ?phase 2? goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior. > > Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind? > > ?Gershom > > P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns. > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime From gershomb at gmail.com Mon Oct 5 15:09:23 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 5 Oct 2015 11:09:23 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com) wrote: > I would like to suggest that the bar for breaking all existing libraries, books, papers, > and lecture notes should be very high; and that the benefit associated with such a breaking > change should be correspondingly huge. > My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one? As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP. So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been. So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc. It is totally reasonable to have a discussion on whether this change is worth it at all. But let?s not overestimate the cost of it just to further tip the scales :-) ?gershom From johan.tibell at gmail.com Mon Oct 5 15:12:38 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 5 Oct 2015 17:12:38 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: Perhaps we should weigh the +1 and -1s in this thread with the number of lines of Haskell written by the voter? ;) On Mon, Oct 5, 2015 at 5:09 PM, Gershom B wrote: > On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com) > wrote: > > I would like to suggest that the bar for breaking all existing > libraries, books, papers, > > and lecture notes should be very high; and that the benefit associated > with such a breaking > > change should be correspondingly huge. > > > > My understanding of the argument here, which seems to make sense to me, is > that the AMP already introduced a significant breaking change with regards > to monads. Books and lecture notes have already not caught up to this, by > and large. Hence, by introducing a further change, which _completes_ the > general AMP project, then by the time books and lecture notes are all > updated, they will be able to tell a much nicer story than the current one? > > As for libraries, it has been pointed out, I believe, that without CPP one > can write instances compatible with AMP, and also with AMP + MRP. One can > also write code, sans CPP, compatible with pre- and post- AMP. > > So the reason for choosing to not do MRP simultaneous with AMP was > precisely to allow a gradual migration path where, sans CPP, people could > write code compatible with the last three versions of GHC, as the general > criteria has been. > > So without arguing the necessity or not, I just want to weigh in with a > technical opinion that if this goes through, my _estimation_ is that there > will be a smooth and relatively painless migration period, the sky will not > fall, good teaching material will remain good, those libraries that bitrot > will tend to do so for a variety of reasons more significant than this, etc. > > It is totally reasonable to have a discussion on whether this change is > worth it at all. But let?s not overestimate the cost of it just to further > tip the scales :-) > > ?gershom > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Oct 5 17:11:23 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 5 Oct 2015 19:11:23 +0200 (CEST) Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On Mon, 5 Oct 2015, Johan Tibell wrote: > Perhaps we should weigh the +1 and -1s in this thread with the number of > lines of Haskell written by the voter? ;) My prefered measure would the number of Haskell packages hosted at hub.darcs.net. :-) From defigueiredo at ucdavis.edu Mon Oct 5 17:28:00 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Mon, 5 Oct 2015 11:28:00 -0600 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <5612B320.3060701@ucdavis.edu> +1 I think this idea is good and should not be taken lightly. I'm a newcomer to the community and currently hold a grand total of *zero* open source contributions. Obviously, I would like to change this soon, but I think it is very *unfair* and makes absolutely no sense to have the standard one person one vote rule for decisions involving the libraries. Let the code produced vote. Maybe weight them by downloads? Dimitri On 10/5/15 9:12 AM, Johan Tibell wrote: > Perhaps we should weigh the +1 and -1s in this thread with the number > of lines of Haskell written by the voter? ;) > > On Mon, Oct 5, 2015 at 5:09 PM, Gershom B > wrote: > > On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan > (bos at serpentine.com ) wrote: > > I would like to suggest that the bar for breaking all existing > libraries, books, papers, > > and lecture notes should be very high; and that the benefit > associated with such a breaking > > change should be correspondingly huge. > > > > My understanding of the argument here, which seems to make sense > to me, is that the AMP already introduced a significant breaking > change with regards to monads. Books and lecture notes have > already not caught up to this, by and large. Hence, by introducing > a further change, which _completes_ the general AMP project, then > by the time books and lecture notes are all updated, they will be > able to tell a much nicer story than the current one? > > As for libraries, it has been pointed out, I believe, that without > CPP one can write instances compatible with AMP, and also with AMP > + MRP. One can also write code, sans CPP, compatible with pre- and > post- AMP. > > So the reason for choosing to not do MRP simultaneous with AMP was > precisely to allow a gradual migration path where, sans CPP, > people could write code compatible with the last three versions of > GHC, as the general criteria has been. > > So without arguing the necessity or not, I just want to weigh in > with a technical opinion that if this goes through, my > _estimation_ is that there will be a smooth and relatively > painless migration period, the sky will not fall, good teaching > material will remain good, those libraries that bitrot will tend > to do so for a variety of reasons more significant than this, etc. > > It is totally reasonable to have a discussion on whether this > change is worth it at all. But let?s not overestimate the cost of > it just to further tip the scales :-) > > ?gershom > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Mon Oct 5 18:33:42 2015 From: jwlato at gmail.com (John Lato) Date: Mon, 05 Oct 2015 18:33:42 +0000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5612B320.3060701@ucdavis.edu> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5612B320.3060701@ucdavis.edu> Message-ID: I think code-based weighting should not be considered at all. There's a non-trivial amount of proprietary code that wouldn't be counted, and likely can't be accounted for accurately. I have some unknown amount of code at my previous employer (which does include Monad instances) that now has to be maintained by others. I may have said +1 (and I'm reconsidering), but the current maintainers probably don't want the extra make-work this involves. There's an argument that this proposal involves very little up-front breakage. This is true but disingenuous, because the breakage will still happen in the future unless changes are made and committed. The entire maintenance load should be considered, not just the immediate load. Bryan, nothing I've seen since I started using Haskell makes me think that the libraries committee or ghc devs value back compatibility much at all. My favorite example is RecursiveDo, which was deprecated in favor of DoRec, only for that to be reversed in the next ghc release. Of course that was more irritating than breaking, but it's indicative of the general value placed on maintenance programming. On 12:28, Mon, Oct 5, 2015 Dimitri DeFigueiredo wrote: > +1 > > I think this idea is good and should not be taken lightly. I'm a newcomer > to the community and currently hold a grand total of *zero* open source > contributions. Obviously, I would like to change this soon, but I think it > is very *unfair* and makes absolutely no sense to have the standard one > person one vote rule for decisions involving the libraries. > > Let the code produced vote. Maybe weight them by downloads? > > Dimitri > > > > > On 10/5/15 9:12 AM, Johan Tibell wrote: > > Perhaps we should weigh the +1 and -1s in this thread with the number of > lines of Haskell written by the voter? ;) > > On Mon, Oct 5, 2015 at 5:09 PM, Gershom B wrote: > >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com) >> wrote: >> > I would like to suggest that the bar for breaking all existing >> libraries, books, papers, >> > and lecture notes should be very high; and that the benefit associated >> with such a breaking >> > change should be correspondingly huge. >> > >> >> My understanding of the argument here, which seems to make sense to me, >> is that the AMP already introduced a significant breaking change with >> regards to monads. Books and lecture notes have already not caught up to >> this, by and large. Hence, by introducing a further change, which >> _completes_ the general AMP project, then by the time books and lecture >> notes are all updated, they will be able to tell a much nicer story than >> the current one? >> >> As for libraries, it has been pointed out, I believe, that without CPP >> one can write instances compatible with AMP, and also with AMP + MRP. One >> can also write code, sans CPP, compatible with pre- and post- AMP. >> >> So the reason for choosing to not do MRP simultaneous with AMP was >> precisely to allow a gradual migration path where, sans CPP, people could >> write code compatible with the last three versions of GHC, as the general >> criteria has been. >> >> So without arguing the necessity or not, I just want to weigh in with a >> technical opinion that if this goes through, my _estimation_ is that there >> will be a smooth and relatively painless migration period, the sky will not >> fall, good teaching material will remain good, those libraries that bitrot >> will tend to do so for a variety of reasons more significant than this, etc. >> >> It is totally reasonable to have a discussion on whether this change is >> worth it at all. But let?s not overestimate the cost of it just to further >> tip the scales :-) >> >> ?gershom >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Mon Oct 5 18:34:31 2015 From: greg at gregorycollins.net (Gregory Collins) Date: Mon, 5 Oct 2015 11:34:31 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On Mon, Oct 5, 2015 at 8:09 AM, Gershom B wrote: > My understanding of the argument here, which seems to make sense to me, is > that the AMP already introduced a significant breaking change with regards > to monads. Books and lecture notes have already not caught up to this, by > and large. Hence, by introducing a further change, which _completes_ the > general AMP project, then by the time books and lecture notes are all > updated, they will be able to tell a much nicer story than the current one? This is a multi-year, "boil the ocean"-style project, affecting literally every Haskell user, and the end result after all of this labor is going to be... a slightly spiffier bike shed? Strongly -1 from me also. My experience over the last couple of years is that every GHC release breaks my libraries in annoying ways that require CPP to fix: ~/personal/src/snap ? find . -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l 64 As a user this is another bikeshedding change that is not going to benefit me at all. Maintaining a Haskell library can be an exasperating exercise of running on a treadmill to keep up with busywork caused by changes to the core language and libraries. My feeling is starting to become that the libraries committee is doing as much (if not more) to *cause* problems and work for me than it is doing to improve the common infrastructure. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbouscal at gmail.com Mon Oct 5 18:50:27 2015 From: nbouscal at gmail.com (Nathan Bouscal) Date: Mon, 5 Oct 2015 19:50:27 +0100 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5612B320.3060701@ucdavis.edu> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5612B320.3060701@ucdavis.edu> Message-ID: I'm a strong +1 on this (and on Edward's addendum to it), and I object to the characterization of this change as having only trivial benefits. Simplicity and correctness are never trivial. In my view, disagreement on *how* this change is made (migration strategy, etc.) is completely reasonable, but disagreement on *whether* to make it is not. There have been a lot of objections based on the idea that learners will consult books that are out of date, but the number of learners affected by this is dwarfed by the number of learners who will use updated materials and be confused by this strange historical artifact. Permanently-enshrined historical artifacts accrete forever and cause linear confusion, whereas outdated materials are inevitably replaced such that the amount of confusion remains constant. There was also an argument that Haskell has a ?window of opportunity?, implying that breakages are more likely to cost us future valued community members than historical artifacts are. I couldn't disagree more. If it weren't for Haskell's past willingness to make changes when we learned better ways of doing things, I doubt I would presently be using the language. I would much rather add a marginal community member with a strong preference for cleanliness, simplicity, and correctness than one with a strong preference against making occasional small changes to their code. ? On Mon, Oct 5, 2015 at 6:28 PM, Dimitri DeFigueiredo < defigueiredo at ucdavis.edu> wrote: > +1 > > I think this idea is good and should not be taken lightly. I'm a newcomer > to the community and currently hold a grand total of *zero* open source > contributions. Obviously, I would like to change this soon, but I think it > is very *unfair* and makes absolutely no sense to have the standard one > person one vote rule for decisions involving the libraries. > > Let the code produced vote. Maybe weight them by downloads? > > Dimitri > > > > > On 10/5/15 9:12 AM, Johan Tibell wrote: > > Perhaps we should weigh the +1 and -1s in this thread with the number of > lines of Haskell written by the voter? ;) > > On Mon, Oct 5, 2015 at 5:09 PM, Gershom B wrote: > >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com) >> wrote: >> > I would like to suggest that the bar for breaking all existing >> libraries, books, papers, >> > and lecture notes should be very high; and that the benefit associated >> with such a breaking >> > change should be correspondingly huge. >> > >> >> My understanding of the argument here, which seems to make sense to me, >> is that the AMP already introduced a significant breaking change with >> regards to monads. Books and lecture notes have already not caught up to >> this, by and large. Hence, by introducing a further change, which >> _completes_ the general AMP project, then by the time books and lecture >> notes are all updated, they will be able to tell a much nicer story than >> the current one? >> >> As for libraries, it has been pointed out, I believe, that without CPP >> one can write instances compatible with AMP, and also with AMP + MRP. One >> can also write code, sans CPP, compatible with pre- and post- AMP. >> >> So the reason for choosing to not do MRP simultaneous with AMP was >> precisely to allow a gradual migration path where, sans CPP, people could >> write code compatible with the last three versions of GHC, as the general >> criteria has been. >> >> So without arguing the necessity or not, I just want to weigh in with a >> technical opinion that if this goes through, my _estimation_ is that there >> will be a smooth and relatively painless migration period, the sky will not >> fall, good teaching material will remain good, those libraries that bitrot >> will tend to do so for a variety of reasons more significant than this, etc. >> >> It is totally reasonable to have a discussion on whether this change is >> worth it at all. But let?s not overestimate the cost of it just to further >> tip the scales :-) >> >> ?gershom >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Oct 5 18:58:57 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 5 Oct 2015 20:58:57 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: 2015-10-05 17:09 GMT+02:00 Gershom B : > On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com) > wrote: > [...] As for libraries, it has been pointed out, I believe, that without > CPP one can write instances compatible with AMP, and also with AMP + MRP. > One can also write code, sans CPP, compatible with pre- and post- AMP. [...] > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is now part of the Prelude, you can't simply import some compatibility module, because GHC might tell you (rightfully) that that import is redundant, because (<$>) is already visible through the Prelude. So you'll have to use CPP to avoid that import on base >= 4.8, be it from it Data.Functor, Control.Applicative or some compat-* module. And you'll have to use CPP in each and every module using <$> then, unless I miss something obvious. AFAICT all transitioning guides ignore -Wall and friends... -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Mon Oct 5 19:01:16 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 5 Oct 2015 21:01:16 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins wrote: > > On Mon, Oct 5, 2015 at 8:09 AM, Gershom B wrote: > >> My understanding of the argument here, which seems to make sense to me, >> is that the AMP already introduced a significant breaking change with >> regards to monads. Books and lecture notes have already not caught up to >> this, by and large. Hence, by introducing a further change, which >> _completes_ the general AMP project, then by the time books and lecture >> notes are all updated, they will be able to tell a much nicer story than >> the current one? > > > This is a multi-year, "boil the ocean"-style project, affecting literally > every Haskell user, and the end result after all of this labor is going to > be... a slightly spiffier bike shed? > > Strongly -1 from me also. My experience over the last couple of years is > that every GHC release breaks my libraries in annoying ways that require > CPP to fix: > > ~/personal/src/snap ? find . -name '*.hs' | xargs egrep > '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l > 64 > > > As a user this is another bikeshedding change that is not going to benefit > me at all. Maintaining a Haskell library can be an exasperating exercise of > running on a treadmill to keep up with busywork caused by changes to the > core language and libraries. My feeling is starting to become that the > libraries committee is doing as much (if not more) to *cause* problems > and work for me than it is doing to improve the common infrastructure. > On the libraries I maintain and have a copy of on my computer right now: 329 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Mon Oct 5 19:02:26 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 5 Oct 2015 21:02:26 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On 5 October 2015 at 20:58, Sven Panne wrote: > 2015-10-05 17:09 GMT+02:00 Gershom B : >> >> [...] As for libraries, it has been pointed out, I believe, that without >> CPP one can write instances compatible with AMP, and also with AMP + MRP. >> One can also write code, sans CPP, compatible with pre- and post- AMP. [...] > > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is > now part of the Prelude, you can't simply import some compatibility module, > because GHC might tell you (rightfully) that that import is redundant, > because (<$>) is already visible through the Prelude. So you'll have to use > CPP to avoid that import on base >= 4.8, be it from it Data.Functor, > Control.Applicative or some compat-* module. And you'll have to use CPP in > each and every module using <$> then, unless I miss something obvious. > AFAICT all transitioning guides ignore -Wall and friends... Does the hack mentioned on the GHC trac [1] work for this? It seems a bit fragile but that page says it works and it avoids CPP. Erik [1] https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...isredundant From johan.tibell at gmail.com Mon Oct 5 19:05:40 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 5 Oct 2015 21:05:40 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On Mon, Oct 5, 2015 at 9:02 PM, Erik Hesselink wrote: > On 5 October 2015 at 20:58, Sven Panne wrote: > > 2015-10-05 17:09 GMT+02:00 Gershom B : > >> > >> [...] As for libraries, it has been pointed out, I believe, that without > >> CPP one can write instances compatible with AMP, and also with AMP + > MRP. > >> One can also write code, sans CPP, compatible with pre- and post- AMP. > [...] > > > > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which > is > > now part of the Prelude, you can't simply import some compatibility > module, > > because GHC might tell you (rightfully) that that import is redundant, > > because (<$>) is already visible through the Prelude. So you'll have to > use > > CPP to avoid that import on base >= 4.8, be it from it Data.Functor, > > Control.Applicative or some compat-* module. And you'll have to use CPP > in > > each and every module using <$> then, unless I miss something obvious. > > AFAICT all transitioning guides ignore -Wall and friends... > > Does the hack mentioned on the GHC trac [1] work for this? It seems a > bit fragile but that page says it works and it avoids CPP. > No it doesn't, if you also don't want closed import lists (which you should). -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Oct 5 19:08:09 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 5 Oct 2015 14:08:09 -0500 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: I'm writing a book (http://haskellbook.com/) with my coauthor. It is up to date with GHC 7.10. AMP made things better, not harder, with respect to teaching Haskell. BBP required some explanation of "ignore this type, we're asserting a different one", but the positives are still better than the negatives. Please don't use existing or forthcoming books as an excuse to do or not-do things. Do what's right for the users of the language. On Mon, Oct 5, 2015 at 2:01 PM, Johan Tibell wrote: > On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins > wrote: > >> >> On Mon, Oct 5, 2015 at 8:09 AM, Gershom B wrote: >> >>> My understanding of the argument here, which seems to make sense to me, >>> is that the AMP already introduced a significant breaking change with >>> regards to monads. Books and lecture notes have already not caught up to >>> this, by and large. Hence, by introducing a further change, which >>> _completes_ the general AMP project, then by the time books and lecture >>> notes are all updated, they will be able to tell a much nicer story than >>> the current one? >> >> >> This is a multi-year, "boil the ocean"-style project, affecting literally >> every Haskell user, and the end result after all of this labor is going to >> be... a slightly spiffier bike shed? >> >> Strongly -1 from me also. My experience over the last couple of years is >> that every GHC release breaks my libraries in annoying ways that require >> CPP to fix: >> >> ~/personal/src/snap ? find . -name '*.hs' | xargs egrep >> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l >> 64 >> >> >> As a user this is another bikeshedding change that is not going to >> benefit me at all. Maintaining a Haskell library can be an exasperating >> exercise of running on a treadmill to keep up with busywork caused by >> changes to the core language and libraries. My feeling is starting to >> become that the libraries committee is doing as much (if not more) to >> *cause* problems and work for me than it is doing to improve the common >> infrastructure. >> > > On the libraries I maintain and have a copy of on my computer right now: > 329 > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.jan.mrotek at gmail.com Mon Oct 5 19:21:52 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Mon, 5 Oct 2015 21:21:52 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5612B320.3060701@ucdavis.edu> Message-ID: > There's an argument that this proposal involves very little up-front > breakage. This is true but disingenuous, because the breakage will still > happen in the future unless changes are made and committed. The entire > maintenance load should be considered, not just the immediate load. I don't have much to say about breakage (and thus I've refrained from voting), as a maintainer of just 7 packages of which exactly zero are compatible with anything else than the latest GHC (well, no one complained, I'm rather lazy, and if it's any defense I can't even run GHC 7.10.1 on my Arch Linux box because of inappropriate versions of dynamically linked libraries), but a honest question: does this proposal entail anything else than replacing every "return" with "pure" and conditional compilation of "return = pure" in Monad instances? Best regards, Marcin Mrotek From quentin.leguennec1 at gmail.com Mon Oct 5 19:37:49 2015 From: quentin.leguennec1 at gmail.com (Quentin Le Guennec) Date: Mon, 5 Oct 2015 21:37:49 +0200 Subject: [Haskell-cafe] Teaching haskell at the 42 french school Message-ID: Hi, as an introduction, it would be a good advice to first look, if you did not heard of it yet, at what the 42 school is: http://www.42.fr/42-revolutionary-computer-training-free-and-open-to-all/ (TL;DR: *"unique pedagogical approach and accessibility to all, completely free of charge, 42 is the most daring response yet to the challenge of information-technology skill development", "**Innovative teaching methods in technology training: Peer-to-Peer learning"*) ?The school aims to teach a general knowledge of computer science, but does not provide a Haskell course yet. ?The exercices and projects are built by students, for students. I love haskell and I'd be really happy to teach that wonderful language, and I'd love to hear your suggestions. I was thinking of the haskell's hard learning way. (I gotta say, the school's pedagogy is pretty sadistic). - Recode List, (,), Either, Maybe and their functor/applicative/monad/etc instances (implying recode those data types first) - String manipulation (basically recode Data.List). Any ideas for prevent students from just copy pasting the hackage code source? - Red black trees are fun, aren't they? - Some kind of AI to solve, for example, Rubik's cube One other thing, this may be very sadistic, but I would like to ask what do you think of allowing ONLY pointfree? It may end-up by having different answers and promote beautiful and concise code. Please expose your ideas, everything is feasible, bonus added to traps, hard to solve problems, and everything that may lead the student to think a lot. Thanks. -- Quentin Le Guennec -------------- next part -------------- An HTML attachment was scrubbed... URL: From yom at artyom.me Mon Oct 5 19:56:10 2015 From: yom at artyom.me (Artyom) Date: Mon, 05 Oct 2015 22:56:10 +0300 Subject: [Haskell-cafe] Teaching haskell at the 42 french school In-Reply-To: References: Message-ID: <5612D5DA.9090702@artyom.me> > what do you think of allowing ONLY pointfree? It may end-up by having different answers and promote beautiful and concise code This would be very sadistic, yes ? to people who would have to read code written by 42's graduates! I urge you to avoid it. > Red black trees are fun, aren't they? They are also on a rather different level of difficulty from rewriting Data.List and friends (which is what beginners often do on their first day of learning). So, I don't understand what your intended level actually is. If it's ?can understand red-black trees and write them without blindly copying code?, you could skip rewriting Data.List and go straight to: * monad transformers * lenses * the Cont monad * free monads On the other hand, if rewriting Data.List is necessary, then take a look at Richard Bird's book Thinking Functionally With Haskell ? it would be a perfect fit for you. From alan.zimm at gmail.com Mon Oct 5 20:27:30 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 5 Oct 2015 22:27:30 +0200 Subject: [Haskell-cafe] ANN: HaRe 0.8 - The Haskell Refactorer In-Reply-To: References: Message-ID: Update: Version 0.8.1 is out, which fixes renaming that crosses module boundaries and preserves CPP directives On Sun, Oct 4, 2015 at 10:18 PM, Alan & Kim Zimmerman wrote: > I'm pleased to announce the release of HaRe 0.8, available on hackage [1] > > What's new? > =========== > > Everything, and nothing. > > Everything in the sense that it has been completely reworked internally to > make > use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint > [3] > library. > > Nothing in the sense that the functionality in this version is/should be > identical to that in 0.7.2.8 > > Limitations > =========== > > HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation. > Compiling > HaRe with 7.10.2 and then using it against projects using an earlier > compiler > will not work, as HaRe needs to be able to invoke GHC to the type checker > stage > on the project using GHC 7.10.2. > > What is it? > =========== > > HaRe makes changes to working code, so that it still works once the change > is > made. > > Refactorings it can do are > > * demote > > Take a declaration from the level where it is defined and move it down > to the > place where it is used. This only works if it is used in one place only. > > * dupdef > > Duplicate a definition with a new name. > > * iftocase > > Convert an if declaration to a case declaration. > > * liftOneLevel > > Move a declaration one level up, adding parameters as needed to pass in > locally declared variables. > > * liftToTopLevel > > Move a declaration to the top level, adding parameters as needed to pass > in > locally declared variables. > > * rename > > Change a name throughout the project. This makes use of the GHC renamed > source > so will not change other names that just happen to be lexically > identical, but > are in fact different names. > > It currently has an emacs integration only, assistance in supporting other > environnments welcome. > > [1] https://hackage.haskell.org/package/HaRe > [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations > [3] https://hackage.haskell.org/package/ghc-exactprint > > Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantkiew at gsd.uwaterloo.ca Mon Oct 5 21:21:13 2015 From: mantkiew at gsd.uwaterloo.ca (mantkiew at gsd.uwaterloo.ca) Date: Mon, 05 Oct 2015 17:21:13 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <20151005212113.5476430.73664.12679@gsd.uwaterloo.ca> I loved the statement made by Ryan Trinkle in his recent talk [1]: "since we cannot predict all the changes needed the future, we must have an architecture that will support any change" (it's roughly like that, not an exact quote, about 4minutes in). Having to use IFDEFs is a sign that the language itself is not expressive enough to deal with these kinds of changes and therefore it's not having the right "architecture". Is Backpack going to provide the necessary support, (e.g., ability to mix in package fragments with extensions instead of making breaking changes)? What kind of language features are still missing? Anyway, mistakes were made in the past, because had we known any better we would have done better. Nothing should prevent us from fixing mistakes. Regarding IFDEFS, all of them disappeared from my code once I used transformers-compat and mtl-compat. ?Also the trick with import Prelude worked-you just have to list what you hide instead of what you import (which is weird...).? -- Micha? [1] http://www.infoq.com/presentations/functional-techniques-complexity On Mon, Oct 5, 2015 at 2:34 PM, Gregory Collins wrote: > > On Mon, Oct 5, 2015 at 8:09 AM, Gershom B wrote: >> >> My understanding of the argument here, which seems to make sense to me, is >> that the AMP already introduced a significant breaking change with regards >> to monads. Books and lecture notes have already not caught up to this, by >> and large. Hence, by introducing a further change, which _completes_ the >> general AMP project, then by the time books and lecture notes are all >> updated, they will be able to tell a much nicer story than the current one? > > > This is a multi-year, "boil the ocean"-style project, affecting literally > every Haskell user, and the end result after all of this labor is going to > be... a slightly spiffier bike shed? > > Strongly -1 from me also. My experience over the last couple of years is > that every GHC release breaks my libraries in annoying ways that require CPP > to fix: > > ~/personal/src/snap ? find . -name '*.hs' | xargs egrep > '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l > 64 > > > As a user this is another bikeshedding change that is not going to benefit > me at all. Maintaining a Haskell library can be an exasperating exercise of > running on a treadmill to keep up with busywork caused by changes to the > core language and libraries. My feeling is starting to become that the > libraries committee is doing as much (if not more) to cause problems and > work for me than it is doing to improve the common infrastructure. > > G > -- > Gregory Collins > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From acfoltzer at gmail.com Mon Oct 5 21:23:08 2015 From: acfoltzer at gmail.com (Adam Foltzer) Date: Mon, 5 Oct 2015 14:23:08 -0700 Subject: [Haskell-cafe] Language Change Management (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <87lhbhperb.fsf_-_@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87lhbhperb.fsf_-_@gnu.org> Message-ID: Thanks for splitting this off, as it really deserves its own conversation. % find cryptol -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l 49 % find saw-script -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l 242 I introduced most of these in order to accommodate AMP, and now I learn that there is another proposal that is considered to be part-and-parcel with AMP where I will have to make yet more changes to the same code and presumably introduce another layer of #ifdefs. As proposed, I will spend 2*n hours implementing, testing, and releasing these changes. Had both changes been bundled, it would have been 2*(n+?). Also I'm not sure if there would be less complaints if AMP/FTP/MFP/MRP/etc > as part of a new Haskell Report would be switched on all at once in e.g. > `base-5.0`, breaking almost *every* single package out there at once. I doubt the number of complaints-per-change would be fewer, but I'm strongly in favor of moving away from what feels like a treadmill that doesn't value the time of developers and that doesn't account for the more-than-sum-of-parts cost of the "constant flux". Thanks, Adam On Mon, Oct 5, 2015 at 7:32 AM, Herbert Valerio Riedel wrote: > On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote: > > 2015-10-05 11:59 GMT+02:00 Simon Thompson : > > > >> [...] It?s really interesting to have this discussion, which pulls in > all > >> sorts of well-made points about orthogonality, teaching, the evolution > of > >> the language and so on, but it simply goes to show that the process of > >> evolving Haskell is profoundly broken. [...] > >> > > > > I wouldn't necessarily call the process "broken", but it's a bit > > annoying: Because of the constant flux of minor changes in the > > language and the libraries, I've reached the stage where I'm totally > > unable to tell if my code will work for the whole GHC 7.x series. The > > only way I see is doing heavy testing on Travis CI and littering the > > code with #ifdefs after compilation failures. (BTW: Fun exercise: Try > > using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for > > keeping the #ifdefs centralized. No clue how to do that...) This is > > less than satisfactory IMHO, and I would really prefer some other mode > > for introducing such changes: Perhaps these should be bundled and > > released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way > > some stuff which belongs together (AMP, FTP, kicking out return, etc.) > > comes in slightly larger, but more sensible chunks. > > > > Don't get me wrong: Most of the proposed changes in itself are OK and > > should be done, it's only the way they are introduced should be > > improved... > > I think that part of the reason we have seen these changes occur in a > "constant flux" rather than in bigger coordinated chunks is that faith > in the Haskell Report process was (understandably) abandoned. And > without the Haskell Report as some kind of "clock generator" with which > to align/bundle related changes into logical units, changes occur > whenever they're proposed and agreed upon (which may take several > attempts as we've seen with the AMP and others). > > I hope that the current attempt to revive the Haskell Prime process will > give us a chance to clean up the unfinished intermediate `base-4.8` > situation we're left with now after AMP, FTP et al, as the next Haskell > Report revision provides us with a milestone to work towards. > > That being said, there's also the desire to have changes field-tested by > a wide audience on a wide range before integrating them into a Haskell > Report. Also I'm not sure if there would be less complaints if > AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on > all at once in e.g. `base-5.0`, breaking almost *every* single package > out there at once. > > For language changes we have a great way to field-test new extensions > before integrating them into the Report via `{-# LANGUAGE #-}` pragmas > in a nicely modular and composable way (i.e. a package enabling a > certain pragma doesn't require other packages to use it as well) which > have proven to be quite popular. > > However, for the library side we lack a comparable mechanism at this > point. The closest we have, for instance, to support an isolated > Haskell2010 legacy environment is to use RebindableSyntax which IMO > isn't good enough in its current form[1]. And then there's the question > whether we want a Haskell2010 legacy environment that's isolated or > rather shares the types & typeclasses w/ `base`. If we require sharing > types and classes, then we may need some facility to implicitly > instanciate new superclasses (e.g. implicitly define Functor and > Applicative if only a Monad instance is defined). If we don't want to > share types & classes, we run into the problem that we can't easily mix > packages which depend on different revisions of the standard-library > (e.g. one using `base-4.8` and others which depend on a legacy > `haskell2010` base-API). One way to solve this could be to mutually > exclude depending on both , `base-4.8` and `haskell2010`, in the same > install-plan (assuming `haskell2010` doesn't depend itself on > `base-4.8`) > > In any case, I think we will have to think hard how to address > language/library change management in the future, especially if the > Haskell code-base continues to grow. Even just migrating the code base > between Haskell Report revisions is a problem. An extreme example > is the Python 2->3 transition which the Python ecosystem is still > suffering from today (afaik). Ideas welcome! > > > > [1]: IMO, we need something to be used at the definition site providing > desugaring rules, rather than requiring the use-site to enable a > generalised desugaring mechanism; I've been told that Agda has an > interesting solution to this in its base libraries via > {-# LANGUAGE BUILTIN ... #-} pragmas. > > > Regards, > H.V.Riedel > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From b at chreekat.net Mon Oct 5 22:18:29 2015 From: b at chreekat.net (Bryan Richter) Date: Mon, 5 Oct 2015 15:18:29 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> Message-ID: On Mon, Oct 5, 2015 at 06:43-0700, mantkiew wrote: > > Well, there are the *compat packages: > > Base-compat > Transformers-compat > Mtl-compat > > Etc. They do centralize the ifdefs and give you compatibility with > GHC 7.*. I recently adopted the last two ones and they work like > a charm. I am yet to adopt base-compat, so I don't know what the > experience is with it. Hang on a moment, are you saying that all the people writing to argue that these changes would require them to write dozens more #ifdef's actually don't have to write any at all? I never knew what the *-compat packages were all about. If that's what they're designed to do, I have a feeling they have not gotten *nearly* enough exposure. [Apologies for possible cross-posting; this thread jumped into my inbox from I-know-not-where and already has half a dozen CCs attached.] -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Mon Oct 5 22:29:34 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 6 Oct 2015 00:29:34 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5612B320.3060701@ucdavis.edu> Message-ID: <5612F9CE.8060106@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/10/15 20:50, Nathan Bouscal wrote: > There have been a lot of objections based on the idea that > learners will consult books that are out of date, but the number of > learners affected by this is dwarfed by the number of learners who > will use updated materials and be confused by this strange > historical artifact. Permanently-enshrined historical artifacts > accrete forever and cause linear confusion, whereas outdated > materials are inevitably replaced such that the amount of confusion > remains constant. Thank you for making this point I would be very saddened if the appeal to history (i.e. technical debt) would halt our momentum. That's what happens to most things both in and out of computer science. And it's honestly depressing. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWEvnNAAoJENQqWdRUGk8BrqEQAKcWj2Gv/4gVzTq++m1lU+r1 9TxdBXG+V+y66yyqpZAv4tOOCVtkDYR6/qUGtpYO5cdmh8mYKh5PUvb/p/l1AUQl Ug8gVO+u+yvwkVif8Jhhl+e8JqYGPgH6+lUvA8VE47VNkYGKMsNlXFYPik8Sc22w 6EhS7SRhR57quOclQw2NRIxS4F3ZqE7YKkXETId9QBtder9e6OEYdc4pQivcr46H FHzK3ybRF80U/3lKivPFo/114ICrS0l/Mneqf2ITLso6HFAZXhms5RzuSOaxLSbI xAV2k9gRv6cPWdMgx7DCjiOOsNc78peAcqwlEdQ5dJWGs5fu70hsKqNAL3LYCmRC YTcC2F1kJmuKYucHzfDLFYiVgbn03ehZkkx4b9NFQyHwj8rBNn4E4JspjOR/ej9w p3e3lGCj/Voouq+bIb5AAlp01Bioxew/+ewQeI739js9b9LE0wZQvFbYfngxdmf4 Z7IADHsfou7xtiChXbSkOlOEI3mDYTXXxeTSmF/OY7HVnCReCKtVa0Aj5j9G116V LrMeUegOFMazlbpyG2GGvp7zD/3xTH3v6zpNcj8ijsCIXtch7ygebA5ecXZ0m30s y6VoVMPkQtHdAaaO5qi7MY+/cSNAiJdEcKR4hSZxPrFqUsiOJ006FMhh1PcSRjBx 3IMLL+8mPsvTnfWDj+NY =Mwbu -----END PGP SIGNATURE----- From tonymorris at gmail.com Mon Oct 5 22:31:25 2015 From: tonymorris at gmail.com (Tony Morris) Date: Tue, 6 Oct 2015 08:31:25 +1000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5612F9CE.8060106@plaimi.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5612B320.3060701@ucdavis.edu> <5612F9CE.8060106@plaimi.net> Message-ID: <5612FA3D.7050207@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 +1 On 06/10/15 08:29, Alexander Berntsen wrote: > On 05/10/15 20:50, Nathan Bouscal wrote: >> There have been a lot of objections based on the idea that >> learners will consult books that are out of date, but the number >> of learners affected by this is dwarfed by the number of >> learners who will use updated materials and be confused by this >> strange historical artifact. Permanently-enshrined historical >> artifacts accrete forever and cause linear confusion, whereas >> outdated materials are inevitably replaced such that the amount >> of confusion remains constant. > Thank you for making this point > > I would be very saddened if the appeal to history (i.e. technical > debt) would halt our momentum. That's what happens to most things > both in and out of computer science. And it's honestly depressing. > _______________________________________________ Haskell-Cafe > mailing list Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWEvo3AAoJEFkczQCvdvv0BQMH/2oxlo35Y4oFw2ZYMMjmb8es Asm7IrQCOoYRH10mgFhZiNPsZakRrEBsk6QD6iyIk6DGGoA7YBuQ2DwOE3Hzr2Ih jelQbB0Lqs6P3bj5EibZ1qad+g0zR9RWkjp+7R+zsbhQ3cu4WITT0EI5nwLIacE3 xKmT9WuWcd166rRJrpFSs7gCzQwtWPHropQgnXttx/85Uw6zxA//EimUqsIaLPI7 Yu8IlxqpbICgq7uWni1f1EVajNEIk4qewezrlahrJuBMcBqZ7jAknMIO06UIGFjv ZZm5lBRc+c++XmwSAVdo+5StiILzHftrlqsW3dVoJLvFFKdKYRDhd3auA+PB/Oo= =ND0C -----END PGP SIGNATURE----- From doug at cs.dartmouth.edu Mon Oct 5 22:59:21 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 05 Oct 2015 18:59:21 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal Message-ID: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU> > littering the code with #ifdefs > Bonus points for keeping the #ifdefs centralized Littering is the right word. "Bonus" is merely less negative points. It is ironic that the beautiful Haskell should progress by adopting the worst feature of C. #ifdef is a sticking-plaster for non-portable code. It is inserted at global level, usually to effect changes at the bottom of the code hierarchy. (Maybe in Haskell it should be a monad, in competition with IO for the outermost layer.) Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed) inescapably nonportable code, such as endianity, in compilation units and #include files in a distinct part of the file system tree selected by the shell. Another trick is to use plain if rather than #if or #ifdef, and let the compiler optimize away the unwanted side of the branch. In any event, #ifdef is, as Simon evidently agrees, evidence From doug at cs.dartmouth.edu Mon Oct 5 23:07:59 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 05 Oct 2015 19:07:59 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal Message-ID: <201510052307.t95N7xqK013994@coolidge.cs.Dartmouth.EDU> Sorry for the premature send. The incomplete sentence was: In any event, #ifdef is, as Simon evidently agrees, telling evidence of non-portability. It is hard to imagine an uglier "solution" to keeping up with the drip-drip-drip of Haskell evolution. doug From greg at gregorycollins.net Tue Oct 6 00:40:43 2015 From: greg at gregorycollins.net (Gregory Collins) Date: Mon, 5 Oct 2015 17:40:43 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> Message-ID: On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter wrote: > Hang on a moment, are you saying that all the people writing to argue > that these changes would require them to write dozens more #ifdef's > actually don't have to write any at all? > Um, no, it usually isn't anything like that. Here's a sampling of some of the things I've used CPP for in the past few years: - After GHC 7.4, when using a newtype in FFI imports you need to import the constructor, i.e. "import Foreign.C.Types(CInt(..))" --- afaik CPP is the only way to shut up warnings everywhere - defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5 (no compat package for this, afaik) - one of many various changes to Typeable in the GHC 7.* series (deriving works better now, mkTyCon vs mkTyCon3, etc) - Do I have to hide "catch" from Prelude, or not? It got moved, and "hiding" gives an error if the symbol you're trying to hide is missing. Time to break out the CPP (and curse myself for not just using the qualified import in the first place) - Do I get monoid functions from Prelude or from Data.Monoid? Same w/ Applicative, Foldable, Word. I don't know where anything is supposed to live anymore, or which sequence of imports will shut up spurious warnings on all four versions of GHC I support, so the lowest-friction fix is: break out the #ifdef spackle - ==# and friends return Int# instead of Bool after GHC 7.8.1 - To use functions like "tryReadMVar", "unsafeShiftR", and "atomicModifyIORef'" that are in recent base versions but not older ones (this is a place where CPP use is actually justified) -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From wren at community.haskell.org Tue Oct 6 00:49:19 2015 From: wren at community.haskell.org (wren romano) Date: Mon, 5 Oct 2015 20:49:19 -0400 Subject: [Haskell-cafe] Language Change Management (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87lhbhperb.fsf_-_@gnu.org> Message-ID: On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer wrote: >> Also I'm not sure if there would be less complaints if >> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all >> at once in e.g. `base-5.0`, breaking almost *every* single package out there >> at once. > > I doubt the number of complaints-per-change would be fewer, but I'm strongly > in favor of moving away from what feels like a treadmill that doesn't value > the time of developers and that doesn't account for the > more-than-sum-of-parts cost of the "constant flux". Broadly speaking, I'm a "fix it now rather than later" sort of person in Haskell because I've seen how long things can linger before finally getting fixed (even when everyone agrees on what the fix should be and agrees that it should be done). However, as I mentioned in the originating thread, I think that ?at this point? when it comes to AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to work out a comprehensive solution (as soon as possible), and then enact all the changes at once when switching to Haskell201X/base-5.0/whatevs. I understand the motivations for wanting things to be field-tested before making it into the report, but I don't think having a series of rapid incremental changes is the correct approach here. Because we're dealing with the Prelude and the core classes, the amount of breakage (and CPP used to paper over it) here is much higher than our usual treadmill of changes; so we should take that into account when planning how to roll the changes out. -- Live well, ~wren From mantkiew at gsd.uwaterloo.ca Tue Oct 6 00:49:37 2015 From: mantkiew at gsd.uwaterloo.ca (=?UTF-8?Q?Micha=C5=82_Antkiewicz?=) Date: Mon, 5 Oct 2015 20:49:37 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> Message-ID: All I am saying is that these various *compat packages manage to encapsulate the ifdefs to some degree. Here's the record of my struggle [1]. Then came Edward K. and told me to use transformers-compat [2]. Then Adam B. chimed in suggesting mtl-compat [3]. That's it. All my IFDEFs related to this topic were gone. I looked at base-compat [4] and it's very interesting. The big question is: **Why cannot normal base be written the same way as base-compat? ** It would then automatically provide compatibility across all GHC versions. Micha? [1] https://www.reddit.com/r/haskell/comments/3gqqu8/depending_on_both_mtl2131_for_stackage_lts2_and/ [2] https://www.reddit.com/r/haskell/comments/3gqqu8/depending_on_both_mtl2131_for_stackage_lts2_and/cu0l6nf [3] https://www.reddit.com/r/haskell/comments/3gqqu8/depending_on_both_mtl2131_for_stackage_lts2_and/cu5g73q [4] https://hackage.haskell.org/package/base-compat On Mon, Oct 5, 2015 at 6:18 PM, Bryan Richter wrote: > On Mon, Oct 5, 2015 at 06:43-0700, mantkiew wrote: >> >> Well, there are the *compat packages: >> >> Base-compat >> Transformers-compat >> Mtl-compat >> >> Etc. They do centralize the ifdefs and give you compatibility with >> GHC 7.*. I recently adopted the last two ones and they work like >> a charm. I am yet to adopt base-compat, so I don't know what the >> experience is with it. > > Hang on a moment, are you saying that all the people writing to argue > that these changes would require them to write dozens more #ifdef's > actually don't have to write any at all? I never knew what the *-compat > packages were all about. If that's what they're designed to do, I have a > feeling they have not gotten *nearly* enough exposure. > > [Apologies for possible cross-posting; this thread jumped into my inbox > from I-know-not-where and already has half a dozen CCs attached.] From rf at rufflewind.com Tue Oct 6 01:00:21 2015 From: rf at rufflewind.com (Phil Ruffwind) Date: Mon, 5 Oct 2015 21:00:21 -0400 Subject: [Haskell-cafe] Language Change Management (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87lhbhperb.fsf_-_@gnu.org> Message-ID: Having so many #ifdefs isn't by itself a major problem. Yes, it does introduce a small increase in compilation time and the size of the codebase. The real cost is the developer time: every developer has to come up with these these #ifdef clauses from scratch for every change that gets made, tailored to their specific code. As more and more get added, it becomes more and more of a confusing mess. It makes me wonder if this can be automated somehow. It would be nice to have a mechanism to alleviate this cost so that most developers downstream (provided that the code was written in a reasonable manner) only need to make a minimal effort to keep up, while still being able to write code that works for a reasonably large range of GHC versions. The burden of breaking changes right now is on the downstream developers, but perhaps there could be a way to shift most of that upstream to avoid this large duplication of effort. Haskell should be allowed to evolve, but there also needs to be a counterweight mechanism that provides stability in the face of constant changes. It would be something similar in spirit to base-compat, but I don't think a library package alone is powerful enough to solve the problem: a missing 'return' for example is not something a library can just patch in. I don't have any preference for "lots of small changes" vs "one big change": in the former, there is a lot of overhead needed to keep track of and fix these small changes; in the latter, there is a risk of introducing a rift that fragments the community (cf Python 2 vs 3). Maybe something in-between would be the best. From amindfv at gmail.com Tue Oct 6 01:20:40 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 5 Oct 2015 21:20:40 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5612F9CE.8060106@plaimi.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5612B320.3060701@ucdavis.edu> <5612F9CE.8060106@plaimi.net> Message-ID: <0DD58DFC-B002-4D09-A91F-66D964BB6845@gmail.com> IMO, the "tech debt" you're talking about feels very small. We've already made the change that return = pure by default. The historical baggage that this proposal cleans up is just the fact that legacy code is able to define its own "return" without breaking (which must be the same as the definition of pure anyway). I am also moving from +0.5 to +0 on this. Tom > El 5 oct 2015, a las 18:29, Alexander Berntsen escribi?: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > >> On 05/10/15 20:50, Nathan Bouscal wrote: >> There have been a lot of objections based on the idea that >> learners will consult books that are out of date, but the number of >> learners affected by this is dwarfed by the number of learners who >> will use updated materials and be confused by this strange >> historical artifact. Permanently-enshrined historical artifacts >> accrete forever and cause linear confusion, whereas outdated >> materials are inevitably replaced such that the amount of confusion >> remains constant. > Thank you for making this point > > I would be very saddened if the appeal to history (i.e. technical > debt) would halt our momentum. That's what happens to most things both > in and out of computer science. And it's honestly depressing. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCgAGBQJWEvnNAAoJENQqWdRUGk8BrqEQAKcWj2Gv/4gVzTq++m1lU+r1 > 9TxdBXG+V+y66yyqpZAv4tOOCVtkDYR6/qUGtpYO5cdmh8mYKh5PUvb/p/l1AUQl > Ug8gVO+u+yvwkVif8Jhhl+e8JqYGPgH6+lUvA8VE47VNkYGKMsNlXFYPik8Sc22w > 6EhS7SRhR57quOclQw2NRIxS4F3ZqE7YKkXETId9QBtder9e6OEYdc4pQivcr46H > FHzK3ybRF80U/3lKivPFo/114ICrS0l/Mneqf2ITLso6HFAZXhms5RzuSOaxLSbI > xAV2k9gRv6cPWdMgx7DCjiOOsNc78peAcqwlEdQ5dJWGs5fu70hsKqNAL3LYCmRC > YTcC2F1kJmuKYucHzfDLFYiVgbn03ehZkkx4b9NFQyHwj8rBNn4E4JspjOR/ej9w > p3e3lGCj/Voouq+bIb5AAlp01Bioxew/+ewQeI739js9b9LE0wZQvFbYfngxdmf4 > Z7IADHsfou7xtiChXbSkOlOEI3mDYTXXxeTSmF/OY7HVnCReCKtVa0Aj5j9G116V > LrMeUegOFMazlbpyG2GGvp7zD/3xTH3v6zpNcj8ijsCIXtch7ygebA5ecXZ0m30s > y6VoVMPkQtHdAaaO5qi7MY+/cSNAiJdEcKR4hSZxPrFqUsiOJ006FMhh1PcSRjBx > 3IMLL+8mPsvTnfWDj+NY > =Mwbu > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From amindfv at gmail.com Tue Oct 6 01:24:26 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 5 Oct 2015 21:24:26 -0400 Subject: [Haskell-cafe] Language Change Management (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87lhbhperb.fsf_-_@gnu.org> Message-ID: <2F902D16-CED6-46D4-A596-5826DC14E5EF@gmail.com> Another problem with #ifdefs (especially machine-generated ones) is that it makes code much harder to read. One of the things I love about Haskell is the ability to read code and literally see an author describe how they're thinking about the domain. #ifdefs make life less fun :) Tom > El 5 oct 2015, a las 21:00, Phil Ruffwind escribi?: > > Having so many #ifdefs isn't by itself a major problem. Yes, it does > introduce a small increase in compilation time and the size of the > codebase. The real cost is the developer time: every developer has to > come up with these these #ifdef clauses from scratch for every change > that gets made, tailored to their specific code. As more and more get > added, it becomes more and more of a confusing mess. > > It makes me wonder if this can be automated somehow. It would be nice > to have a mechanism to alleviate this cost so that most developers > downstream (provided that the code was written in a reasonable manner) > only need to make a minimal effort to keep up, while still being able > to write code that works for a reasonably large range of GHC versions. > The burden of breaking changes right now is on the downstream > developers, but perhaps there could be a way to shift most of that > upstream to avoid this large duplication of effort. > > Haskell should be allowed to evolve, but there also needs to be a > counterweight mechanism that provides stability in the face of > constant changes. It would be something similar in spirit to > base-compat, but I don't think a library package alone is powerful > enough to solve the problem: a missing 'return' for example is not > something a library can just patch in. > > I don't have any preference for "lots of small changes" vs "one big > change": in the former, there is a lot of overhead needed to keep > track of and fix these small changes; in the latter, there is a risk > of introducing a rift that fragments the community (cf Python 2 vs 3). > Maybe something in-between would be the best. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From tonymorris at gmail.com Tue Oct 6 01:52:22 2015 From: tonymorris at gmail.com (Tony Morris) Date: Tue, 6 Oct 2015 11:52:22 +1000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <0DD58DFC-B002-4D09-A91F-66D964BB6845@gmail.com> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5612B320.3060701@ucdavis.edu> <5612F9CE.8060106@plaimi.net> <0DD58DFC-B002-4D09-A91F-66D964BB6845@gmail.com> Message-ID: <56132956.5040204@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 - -- I am going to do some logging, yay! data Logs a = Logs a [a] deriving (Eq, Show) - -- one log message singlelog :: a -> Logs a singlelog a = Logs a [] - -- two log messages twologs :: a -> a -> Logs a twologs a1 a2 = Logs a1 [a2] class Semigroup a where (<>) :: a -> a -> a - -- I can append logs instance Semigroup (Logs a) where Logs h1 t1 <> Logs h2 t2 = Logs h1 (t1 ++ h2 : t2) - -- I can map on Logs instance Functor Logs where fmap f (Logs h t) = Logs (f h) (fmap f t) - -- I will collect logs with a value data WriteLogs l a = WriteLogs (Logs l) a deriving (Eq, Show) - -- I can map the pair of logs and a value instance Functor (WriteLogs l) where fmap f (WriteLogs l a) = WriteLogs l (f a) singlewritelog :: l -> a -> WriteLogs l a singlewritelog l a = WriteLogs (singlelog l) a - -- Monad without return class Bind f where (-<<) :: (a -> f b) -> f a -> f b - -- Can I Applicativate WriteLogs? Let's see. instance Applicative (WriteLogs l) where -- Well that was easy. WriteLogs l1 f <*> WriteLogs l2 a = WriteLogs (l1 <> l2) (f a) pure a = WriteLogs (error "wait, what goes here?") a -- Oh I guess I cannot Applicativate WriteLogs, but I can Apply them! - -- Well there goes that idea. - -- instance Monad (WriteLogs l) where - -- Wait a minute, can I bind WriteLogs? instance Bind (WriteLogs l) where -- Of course I can! f -<< WriteLogs l1 a = let WriteLogs l2 b = f a in WriteLogs (l1 <> l2) b - -- OK here goes ... myprogram :: WriteLogs String Int myprogram = -- No instance for (Monad (WriteLogs String)) -- RAR!, why does do-notation require extraneous constraints?! -- Oh that's right, Haskell is broken. -- Oh well, I guess I need to leave Prelude turned off and rewrite the base libraries. do a <- singlewritelog "message" 18 b <- WriteLogs (twologs "hi" "bye") 73 WriteLogs (singlelog "exit") (a * b) - -- One day, one day soon, I can move on. On 06/10/15 11:20, amindfv at gmail.com wrote: > IMO, the "tech debt" you're talking about feels very small. We've > already made the change that return = pure by default. The > historical baggage that this proposal cleans up is just the fact > that legacy code is able to define its own "return" without > breaking (which must be the same as the definition of pure > anyway). I am also moving from +0.5 to +0 on this. > > Tom > > >> El 5 oct 2015, a las 18:29, Alexander Berntsen >> escribi?: >> >>>> On 05/10/15 20:50, Nathan Bouscal wrote: There have been a >>>> lot of objections based on the idea that learners will >>>> consult books that are out of date, but the number of >>>> learners affected by this is dwarfed by the number of >>>> learners who will use updated materials and be confused by >>>> this strange historical artifact. Permanently-enshrined >>>> historical artifacts accrete forever and cause linear >>>> confusion, whereas outdated materials are inevitably replaced >>>> such that the amount of confusion remains constant. > Thank you for making this point > > I would be very saddened if the appeal to history (i.e. technical > debt) would halt our momentum. That's what happens to most things > both in and out of computer science. And it's honestly depressing. >> _______________________________________________ Haskell-Cafe >> mailing list Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe > mailing list Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWEylQAAoJEFkczQCvdvv08KMIAIGEwj6dQqnk8Z3zjFC1Vpvb LTXdnzlcXCMXmIdzr9RaSGUKo52b3BPaP6EgFDJm8U/CJYQ/X8FAyy0gmKVJlru4 JQc4Y+CcGqz7+UwfYRlOOJDFNscigvGDj33N3hp3G/HuWfvllWJSx9n7gTqSrnXS W/jTDN3sntJWiCdC+A5rLoqzH3eZ2LhwB0iL26DSfE1OLPyBK2kignKCjnMtRbEq xY5vjx7xLQKzApRARIrBdDNVuXVRy+QQyGTGmdOKaLscNNrMzewcUr8LZLRG+6W7 RKA12y3etcVXGRlACHNn67mUKJIlKWX5PZSVsj07SZNWp3eyDctHfKuqYonfgJU= =G8G2 -----END PGP SIGNATURE----- From rustompmody at gmail.com Tue Oct 6 03:43:43 2015 From: rustompmody at gmail.com (Rustom Mody) Date: Tue, 6 Oct 2015 09:13:43 +0530 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` Message-ID: On Tue, Oct 6, 2015 at 4:29 AM, Doug McIlroy wrote: > > littering the code with #ifdefs > > > Bonus points for keeping the #ifdefs centralized > > Littering is the right word. "Bonus" is merely less negative points. > > It is ironic that the beautiful Haskell should progress by > adopting the worst feature of C. #ifdef is a sticking-plaster > for non-portable code. It is inserted at global level, usually > to effect changes at the bottom of the code hierarchy. (Maybe > in Haskell it should be a monad, in competition with IO for > the outermost layer.) > > Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed) > inescapably nonportable code, such as endianity, in compilation > units and #include files in a distinct part of the file system > tree selected by the shell. > > Another trick is to use plain if rather than #if or #ifdef, > and let the compiler optimize away the unwanted side of the > branch. > > > In any event, #ifdef is, as Simon evidently agrees, telling > evidence of non-portability. It is hard to imagine an uglier > "solution" to keeping up with the drip-drip-drip of Haskell > evolution. > > The python 2?3 transition may have caused some pain to some. However it would have been far more difficult if they had not provided tools like 2to3 and six: https://docs.python.org/2/library/2to3.html http://pythonhosted.org/six/ Since the change here is trivial and pervasive why is such a tool not being considered? [Or have I missed the discussion?] In particular we can envisage a tool say 8to10 that has these modes (command-line flags) --portable --readable --info with the idea that - portable is most unreadable (ifdef litter) - readable is not portable -- generate a copy of the whole source tree that will have the changes and not be compatible for ghc < 7.8 This is for those library authors that prefer to maintain a clean code base and hell with earlier ghc versions - info summarizes which files would change and how so that a suitable reorganization of the files/directories can be done prior to the switch This is for those library authors that would like to take the trouble to have a compatibility layer and have code as readable as possible overall [Whether pure is really preferable to return is another matter -- For me one of the strongest criticisms of the python 2?3 switch is this that if they were going to break things anyhow why was the cleanup not more far-reaching? Lets keep this note in these parentheses :-) ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Tue Oct 6 07:04:02 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 6 Oct 2015 18:04:02 +1100 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> Message-ID: On 6 October 2015 at 11:40, Gregory Collins wrote: > > defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5 > (no compat package for this, afaik) http://hackage.haskell.org/package/time-locale-compat -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From hvr at gnu.org Tue Oct 6 07:10:12 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 09:10:12 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: (Johan Tibell's message of "Mon, 5 Oct 2015 21:01:16 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <87zizw8obv.fsf_-_@gnu.org> On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: > On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins [...] >> Strongly -1 from me also. My experience over the last couple of years is >> that every GHC release breaks my libraries in annoying ways that require >> CPP to fix: >> >> ~/personal/src/snap ? find . -name '*.hs' | xargs egrep >> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l >> 64 [...] > On the libraries I maintain and have a copy of on my computer right now: 329 Although this was already pointed out to you in a response to a Tweet of yours, I'd like to expand on this here to clarify: You say that you stick to the 3-major-ghc-release support-window convention for your libraries. This is good, because then you don't need any CPP at all! Here's why: So when GHC 8.2 is released, your support-window requires you to support GHC 7.10 and GHC 8.0 in addition to GHC 8.2. At this point you'll be happy that you can start dropping those #ifdefs you added for GHC 7.10 in your code in order to adapt to FTP & AMP. And when you do *that*, you can also drop all your `return = pure` methods overrides. (Because we prepared for MRP already in GHC 7.10 by introducing the default implementation for `return`!) This way, you don't need to introduce any CPP whatsoever due to MRP! Finally, since we're not gonna remove `return` in GHC 8.2 anyway, as GHC 8.2 was just the *earliest theoretical* possible GHC in which this *could* have happened. Realistically, this would happen at a much later point, say GHC 8.6 or even later! Therefore, the scheme above would actually work for 5-year time-windows! And there's even an idea on the table to have a lawful `return = pure` method override be tolerated by GHC even when `return` has already moved out of `Monad`! PS: I'm a bit disappointed you seem to dismiss this proposal right away categorically without giving us a chance to address your concerns. The proposal is not a rigid all-or-nothing thing that can't be tweaked and revised. That's why we're having these proposal-discussions in the first place (rather than doing blind +1/-1 polls), so we can hear everyone out and try to maximise the agreement (even if we will never reach 100% consensus on any proposal). So please, keep on discussing! From mwm at mired.org Tue Oct 6 07:58:29 2015 From: mwm at mired.org (Mike Meyer) Date: Tue, 06 Oct 2015 07:58:29 +0000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> Message-ID: On Tue, Oct 6, 2015 at 2:40 AM Bardur Arantsson wrote: > > - To use functions like "tryReadMVar", "unsafeShiftR", and > > "atomicModifyIORef'" that are in recent base versions but not older > ones > > (this is a place where CPP use is actually justified) > Well, yeah, new functions don't magically appear in old versions. I > don't anybody expects that :). > Right - they have to be backported, and imply maintenance of multiple branches. Python has been mentioned a couple of times. They did that, backporting functions that mimiced Python 3 functions to later Python 2 versions, which made the tools mentioned possible, or at least more capable. I'll refer those wanting fewer breaking changes to Python. Getting language changes accepted by the PYthon community is *hard*. You need a use case for your change, you need to show that the case can't be handled cleanly by the language as it exists today, that it's common enough to justify the change, and that it won't tempt people to write uglier code than the current solution. If you want to break old code, all those bars get raised - a lot. Or did, anyway, The result of following that was the Python 2/Python 3 split, which I don't think anybody thought was a good thing. Unavoidable, maybe - Python 3 had to break backwards compatibility, so they cleaned up everything along the way, and created tools to migrate code, and committed to maintaining both versions for an extended period of time. And the community was pretty badly splintered by this. The one thing I think they got right is documenting the language change process with the entire PEP process. We seem to have wiki pages, with no editorial oversight, and pages show up in google searches after they've been incorporated into the language in a different form. Not quite as good a thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Tue Oct 6 08:31:30 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 10:31:30 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: (Rustom Mody's message of "Tue, 6 Oct 2015 09:13:43 +0530") References: Message-ID: <87mvvw8kkd.fsf@gnu.org> On 2015-10-06 at 05:43:43 +0200, Rustom Mody wrote: [...] > The python 2?3 transition may have caused some pain to some. However it > would have been far more difficult if they had not provided tools like > 2to3 and six: > https://docs.python.org/2/library/2to3.html > http://pythonhosted.org/six/ > > Since the change here is trivial and pervasive why is such a tool not being > considered? > [Or have I missed the discussion?] It is being considered! :-) I'm in the process of collecting rewrite recipes and samples on https://github.com/hvr/Hs2010To201x Alan is looking into how HaRe can be leveraged for this. I've refrained from bringing this up, as I'm still waiting to reach a proof-of-concept stage where we can confidently say that this actually works. > In particular we can envisage a tool say 8to10 that has these modes > (command-line flags) > --portable > --readable > --info > > with the idea that > - portable is most unreadable (ifdef litter) > - readable is not portable -- generate a copy of the whole source tree that > will have the changes and not be compatible for ghc < 7.8 > This is for those library authors that prefer to maintain a clean code > base and hell with earlier ghc versions > - info summarizes which files would change and how so that a suitable > reorganization of the files/directories can be done prior to the switch > This is for those library authors that would like to take the trouble to > have a compatibility layer and have code as readable as possible overall > > [Whether pure is really preferable to return is another matter -- > For me one of the strongest criticisms of the python 2?3 switch is this > that if they were going to break things anyhow why was the cleanup not more > far-reaching? > > Lets keep this note in these parentheses :-) > > ] > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- "Elegance is not optional" -- Richard O'Keefe From ben at smart-cactus.org Tue Oct 6 08:44:29 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 06 Oct 2015 10:44:29 +0200 Subject: [Haskell-cafe] Reducing the need for CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <87k2r0z8r6.fsf@smart-cactus.org> Sven Panne writes: > 2015-10-05 17:09 GMT+02:00 Gershom B : > >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com) >> wrote: >> [...] As for libraries, it has been pointed out, I believe, that without >> CPP one can write instances compatible with AMP, and also with AMP + MRP. >> One can also write code, sans CPP, compatible with pre- and post- AMP. [...] >> > > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is > now part of the Prelude, you can't simply import some compatibility module, > because GHC might tell you (rightfully) that that import is redundant, > because (<$>) is already visible through the Prelude. So you'll have to use > CPP to avoid that import on base >= 4.8, be it from it Data.Functor, > Control.Applicative or some compat-* module. And you'll have to use CPP in > each and every module using <$> then, unless I miss something obvious. > AFAICT all transitioning guides ignore -Wall and friends... > This is a fair point that comes up fairly often. The fact that CPP is required to silence redundant import warnings is quite unfortunate. Others languages have better stories in this area. One example is Rust, which has a quite flexible `#[allow(...)]` pragma which can be used to acknowledge and silence a wide variety of warnings and lints [1]. I can think of a few ways (some better than others) how we might introduce a similar idea for import redundancy checks in Haskell, 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition, -- in Control.Applicative {-# ALLOW redundant_import (<$>) #-} (<$>) :: (a -> b) -> f a -> f b (<$>) = fmap asking the compiler to pretend that any import of the symbol did not exist when looking for redundant imports. This would allow library authors to appropriately mark definitions when they are moved, saving downstream users from having to make any change whatsoever. 2. Or alternatively we could make this a idea a bit more precise, -- in Control.Applicative {-# ALLOW redundant_import Prelude.(<$>) #-} (<$>) :: (a -> b) -> f a -> f b (<$>) = fmap Which would ignore imports of `Control.Applicative.(<$>)` only if `Prelude.(<$>)` were also in scope. 3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import, import {-# ALLOW redundant_import #-} Control.Applicative -- or perhaps import Control.Applicative {-# ALLOW redundant_import Control.Applicative #-} allowing the user to explicitly state that they are aware that this import may be redundant. 4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an import list, import Control.Applicative ((<$>) {-# ALLOW redundant_import #-}) allowing the user to explicitly state that they are aware that this imported function may be redundant. In general I'd like to reiterate that many of the comments in this thread describe genuine sharp edges in our language which have presented a real cost in developer time during the AMP and and FTP transitions. I think it is worth thinking of ways to soften these edges; we may be surprised how easy it is to fix some of them. - Ben [1] https://doc.rust-lang.org/stable/reference.html#lint-check-attributes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From _deepfire at feelingofgreen.ru Tue Oct 6 09:16:32 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Tue, 06 Oct 2015 12:16:32 +0300 Subject: [Haskell-cafe] Monad of no `return` Proposal In-Reply-To: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU> (sfid-20151006_032252_496842_92F9A6BF) (Doug McIlroy's message of "Mon, 05 Oct 2015 18:59:21 -0400") References: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU> Message-ID: <87lhbgl5lb.fsf@feelingofgreen.ru> Doug McIlroy writes: >> littering the code with #ifdefs > >> Bonus points for keeping the #ifdefs centralized > > Littering is the right word. "Bonus" is merely less negative points. > > It is ironic that the beautiful Haskell should progress by > adopting the worst feature of C. #ifdef is a sticking-plaster > for non-portable code. It is inserted at global level, usually > to effect changes at the bottom of the code hierarchy. (Maybe > in Haskell it should be a monad, in competition with IO for > the outermost layer.) > > Plan 9 showed the way out of ifdef, by putting (non-ifdef-ed) > inescapably nonportable code, such as endianity, in compilation > units and #include files in a distinct part of the file system > tree selected by the shell. > > Another trick is to use plain if rather than #if or #ifdef, > and let the compiler optimize away the unwanted side of the > branch. > > In any event, #ifdef is, as Simon evidently agrees, telling > evidence of non-portability. It is hard to imagine an uglier > "solution" to keeping up with the drip-drip-drip of Haskell > evolution. By the nature of the problem -- that is, because we want to isolate the compiler as much as possible -- the conditionalization must be performed as a separate pass. The conclusion is that some sort of pre-processor is inevitable. The remainder of the available choice space is about how ugly this pre-processor must be -- and indeed, CPP tends towards the undesirable end of the spectrum. As an example of the opposite end, consider Common Lisp, which: 1. reifies READ as the third processing phase (macroexpansion[1] and actual compilation being the other two) 2. operates at expression granularity 3. makes the full power of the language available to support the decision process of what subexpressions are available in which contexts As a rough example of how this works: http://clhs.lisp.se/Body/24_abaa.htm I don't know how much of Common Lisp preachery the list have suffered over the years, but I can't help but find this uniformity between the three parts of the language very appealing: - syntax-level of READ - macro-level of MACROEXPAND - semantics-level of the post-MACROEXPAND part of EVAL Maybe, just maybe, Haskell could borrow something from that.. -- ? ???????e? / respectfully, ??????? ?????? -- 1. Macroexpansion is actually defined by the ANSI CL standard to be a part of minimal compbilation, but for the purposes of illustration it makes sense to distinguish between them. From _deepfire at feelingofgreen.ru Tue Oct 6 09:30:12 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Tue, 06 Oct 2015 12:30:12 +0300 Subject: [Haskell-cafe] Reducing the need for CPP In-Reply-To: <87k2r0z8r6.fsf@smart-cactus.org> (sfid-20151006_130812_301207_6B09ABEE) (Ben Gamari's message of "Tue, 06 Oct 2015 10:44:29 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87k2r0z8r6.fsf@smart-cactus.org> Message-ID: <87h9m4l4yj.fsf@feelingofgreen.ru> Ben Gamari writes: > This is a fair point that comes up fairly often. The fact that CPP is > required to silence redundant import warnings is quite unfortunate. > Others languages have better stories in this area. One example is Rust, > which has a quite flexible `#[allow(...)]` pragma which can be used to > acknowledge and silence a wide variety of warnings and lints [1]. > > I can think of a few ways (some better than others) how we might > introduce a similar idea for import redundancy checks in Haskell, > > 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition, ... > 2. Or alternatively we could make this a idea a bit more precise, > {-# ALLOW redundant_import Prelude.(<$>) #-} ... > 3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import, > import {-# ALLOW redundant_import #-} Control.Applicative ... > 4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an > import list, > import Control.Applicative ((<$>) {-# ALLOW redundant_import #-}) What I don't like about this solution is how specific it is -- the gut instinct that it can't be the last such extension, if we were to start replacing CPP piecemeal. And after a while, we'd accomodate a number of such extensions.. and they would keep coming.. until it converges to a trainwreck. I think that what instead needs to be done, is this: 1. a concerted effort to summarize *all* uses of CPP in Haskell code 2. a bit of forward thinking, to include desirables that would be easy to get with a more generic solution Personally, I think that any such effort, approached with generality that would be truly satisfying, should inevitably converge to an AST-level mechanism. ..but then I remember how CPP can be used to paper over incompatible syntax changes.. Hmm.. -- ? ???????e? / respectfully, ??????? ?????? From tkoster at gmail.com Tue Oct 6 10:25:15 2015 From: tkoster at gmail.com (Thomas Koster) Date: Tue, 6 Oct 2015 21:25:15 +1100 Subject: [Haskell-cafe] A GC'd heap using weak pointers Message-ID: Good afternoon list, I am implementing a simple, interpreted language that needs a garbage- collected heap for storage. Like most discussions on memory management, I use the term "heap" by analogy - the actual data structure is not necessarily a true heap. My Heap type is basically a map of "addresses" (Int) to values. Values may themselves contain addresses, perhaps recursively to each other (like letrec). The extra field in Heap stores the next unused address, used to allocate fresh slots, as you can see in "heapAlloc". > type Address = Int > data Value = ...things with Addresses... > data Heap = Heap !Address (Map Address Value) > > heapAlloc :: Heap -> (Address, Heap) > heapAlloc (Heap nextFreeAddr binds) = > (nextFreeAddr, Heap (succ nextFreeAddr) binds) There is also a stack of roots and an expression under evaluation. > type Stack = [...things with Addresses...] > data Expr = ...things with Addresses... The function I need to write is: > heapGC :: [Address] -> Heap -> Heap > heapGC roots heap = ...collect unreachable values from heap... Rather than re-invent this particularly complex wheel, I am wondering if I could use GHC weak pointers and have the GHC runtime collect values in my heap for me. Something like this: > type Address = Int > data Reference = Reference Address > data Value = ...things with References... > data Heap = Heap !Address (Map Address (Weak Value)) > > heapAlloc :: Heap -> (Reference, Heap) > heapAlloc (Heap nextFreeAddr binds) = > (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds) > > heapStore :: Reference -> Value -> Heap -> IO Heap > heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do > weakVal <- mkWeak ref val Nothing > return $ Heap nextFreeAddr (Map.insert addr weakVal binds) Note the new type, Reference. This replaces Address everywhere except in the heap's internal structure, which continues to use Address. Reference values are opaque, unique and obtained from the heap using heapAlloc. The idea is that only two things should cause Values to stay alive: 1. reachable holders of Reference (by GHC's definition of "reachable"), 2. ordinary Haskell closures arising from stepping the interpreter. "Being in the Heap" should not be enough to keep a Value alive. Then, my heapGC function should only have to prune dead addresses from the map. I am having trouble getting a proof-of-concept working (I am unable to observe any finalizers running, ever), but before I get into that, is this idea sound? Has somebody else implemented this in a library already? Thanks, Thomas Koster From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Oct 6 10:39:59 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 6 Oct 2015 16:09:59 +0530 Subject: [Haskell-cafe] A GC'd heap using weak pointers In-Reply-To: References: Message-ID: This would be well recieved on ghc-devs mailing list. Adding to cc. On 6 October 2015 at 15:55, Thomas Koster wrote: > Good afternoon list, > > I am implementing a simple, interpreted language that needs a garbage- > collected heap for storage. Like most discussions on memory management, > I use the term "heap" by analogy - the actual data structure is not > necessarily a true heap. > > My Heap type is basically a map of "addresses" (Int) to values. Values > may themselves contain addresses, perhaps recursively to each other > (like letrec). The extra field in Heap stores the next unused address, > used to allocate fresh slots, as you can see in "heapAlloc". > > > type Address = Int > > data Value = ...things with Addresses... > > data Heap = Heap !Address (Map Address Value) > > > > heapAlloc :: Heap -> (Address, Heap) > > heapAlloc (Heap nextFreeAddr binds) = > > (nextFreeAddr, Heap (succ nextFreeAddr) binds) > > There is also a stack of roots and an expression under evaluation. > > > type Stack = [...things with Addresses...] > > data Expr = ...things with Addresses... > > The function I need to write is: > > > heapGC :: [Address] -> Heap -> Heap > > heapGC roots heap = ...collect unreachable values from heap... > > Rather than re-invent this particularly complex wheel, I am wondering > if I could use GHC weak pointers and have the GHC runtime collect values > in my heap for me. Something like this: > > > type Address = Int > > data Reference = Reference Address > > data Value = ...things with References... > > data Heap = Heap !Address (Map Address (Weak Value)) > > > > heapAlloc :: Heap -> (Reference, Heap) > > heapAlloc (Heap nextFreeAddr binds) = > > (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds) > > > > heapStore :: Reference -> Value -> Heap -> IO Heap > > heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do > > weakVal <- mkWeak ref val Nothing > > return $ Heap nextFreeAddr (Map.insert addr weakVal binds) > > Note the new type, Reference. This replaces Address everywhere except > in the heap's internal structure, which continues to use Address. > Reference values are opaque, unique and obtained from the heap using > heapAlloc. > > The idea is that only two things should cause Values to stay alive: > 1. reachable holders of Reference (by GHC's definition of "reachable"), > 2. ordinary Haskell closures arising from stepping the interpreter. > "Being in the Heap" should not be enough to keep a Value alive. Then, > my heapGC function should only have to prune dead addresses from the > map. > > I am having trouble getting a proof-of-concept working (I am unable to > observe any finalizers running, ever), but before I get into that, is > this idea sound? Has somebody else implemented this in a library > already? > > Thanks, > Thomas Koster > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From Henrik.Nilsson at nottingham.ac.uk Tue Oct 6 11:32:31 2015 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Tue, 06 Oct 2015 12:32:31 +0100 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <5613B14F.9070107@nottingham.ac.uk> Dear all, Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee While we can discuss the extent of additional breakage MRP would cause, the fact remains it is a further breaking change. A survey of breakage to books as Herbert did is certainly valuable (thanks!), but much breakage will (effectively) remain unquantifiable. It is also clear from the discussions over the last couple of weeks, on the Haskell libraries list as well as various other forums and social media, that MRP is highly contentions. This begs two questions: 1. Is the Haskell Libraries list and informal voting process really an appropriate, or even acceptable, way to adopt such far-reaching changes to what effectively amounts to Haskell itself? 2. Why the hurry to push MRP through? As to question 1, to Graham Hutton's and my knowledge, the libraries list and its voting process was originally set up for 3rd-party libraries in fptools. It seems to have experienced some form of "mission creep" since. Maybe that is understandable given that there was no obvious alternative as HaskellPrime has been defunct for a fair few years. But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal) and also have very little time for engaging in long and complicated e-mail discussions that, from their perspective, happen at a completely random point in time and for which they thus have not had a chance to set aside time even if they wanted to participate. Just as one data point, AMP etc. mostly passed Graham and me by simply because a) we were too busy to notice and b) we simply didn't think there was a mandate for such massive overhauls outside of a process like HaskellPrime. And we are demonstrably not alone. This brings us to question 2. Now that HaskellPrime is being resurrected, why the hurry to push MRP through? Surely HaskellPrime is the forum where breaking changes like MRP should be discussed, allowing as much time as is necessary and allowing for an as wide range of perspectives as possible to properly be taken into account? The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers. If MRP is pushed through now, with a resurrection of HaskellPrime being imminent, Graham and I strongly believe that risks coming across to a very large part of the Haskell community as preempting proper process by facing the new HaskellPrime committee with (yet another) fait accompli. Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks. Best regards, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From Lennart.Augustsson at sc.com Tue Oct 6 11:57:23 2015 From: Lennart.Augustsson at sc.com (Augustsson, Lennart) Date: Tue, 6 Oct 2015 11:57:23 +0000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5613B14F.9070107@nottingham.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5613B14F.9070107@nottingham.ac.uk> Message-ID: <22B950C955F8AB4196E72698FBD00002D0290B59@UKWPISXMB01D.zone1.scb.net> To question 1 my answer is NO! I think voting to decide these kind of issues a terrible idea; we might as well throw dice. -----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Henrik Nilsson Sent: 06 October 2015 12:33 To: haskell-prime at haskell.org List; Haskell Libraries; haskell cafe Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` Dear all, Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee While we can discuss the extent of additional breakage MRP would cause, the fact remains it is a further breaking change. A survey of breakage to books as Herbert did is certainly valuable (thanks!), but much breakage will (effectively) remain unquantifiable. It is also clear from the discussions over the last couple of weeks, on the Haskell libraries list as well as various other forums and social media, that MRP is highly contentions. This begs two questions: 1. Is the Haskell Libraries list and informal voting process really an appropriate, or even acceptable, way to adopt such far-reaching changes to what effectively amounts to Haskell itself? 2. Why the hurry to push MRP through? As to question 1, to Graham Hutton's and my knowledge, the libraries list and its voting process was originally set up for 3rd-party libraries in fptools. It seems to have experienced some form of "mission creep" since. Maybe that is understandable given that there was no obvious alternative as HaskellPrime has been defunct for a fair few years. But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal) and also have very little time for engaging in long and complicated e-mail discussions that, from their perspective, happen at a completely random point in time and for which they thus have not had a chance to set aside time even if they wanted to participate. Just as one data point, AMP etc. mostly passed Graham and me by simply because a) we were too busy to notice and b) we simply didn't think there was a mandate for such massive overhauls outside of a process like HaskellPrime. And we are demonstrably not alone. This brings us to question 2. Now that HaskellPrime is being resurrected, why the hurry to push MRP through? Surely HaskellPrime is the forum where breaking changes like MRP should be discussed, allowing as much time as is necessary and allowing for an as wide range of perspectives as possible to properly be taken into account? The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers. If MRP is pushed through now, with a resurrection of HaskellPrime being imminent, Graham and I strongly believe that risks coming across to a very large part of the Haskell community as preempting proper process by facing the new HaskellPrime committee with (yet another) fait accompli. Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks. Best regards, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same. Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products. From hesselink at gmail.com Tue Oct 6 12:06:11 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 6 Oct 2015 14:06:11 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5613B14F.9070107@nottingham.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5613B14F.9070107@nottingham.ac.uk> Message-ID: I was always under the impression that +1/-1 was just a quick indicator of opinion, not a vote, and that it was the core libraries committee that would make the final call if enough consensus was reached to enact the change. Erik On 6 October 2015 at 13:32, Henrik Nilsson wrote: > Dear all, > > Executive Summary: Please let us defer further discussion > and ultimate decision on MRP to the resurrected HaskellPrime > committee > > While we can discuss the extent of additional breakage > MRP would cause, the fact remains it is a further > breaking change. A survey of breakage to books as > Herbert did is certainly valuable (thanks!), but > much breakage will (effectively) remain unquantifiable. > > It is also clear from the discussions over the last > couple of weeks, on the Haskell libraries list as well > as various other forums and social media, that MRP is > highly contentions. > > This begs two questions: > > 1. Is the Haskell Libraries list and informal voting process > really an appropriate, or even acceptable, way to adopt > such far-reaching changes to what effectively amounts to > Haskell itself? > > 2. Why the hurry to push MRP through? > > As to question 1, to Graham Hutton's and my knowledge, > the libraries list and its voting process was originally > set up for 3rd-party libraries in fptools. It seems to > have experienced some form of "mission creep" since. > Maybe that is understandable given that there was no > obvious alternative as HaskellPrime has been defunct > for a fair few years. But, as has been pointed out in a > number of postings, a lot of people with very valuable > perspectives are also very busy, and thus likely to > miss a short discussion period (as has happened in the > past in relation to the Burning the Bridges proposal) > and also have very little time for engaging in long and > complicated e-mail discussions that, from their > perspective, happen at a completely random point in > time and for which they thus have not had a chance to > set aside time even if they wanted to participate. > > Just as one data point, AMP etc. mostly passed Graham > and me by simply because a) we were too busy to notice > and b) we simply didn't think there was a mandate for > such massive overhauls outside of a process like > HaskellPrime. And we are demonstrably not alone. > > This brings us to question 2. Now that HaskellPrime is > being resurrected, why the hurry to push MRP through? > Surely HaskellPrime is the forum where breaking > changes like MRP should be discussed, allowing as much > time as is necessary and allowing for an as wide range > of perspectives as possible to properly be taken into > account? > > The need to "field test" MRP prior to discussing > it in HaskellPrime has been mentioned. Graham and I > are very sceptical. In the past, at least in the > past leading up to Haskell 2010 or so, the community > at large was not roped in as involuntary field testers. > > If MRP is pushed through now, with a resurrection of > HaskellPrime being imminent, Graham and I strongly believe > that risks coming across to a very large part of the > Haskell community as preempting proper process by facing > the new HaskellPrime committee with (yet another) fait > accompli. > > Therefore, please let us defer further discussion and > ultimate decision on MRP to the resurrected > HaskellPrime committee, which is where it properly > belongs. Otherwise, the Haskell community itself might > be one of the things that MRP breaks. > > Best regards, > > /Henrik > > -- > Henrik Nilsson > School of Computer Science > The University of Nottingham > nhn at cs.nott.ac.uk > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From jmaessen at alum.mit.edu Tue Oct 6 12:25:34 2015 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Tue, 6 Oct 2015 08:25:34 -0400 Subject: [Haskell-cafe] Reducing the need for CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <87k2r0z8r6.fsf@smart-cactus.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87k2r0z8r6.fsf@smart-cactus.org> Message-ID: On Tue, Oct 6, 2015 at 4:44 AM, Ben Gamari wrote: > Sven Panne writes: > > > 2015-10-05 17:09 GMT+02:00 Gershom B : > > > >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com > ) > >> wrote: > >> [...] As for libraries, it has been pointed out, I believe, that without > >> CPP one can write instances compatible with AMP, and also with AMP + > MRP. > >> One can also write code, sans CPP, compatible with pre- and post- AMP. > [...] > >> > > > > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which > is > > now part of the Prelude, you can't simply import some compatibility > module, > > because GHC might tell you (rightfully) that that import is redundant, > > because (<$>) is already visible through the Prelude. So you'll have to > use > > CPP to avoid that import on base >= 4.8, be it from it Data.Functor, > > Control.Applicative or some compat-* module. And you'll have to use CPP > in > > each and every module using <$> then, unless I miss something obvious. > > AFAICT all transitioning guides ignore -Wall and friends... > > > This is a fair point that comes up fairly often. The fact that CPP is > required to silence redundant import warnings is quite unfortunate. > Others languages have better stories in this area. One example is Rust, > which has a quite flexible `#[allow(...)]` pragma which can be used to > acknowledge and silence a wide variety of warnings and lints [1]. > > I can think of a few ways (some better than others) how we might > introduce a similar idea for import redundancy checks in Haskell, > > 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition, > > -- in Control.Applicative > {-# ALLOW redundant_import (<$>) #-} > (<$>) :: (a -> b) -> f a -> f b > (<$>) = fmap > > asking the compiler to pretend that any import of the symbol did not > exist when looking for redundant imports. This would allow library > authors to appropriately mark definitions when they are moved, > saving downstream users from having to make any change whatsoever. > > 2. Or alternatively we could make this a idea a bit more precise, > > -- in Control.Applicative > {-# ALLOW redundant_import Prelude.(<$>) #-} > (<$>) :: (a -> b) -> f a -> f b > (<$>) = fmap > > Which would ignore imports of `Control.Applicative.(<$>)` only if > `Prelude.(<$>)` were also in scope. > One obvious solution I haven't seen mentioned is the ability to add nonexistent identifier to a hiding clause (these identifiers might presumably exist in some other version of the import): import Prelude hiding ((<$>)) I can see the argument for marking such imports with a pragma, though it gets a bit ugly. -Jan-Willem Maessen -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Tue Oct 6 13:00:41 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 15:00:41 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: (Erik Hesselink's message of "Tue, 6 Oct 2015 14:06:11 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5613B14F.9070107@nottingham.ac.uk> Message-ID: <87si5o6tja.fsf@gnu.org> On 2015-10-06 at 14:06:11 +0200, Erik Hesselink wrote: > I was always under the impression that +1/-1 was just a quick > indicator of opinion, not a vote, and that it was the core libraries > committee that would make the final call if enough consensus was > reached to enact the change. I'd like to point out, that the core libraries committee ought to continue to do so (as hinted at in [1]) in its function as a Haskell Prime sub-Committee (c.f. sub-teams in the Rust community[2]). While there will be surely overlap of interests, contributions, cross-reviewing and discussion, the principal task and responsibility of the new sought members is to concentrate on the language part of the Haskell Report where quite a bit of work is awaiting them. Cheers, hvr [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html [2]: https://www.rust-lang.org/team.html From Graham.Hutton at nottingham.ac.uk Tue Oct 6 15:07:52 2015 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Tue, 6 Oct 2015 15:07:52 +0000 Subject: [Haskell-cafe] Journal of Functional Programming - Call for PhD Abstracts Message-ID: If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, deadline 31st October 2015. Many thanks, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st October 2015 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton by 31st October 2015. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 1000 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting in the abstract, but do get in touch if this causes significant problems) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From spam at scientician.net Tue Oct 6 16:16:52 2015 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 6 Oct 2015 18:16:52 +0200 Subject: [Haskell-cafe] Reducing the need for CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87k2r0z8r6.fsf@smart-cactus.org> Message-ID: On 10/06/2015 11:11 AM, Johan Tibell wrote: > It might be enough to just add a NOWARN pragma that acts on > a single line/expression. I've seen it in both C++ and Python linters and > it works reasonably well and it's quite general. +1. Simple is good and can hopefully also be backported to older GHC releases. (Provided someone's willing to do said releases, obviously.) From hvr at gnu.org Tue Oct 6 16:47:08 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 18:47:08 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: (Johan Tibell's message of "Tue, 6 Oct 2015 10:10:01 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: <87612k6j1v.fsf@gnu.org> On 2015-10-06 at 10:10:01 +0200, Johan Tibell wrote: [...] >> You say that you stick to the 3-major-ghc-release support-window >> convention for your libraries. This is good, because then you don't need >> any CPP at all! Here's why: >> >> [...] >> > > So what do I have to write today to have my Monad instances be: > > * Warning free - Warnings are useful. Turning them off or having spurious > warnings both contribute to bugs. Depends on the warnings. Some warnings are more of an advisory kind (hlint-ish). I wouldn't consider redundant imports a source of bugs. Leaving off a top-level signature shouldn't be a source of correctness bugs either. Also, warnings about upcoming changes (i.e. deprecation warnings) also are not necessarily a bug, but rather a way to raise awareness of API changes. At the other end of the spectrum are more serious warnings I'd almost consider errors, such as failing to define a non-defaulting method or violating a MINIMAL pragma specification, as that can lead to bottoms either in the form of runtime errors or even worse, hanging computations (in case of cyclic definitions). IMO, GHC should classify its warnings into severities/categories or introduce some compromise between -Wall and not-Wall. > * Use imports that either are qualified or have explicit import lists - > Unqualified imports makes code more likely to break when dependencies add > exports. > * Don't use CPP. That being said, as how to write your Monad instances today with GHC 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This *does* work (admittedly for an easy example, but this can be generalised): --8<---------------cut here---------------start------------->8--- module MyMaybe where import Control.Applicative (Applicative(..)) import Prelude (Functor(..), Monad(..), (.)) -- or alternatively: `import qualified Prelude as P` data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance Applicative Maybe' where pure = Just' f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1) instance Monad Maybe' where Nothing' >>= _ = Nothing' Just' x >>= f = f x return = pure -- "deprecated" since GHC 7.10 --8<---------------cut here---------------end--------------->8--- This example above compiles -Wall-clean and satisfies all your 3 stated requirements afaics. I do admit this probably not what you had in mind. But to be consistent, if you want to avoid unqualified imports at all costs in order to have full control of what gets imported into your namespace, you shouldn't tolerate an implicit unqualified wildcard `Prelude` import either. As `Prelude` can, even if seldom, gain new exports as well (or even loose them -- `interact` *could* be a candidate for removal at some point). > Neither AMP or MRP includes a recipe for this in their proposal. That's because -Wall-hygiene (w/o opting out of harmless) warnings across multiple GHC versions is not considered a show-stopper. In the specific case of MRP, I can offer you a Wall-perfect transition scheme by either using `ghc-options: -fno-mrp-warnings` in your cabal-file, or if that doesn't satisfy you, we can delay phase1 (i.e. redundant return-def warnings) to GHC 8.2: Now you can continue to write `return = pure` w/o GHC warning bothering you until GHC 8.2, at which point the 3-year-window will reach to GHC 7.10. Then starting with GHC 8.2 you can drop the `return` definition, and keep your More generally though, we need more language-features and/or modifications to the way GHC triggers warnings to make such refactorings/changes to the libraries -Wall-perfect as well. Beyond what Ben already suggested in another post, there was also the more general suggestion to implicitly suppress warnings when you explicitly name an import. E.g. import Control.Applicative (Applicative(..)) would suppress the redundant-import warning for Applicative via Prelude, because we specifically requested Applicative, so we don't mind that Prelude re-exports the same symbol. > AMP got one post-facto on the Wiki. It turns out that the workaround > there didn't work (we tried it in Cabal and it conflicted with one of > the above requirements.) Yes, that unqualified `import Prelude`-last trick mentioned on the Wiki breaks down for more complex imports with (redundant) explicit import lists. However, the Maybe-example above works at the cost of a wordy Prelude-import, but it's more robust, as you pin down exactly which symbol you expect to get from each module. > The problem by discussions is that they are done between two groups with > quite a difference in experience. On one hand you have people like Bryan, > who have considerable contributions to the Haskell ecosystem and much > experience in large scale software development (e.g. from Facebook). On the > other hand you have people who don't. That's okay. We've all been at the > latter group at some point of our career. [...] At the risk of stating the obvious: I don't think it matters from which group a given argument comes from as its validity doesn't depend on the messenger. Neither does it matter whether an argument is repeated several times or stated only once. Also, every argument deserves to be considered regardless of its origin or frequency. -- hvr From hvr at gnu.org Tue Oct 6 17:26:06 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 19:26:06 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87612k6j1v.fsf@gnu.org> (Herbert Valerio Riedel's message of "Tue, 06 Oct 2015 18:47:08 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: <87oagb6h8x.fsf@gnu.org> I hit "send" too early, so here's the incomplete section completed: On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote: [...] > In the specific case of MRP, I can offer you a Wall-perfect transition > scheme by either using `ghc-options: -fno-mrp-warnings` in your > cabal-file, or if that doesn't satisfy you, we can delay phase1 > (i.e. redundant return-def warnings) to GHC 8.2: > > Now you can continue to write `return = pure` w/o GHC warning bothering > you until GHC 8.2, at which point the 3-year-window will reach to GHC > 7.10. > > Then starting with GHC 8.2 you can drop the `return` definition, and ...keep supporting a 3-year-window back till GHC 7.10 (which incorporates AMP and doesn't need `return` explicitly defined anymore) without CPP. And since you don't define `return` anymore, you don't get hit by the MRP warning either, which would start with GHC 8.2. GHC can keep providing as long as we want it to, and consider `return` being an extra method of `Monad` simply a GHC-ism. Future Haskell books and learning materials will hopefully be based on the next Haskell Report incorporating the AMP and stop referring to the historical `return` accident (which I consider badly named anyway from a pedagogically perspective). Code written unaware of `return` being a method of Monad will work anyway just fine. Do you see any problems with this scheme? From svenpanne at gmail.com Tue Oct 6 17:41:51 2015 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 6 Oct 2015 19:41:51 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87612k6j1v.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel : > [...] That being said, as how to write your Monad instances today with GHC > 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This > *does* work (admittedly for an easy example, but this can be > generalised): > > > --8<---------------cut here---------------start------------->8--- > module MyMaybe where > > import Control.Applicative (Applicative(..)) > import Prelude (Functor(..), Monad(..), (.)) > -- or alternatively: `import qualified Prelude as P` > [...] > --8<---------------cut here---------------end--------------->8--- > > This example above compiles -Wall-clean and satisfies all your 3 stated > requirements afaics. I do admit this probably not what you had in mind. > OK, so the trick is that you're effectively hiding Applicative from the Prelude (which might be a no-op). This "works" somehow, but is not satisfactory IMHO for several reasons: * If you explicitly import all entities from Prelude, your import list will typically get *very* long and unreadable. Furthermore, if that's the suggested technique, what's the point of having a Prelude at all? * Some people see qualified imports as the holy grail, but having to prefix tons of things with "P." is IMHO very ugly. Things are even worse for operators: The whole notion of operators in itself is totally useless and superfluous *except* for a single reason: Readability. And exactly that gets destroyed when you have to qualify them, so I would (sadly) prefer some #ifdef hell, if that gives me readable code elsewhere. * With the current trend of moving things to the Prelude, I can envision a not-so-distant future where the whole Control.Applicative module will be deprecated. As it is now, it's mostly superfluous and/or contains only stuff which might better live somewhere else. > [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings > across multiple GHC versions is not considered a show-stopper. > That's your personal POV, I'm more leaning towards "-Wall -Werror". I've seen too many projects where neglecting warning over an extended period of time made fixing them basically impossible at the end. Anyway, I think that a sane ecosystem should allow *both* POVs, the sloppy one and the strict one. > [...] Beyond what Ben already suggested in another post, there was also the > more general suggestion to implicitly suppress warnings when you > explicitly name an import. E.g. > > import Control.Applicative (Applicative(..)) > > would suppress the redundant-import warning for Applicative via Prelude, > because we specifically requested Applicative, so we don't mind that > Prelude re-exports the same symbol. [...] > Uh, oh... That would be bad, because one normally wants to see redundant imports. Without the compiler telling me, how should I find out which are redundant? Manually trying to remove them step by step? :-/ Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Oct 6 18:12:46 2015 From: david.feuer at gmail.com (David Feuer) Date: Tue, 6 Oct 2015 14:12:46 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5613B14F.9070107@nottingham.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5613B14F.9070107@nottingham.ac.uk> Message-ID: On Oct 6, 2015 7:32 AM, "Henrik Nilsson" wrote: > Executive Summary: Please let us defer further discussion > and ultimate decision on MRP to the resurrected HaskellPrime > committee Many more people are on this mailing list than will be chosen for the committee. Those who are not chosen have useful perspectives as well. > 1. Is the Haskell Libraries list and informal voting process > really an appropriate, or even acceptable, way to adopt > such far-reaching changes to what effectively amounts to > Haskell itself? As others have said, no one wants that. > But, as has been pointed out in a > number of postings, a lot of people with very valuable > perspectives are also very busy, and thus likely to > miss a short discussion period (as has happened in the > past in relation to the Burning the Bridges proposal) The Foldable/Traversable BBP indeed was not as well discussed as it should have been. AMP, on the other hand, was discussed extensively and publicly for months. I understand that some people need months of notice to prepare to participate in a discussion. Unfortunately, I don't think those people can always be included. Life moves too quickly for that. I do think it might be valuable to set up a moderated, extremely low volume mailing list for discussion of only the most important changes, with its messages forwarded to the general list. > The need to "field test" MRP prior to discussing > it in HaskellPrime has been mentioned. Graham and I > are very sceptical. In the past, at least in the > past leading up to Haskell 2010 or so, the community > at large was not roped in as involuntary field testers. No, and Haskell 2010 was, by most measures, a failure. It introduced no new language features (as far as I can recall) and only a few of the most conservative library changes imaginable. Standard Haskell has stagnated since 1998, 17 years ago. Haskell 2010 did not reflect the Haskell people used in their research our practical work then, and I think people are justified in their concern that the next standard may be similarly disappointing. One of the major problems is the (understandable, and in many ways productive) concentration of development effort in a single compiler. When there is only one modern Haskell implementation that is commonly used, it's hard to know how changes to the standard will affect other important implementation techniques, and therefore hard to justify any substantial changes. That was true in 2010, and it is, if anything, more true now. > Therefore, please let us defer further discussion and > ultimate decision on MRP to the resurrected > HaskellPrime committee, which is where it properly > belongs. Otherwise, the Haskell community itself might > be one of the things that MRP breaks. I hope not. Haskell has gained an awful lot from the researchers, teachers, and developers who create it and use it. I hope we can work out an appropriate balance of inclusion, caution, and speed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Tue Oct 6 19:02:12 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Tue, 06 Oct 2015 20:02:12 +0100 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87612k6j1v.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote: > >> The problem by discussions is that they are done between two groups with >> quite a difference in experience. On one hand you have people like Bryan, >> who have considerable contributions to the Haskell ecosystem and much >> experience in large scale software development (e.g. from Facebook). On the >> other hand you have people who don't. That's okay. We've all been at the >> latter group at some point of our career. > [...] > > At the risk of stating the obvious: I don't think it matters from which > group a given argument comes from as its validity doesn't depend on the > messenger. In that case, I think you are misunderstanding the relevance of Johan's argument here. Let me try to phrase it differently. Some people who can reasonably claim to have experience with million-line plus codebases are warning that this change is too disruptive, and makes maintenance harder than it ought to be. On the other hand, of the people who say the change is not really disruptive, none of them have (yet?) made claims to have experience of the maintenance of extremely large-scale codebases. The authority of the speaker does matter in technical arguments of this nature: people without the relevant experience are simply unqualified to make guesses about the impact. Regards, Malcolm From hvr at gnu.org Tue Oct 6 17:03:44 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 19:03:44 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87612k6j1v.fsf@gnu.org> (Herbert Valerio Riedel's message of "Tue, 06 Oct 2015 18:47:08 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: <871td86ia7.fsf@gnu.org> I hit "send" too early, so here's the incomplete section completed: On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote: [...] > In the specific case of MRP, I can offer you a Wall-perfect transition > scheme by either using `ghc-options: -fno-mrp-warnings` in your > cabal-file, or if that doesn't satisfy you, we can delay phase1 > (i.e. redundant return-def warnings) to GHC 8.2: > > Now you can continue to write `return = pure` w/o GHC warning bothering > you until GHC 8.2, at which point the 3-year-window will reach to GHC > 7.10. > > Then starting with GHC 8.2 you can drop the `return` definition, and ...keep supporting a 3-year-window back till GHC 7.10 (which incorporates AMP and doesn't need `return` explicitly defined anymore) without CPP. And since you don't define `return` anymore, you don't get hit by the MRP warning either, which would start with GHC 8.2. GHC can keep providing as long as we want it to, and consider `return` being an extra method of `Monad` simply a GHC-ism. Future Haskell books and learning materials will hopefully be based on the next Haskell Report incorporating the AMP and stop referring to the historical `return` accident (which I consider badly named anyway from a pedagogically perspective). Code written unaware of `return` being a method of Monad will work anyway just fine. Do you see any problems with this scheme? From adam at bergmark.nl Tue Oct 6 19:16:22 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 6 Oct 2015 21:16:22 +0200 Subject: [Haskell-cafe] Reducing the need for CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87k2r0z8r6.fsf@smart-cactus.org> Message-ID: On Tue, Oct 6, 2015 at 6:16 PM, Bardur Arantsson wrote: > On 10/06/2015 11:11 AM, Johan Tibell wrote: > > It might be enough to just add a NOWARN pragma that acts > on > > a single line/expression. I've seen it in both C++ and Python linters and > > it works reasonably well and it's quite general. > > +1. Simple is good and can hopefully also be backported to older GHC > releases. (Provided someone's willing to do said releases, obviously.) > I've thought of this in the past and it would be great to have. Another possible use case is to allow this for extensions as well, e.g. "Only allow UndecidableInstances for this declaration" > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Tue Oct 6 19:32:19 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 6 Oct 2015 21:32:19 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <871td86ia7.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <871td86ia7.fsf@gnu.org> Message-ID: Hi, On 6 October 2015 at 19:03, Herbert Valerio Riedel wrote: >> In the specific case of MRP, I can offer you a Wall-perfect transition >> scheme by either using `ghc-options: -fno-mrp-warnings` in your >> cabal-file, [...] Apropos, is there a similar option for AMP warnings? I would rather use that than CPP. From cma at bitemyapp.com Tue Oct 6 20:16:40 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 6 Oct 2015 15:16:40 -0500 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: Do those participating in this thread think sentiments like this are constructive or inclusive? Is this how we encourage participation from newer members of the community? Framing this debate in terms of a programming pecking order is unprofessional. Many times, those higher in the ranks will prefer a more conservative approach, as experienced surgeons once resisted the introduction of the autoclave. The problem isn't the change; it's what the change costs you. Provide data and make your case. Talk about what it _costs_ you, show evidence for that cost, and describe what would make the change acceptable. Do it without talking down to a constructed "other" of the people who've neglected to make the same status display you've injected into this conversation. That could be valuable input to the discussion, so we would could weigh costs and benefits as a community. There _are_ costs associated with going ahead with MRP, especially for those with large 1mm LOC industrial codebases. This is partly why I'm lukewarm on the change, but I believe it needs to happen sooner or later and waiting for more 1mm LOC codebases to be born isn't going to make it any better. The suggestions that we consider the example of 2to3 I believe have been more constructive, particularly since we have this lovely language which lends itself so nicely to static analysis anyway. On Tue, Oct 6, 2015 at 2:02 PM, Malcolm Wallace wrote: > > On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote: > > > > >> The problem by discussions is that they are done between two groups with > >> quite a difference in experience. On one hand you have people like > Bryan, > >> who have considerable contributions to the Haskell ecosystem and much > >> experience in large scale software development (e.g. from Facebook). On > the > >> other hand you have people who don't. That's okay. We've all been at the > >> latter group at some point of our career. > > [...] > > > > At the risk of stating the obvious: I don't think it matters from which > > group a given argument comes from as its validity doesn't depend on the > > messenger. > > In that case, I think you are misunderstanding the relevance of Johan's > argument here. Let me try to phrase it differently. Some people who can > reasonably claim to have experience with million-line plus codebases are > warning that this change is too disruptive, and makes maintenance harder > than it ought to be. On the other hand, of the people who say the change > is not really disruptive, none of them have (yet?) made claims to have > experience of the maintenance of extremely large-scale codebases. The > authority of the speaker does matter in technical arguments of this nature: > people without the relevant experience are simply unqualified to make > guesses about the impact. > > Regards, > Malcolm > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Tue Oct 6 20:16:22 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 22:16:22 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: (Mikhail Glushenkov's message of "Tue, 6 Oct 2015 21:32:19 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <871td86ia7.fsf@gnu.org> Message-ID: <87d1wrycq1.fsf@gnu.org> Hi, On 2015-10-06 at 21:32:19 +0200, Mikhail Glushenkov wrote: > On 6 October 2015 at 19:03, Herbert Valerio Riedel wrote: >>> In the specific case of MRP, I can offer you a Wall-perfect transition >>> scheme by either using `ghc-options: -fno-mrp-warnings` in your >>> cabal-file, [...] > > Apropos, is there a similar option for AMP warnings? I would rather > use that than CPP. Sure, added in GHC 7.8: | In GHC 7.10, Applicative will become a superclass of Monad, | potentially breaking a lot of user code. To ease this transition, GHC | now generates warnings when definitions conflict with the | Applicative-Monad Proposal (AMP). | | A warning is emitted if a type is an instance of Monad but not of | Applicative, MonadPlus but not Alternative, and when a local function | named join, <*> or pure is defined. | | The warnings are enabled by default, and can be controlled using the | new flag -f[no-]warn-amp. However, if you use that now with GHC 7.10 you get a warning: | $ ghc-7.10.2 -fno-warn-amp | | on the commandline: Warning: | -fno-warn-amp is deprecated: it has no effect, and will be removed in GHC 7.12 so you you'll need to guard that with something like if impl(ghc == 7.8.*) ghc-options: -fno-warn-amp From r.wobben at home.nl Tue Oct 6 20:24:03 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 6 Oct 2015 22:24:03 +0200 Subject: [Haskell-cafe] quickCheck problem Message-ID: <56142DE3.30604@home.nl> Hello, I have written a function to test if three numbers are the same. Now I want to test my functions by using quickCheck. So I thought to test first if all three are the same. but how can I tell quickcheck that all numbers are the same. and second question : hwo do the test likeif two numbers are the same. I ask this because I try to solve a exercise of the programming Haskell book, IM have read chapter 3 now. Roelof From creswick at gmail.com Tue Oct 6 20:31:27 2015 From: creswick at gmail.com (Rogan Creswick) Date: Tue, 6 Oct 2015 13:31:27 -0700 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: <56142DE3.30604@home.nl> References: <56142DE3.30604@home.nl> Message-ID: On Tue, Oct 6, 2015 at 1:24 PM, Roelof Wobben wrote: > Hello, > > I have written a function to test if three numbers are the same. > > Now I want to test my functions by using quickCheck. > > So I thought to test first if all three are the same. > > but how can I tell quickcheck that all numbers are the same. Just have quickcheck generate one number, and use it for all three arguments, eg: prop_allSame :: Int -> Bool prop_allSame x = yourFn x x x then test the other cases: prop_different :: Int -> Int -> Int -> Property prop_different x y z = x /= y && y /= z && x /= z ==> not $ yourFn x y z That's probably OK for ints, but generally the guard in that style isn't a great solution, since quickcheck will just keep generating inputs until the predicate is satisfied. That can take a while, so you could also manually offset the first input in various ways: prop_different :: Int -> Int -> Bool prop_different x y = not $ yourFn x (x + y) (x - (y + 1)) -- I put a +1 in here to avoid returning true where y = 0, There are probably other ways to mutate a randomly generated input for your problem that may work better, but that's the general idea. --Rogan > > and second question : hwo do the test likeif two numbers are the same. > > I ask this because I try to solve a exercise of the programming Haskell > book, > IM have read chapter 3 now. > > Roelof > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Oct 6 20:36:41 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 6 Oct 2015 21:36:41 +0100 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> Message-ID: <20151006203641.GS11050@weber> On Mon, Oct 05, 2015 at 05:40:43PM -0700, Gregory Collins wrote: > - defaultTimeLocale moved from System.Locale to Data.Time.Format in > time-1.5 (no compat package for this, afaik) http://hackage.haskell.org/package/time-compat From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Oct 6 20:39:01 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 6 Oct 2015 21:39:01 +0100 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> Message-ID: <20151006203900.GT11050@weber> On Mon, Oct 05, 2015 at 05:40:43PM -0700, Gregory Collins wrote: > On Mon, Oct 5, 2015 at 3:18 PM, Bryan Richter wrote: > > Hang on a moment, are you saying that all the people writing to argue > > that these changes would require them to write dozens more #ifdef's > > actually don't have to write any at all? > > Um, no, it usually isn't anything like that. Here's a sampling of some of > the things I've used CPP for in the past few years: > > - After GHC 7.4, when using a newtype in FFI imports you need to import > the constructor, i.e. "import Foreign.C.Types(CInt(..))" --- afaik CPP is > the only way to shut up warnings everywhere > - defaultTimeLocale moved from System.Locale to Data.Time.Format in > time-1.5 (no compat package for this, afaik) > - one of many various changes to Typeable in the GHC 7.* series > (deriving works better now, mkTyCon vs mkTyCon3, etc) > - Do I have to hide "catch" from Prelude, or not? It got moved, and > "hiding" gives an error if the symbol you're trying to hide is missing. > Time to break out the CPP (and curse myself for not just using the > qualified import in the first place) > - Do I get monoid functions from Prelude or from Data.Monoid? Same w/ > Applicative, Foldable, Word. I don't know where anything is supposed to > live anymore, or which sequence of imports will shut up spurious warnings > on all four versions of GHC I support, so the lowest-friction fix is: break > out the #ifdef spackle > - ==# and friends return Int# instead of Bool after GHC 7.8.1 > - To use functions like "tryReadMVar", "unsafeShiftR", and > "atomicModifyIORef'" that are in recent base versions but not older ones > (this is a place where CPP use is actually justified) In fact I think all of these apart from the FFI one could be solved with a -compat package, could they not? From r.wobben at home.nl Tue Oct 6 21:01:44 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 6 Oct 2015 23:01:44 +0200 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: References: <56142DE3.30604@home.nl> Message-ID: <561436B8.8090804@home.nl> Thanks, but why this part : x (x + y) (x - (y + 1)) Roelof Op 6-10-2015 om 22:31 schreef Rogan Creswick: > On Tue, Oct 6, 2015 at 1:24 PM, Roelof Wobben wrote: >> Hello, >> >> I have written a function to test if three numbers are the same. >> >> Now I want to test my functions by using quickCheck. >> >> So I thought to test first if all three are the same. >> >> but how can I tell quickcheck that all numbers are the same. > Just have quickcheck generate one number, and use it for all three > arguments, eg: > > prop_allSame :: Int -> Bool > prop_allSame x = yourFn x x x > > then test the other cases: > > prop_different :: Int -> Int -> Int -> Property > prop_different x y z = x /= y && y /= z && x /= z ==> not $ yourFn x y z > > That's probably OK for ints, but generally the guard in that style > isn't a great solution, since quickcheck will just keep generating > inputs until the predicate is satisfied. That can take a while, so > you could also manually offset the first input in various ways: > > prop_different :: Int -> Int -> Bool > prop_different x y = not $ yourFn x (x + y) (x - (y + 1)) -- I put a > +1 in here to avoid returning true where y = 0, > > There are probably other ways to mutate a randomly generated input for > your problem that may work better, but that's the general idea. > > --Rogan > >> and second question : hwo do the test likeif two numbers are the same. >> >> I ask this because I try to solve a exercise of the programming Haskell >> book, >> IM have read chapter 3 now. >> >> Roelof >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > ----- > Geen virus gevonden in dit bericht. > Gecontroleerd door AVG - www.avg.com > Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte: 10/06/15 > > From mark.lentczner at gmail.com Tue Oct 6 21:15:10 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 6 Oct 2015 14:15:10 -0700 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel wrote: > TLDR: To complete the AMP, turn `Monad(return)` method into a > top-level binding aliasing `Applicative(pure)`. > Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't. A modest proposal: We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc. Think of it as Perl 6 or Python 3 for Haskell. - Mark On Tue, Oct 6, 2015 at 1:12 AM, Johan Tibell wrote: > (Resending with smaller recipient list to avoid getting stuck in the > moderator queue.) > > On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel > wrote: > >> On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: >> > On the libraries I maintain and have a copy of on my computer right >> now: 329 >> >> >> Although this was already pointed out to you in a response to a Tweet of >> yours, I'd like to expand on this here to clarify: >> >> >> You say that you stick to the 3-major-ghc-release support-window >> convention for your libraries. This is good, because then you don't need >> any CPP at all! Here's why: >> >> [...] >> > > So what do I have to write today to have my Monad instances be: > > * Warning free - Warnings are useful. Turning them off or having spurious > warnings both contribute to bugs. > * Use imports that either are qualified or have explicit import lists - > Unqualified imports makes code more likely to break when dependencies add > exports. > * Don't use CPP. > > Neither AMP or MRP includes a recipe for this in their proposal. AMP got > one post-facto on the Wiki. It turns out that the workaround there didn't > work (we tried it in Cabal and it conflicted with one of the above > requirements.) > > PS: I'm a bit disappointed you seem to dismiss this proposal right away >> categorically without giving us a chance to address your >> concerns. The proposal is not a rigid all-or-nothing thing that >> can't be tweaked and revised. That's why we're having these >> proposal-discussions in the first place (rather than doing blind >> +1/-1 polls), so we can hear everyone out and try to maximise the >> agreement (even if we will never reach 100% consensus on any >> proposal). >> >> So please, keep on discussing! >> > > The problem by discussions is that they are done between two groups with > quite a difference in experience. On one hand you have people like Bryan, > who have considerable contributions to the Haskell ecosystem and much > experience in large scale software development (e.g. from Facebook). On the > other hand you have people who don't. That's okay. We've all been at the > latter group at some point of our career. > > What's frustrating is that people don't take a step bad and realize that > they might be in the latter group and should perhaps listen to those in the > former. This doesn't happen, instead we get lots of "C++ and Java so bad > and we don't want to be like them." Haskell is not at risk of becoming C++ > or Java (which are a large improvement compared to the languages came > before them). We're at risk of missing our window of opportunity. I think > that would be a shame, as I think Haskell is a step forward compared to > those languages and I would like to see more software that used be written > in Haskell. > > We've been through this many times before on the libraries list. I'm not > going to win an argument on this mailing list. Between maintaining > libraries you all use and managing a largish team at Google, I don't have > much time for a discussion which approaches a hundred emails and is won by > virtue of having lots of time to write emails. > > -- Johan > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Tue Oct 6 21:29:53 2015 From: greg at gregorycollins.net (Gregory Collins) Date: Tue, 6 Oct 2015 14:29:53 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <20151006203900.GT11050@weber> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > In fact I think all of these apart from the FFI one could be solved with a > -compat package, could they not? > Who cares? In practice, the programs break and I have to fix them. Most of the time, CPP is the lowest-friction solution -- if I rely on a -compat package, first I have to know it exists and that I should use it to fix my compile error, and then I've added an additional non-platform dependency that I'm going to have to go back and clean up in 18 months. Usually, to be honest, *actually* the procedure is that the new RC comes out and I get github pull requests from hvr@ :-) :-) In response to the other person who asked "why do you want to support so many GHC versions anyways?" --- because I don't hate my users, and don't want to force them to run on the upgrade treadmill if they don't have to? Our policy is to support the last 4 major GHC versions (or 2 years, whichever is shorter). And if we support a version of GHC, I want our libraries to compile on it without warnings, I don't think that should mystify anyone. -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From achudnov at gmail.com Tue Oct 6 21:52:59 2015 From: achudnov at gmail.com (Andrey Chudnov) Date: Tue, 6 Oct 2015 17:52:59 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87zizw8obv.fsf_-_@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: <561442BB.6010404@gmail.com> Herbert, unfortunately your logic would break if there is another invasive library change somewhere between 7.10 and 8.2 as that would require introducing a whole another set of #ifdef's. I've been using GHC since 6.2. Since then new versions of GHC have been breaking builds of foundational packages every 1-2 releases. I'm actually all for decisive and unapologetic language evolution, but there should be a safety net so there's less risk of breakage. And, the main sentiment in the discussion (which, I admit, I have followed very loosely) seems to be that #ifdef's are a poor choice for such a net. So, forgive me if that has been discussed, but what has happened to the `haskell2010` package that is supposed to provide a compatibility layer for the standard library? Are people using it? Why hasn't it been updated since March 2014? Is it really impossible to provide a legacy Haskell2010 base library compatibility layer with AMP in play? Perhaps it's my ignorance speaking, but I really think if packages like `haskell2010` and `haskell98` were actively maintained and used, we wouldn't have issues like that. Then you could say: "if you depend on the GHC `base` package directly, your portability troubles are well deserved". On 10/06/2015 03:10 AM, Herbert Valerio Riedel wrote: > So when GHC 8.2 is released, your support-window requires you to support > GHC 7.10 and GHC 8.0 in addition to GHC 8.2. > > At this point you'll be happy that you can start dropping those #ifdefs > you added for GHC 7.10 in your code in order to adapt to FTP & AMP. From creswick at gmail.com Tue Oct 6 22:28:20 2015 From: creswick at gmail.com (Rogan Creswick) Date: Tue, 6 Oct 2015 15:28:20 -0700 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: <561436B8.8090804@home.nl> References: <56142DE3.30604@home.nl> <561436B8.8090804@home.nl> Message-ID: On Tue, Oct 6, 2015 at 2:01 PM, Roelof Wobben wrote: > but why this part : > > x (x + y) (x - (y + 1)) That is buggy. I was trying to quickly create three arguments that are guaranteed to be different by some random amount, but what I wrote doesn't always work (eg: if y = 0, then the first two arguments are the same, if y is -1, the first and 3rd are the same, if x is MAX_INT, then it may or may not be the same as other arguments, depending on Y, etc...) The predicate guard should work, though it may take longer to run. --Rogan > > > Roelof > > Op 6-10-2015 om 22:31 schreef Rogan Creswick: >> >> On Tue, Oct 6, 2015 at 1:24 PM, Roelof Wobben wrote: >>> >>> Hello, >>> >>> I have written a function to test if three numbers are the same. >>> >>> Now I want to test my functions by using quickCheck. >>> >>> So I thought to test first if all three are the same. >>> >>> but how can I tell quickcheck that all numbers are the same. >> >> Just have quickcheck generate one number, and use it for all three >> arguments, eg: >> >> prop_allSame :: Int -> Bool >> prop_allSame x = yourFn x x x >> >> then test the other cases: >> >> prop_different :: Int -> Int -> Int -> Property >> prop_different x y z = x /= y && y /= z && x /= z ==> not $ yourFn x y z >> >> That's probably OK for ints, but generally the guard in that style >> isn't a great solution, since quickcheck will just keep generating >> inputs until the predicate is satisfied. That can take a while, so >> you could also manually offset the first input in various ways: >> >> prop_different :: Int -> Int -> Bool >> prop_different x y = not $ yourFn x (x + y) (x - (y + 1)) -- I put a >> +1 in here to avoid returning true where y = 0, >> >> There are probably other ways to mutate a randomly generated input for >> your problem that may work better, but that's the general idea. >> >> --Rogan >> >>> and second question : hwo do the test likeif two numbers are the same. >>> >>> I ask this because I try to solve a exercise of the programming Haskell >>> book, >>> IM have read chapter 3 now. >>> >>> Roelof >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> ----- >> Geen virus gevonden in dit bericht. >> Gecontroleerd door AVG - www.avg.com >> Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte: >> 10/06/15 >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From jmct at jmct.cc Tue Oct 6 22:56:47 2015 From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=) Date: Tue, 6 Oct 2015 15:56:47 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: Hello all, I agree with Henrik, I'm very keen on giving the new Haskell committee a shot. While some may not think that Haskell2010 was a success, I think it would be difficult to argue that Haskell98 was anything but a resounding success (even if you don't think the language was what it could have been!). Haskell98 stabilized the constant changes of the proceeding 7 years. The stability brought with it books and courses, and the agreed-upon base of the language allowed _research_ to flourish as well. Having an agreed base allowed the multiple implementations to experiment with different methods of implementing what the standard laid out. Many of us here learned from those texts or those courses. It's easy online to say that materials being out of date isn't a big deal, but it can turn people off the language when the code they paste into ghci doesn't work. We use Haskell for the compilers course at York; Haskell is the means, not the end, so having to update the materials frequently is a significant cost. It can be difficult to defend the choice of using Haskell when so much time is spent on something that 'isn't the point' of the course. Does that mean that we should never change the language? Of course not, but this constant flux within Haskell is very frustrating. Maybe Haskell2010 wasn't what everyone wanted it to be, but that does not mean the _idea_ of a committee is without merit. Having controlled, periodic changes that are grouped together and thought through as a coherent whole is a very useful thing. One of the insights of the original committee was that there would always be one chair at any point in time. The chair of the committee had final say on any issue. This helped keep the revisions coherent and ensured that Haskell made sense as a whole. Lastly, I'd like to quote Prof. Runciman from almost exactly 22 years ago when the issue of incompatible changes came up. His thoughts were similar to Johan's: On 1993-10-19 at 14:12:30 +0100, Colin Runciman wrote: > As a practical suggestion, if any changes for version 1.3 could make > some revision of a 1.2 programs necessary, let's have a precise > stand-alone specification of these revisions and how to make them. > It had better be short and simple. Many would prefer it to be empty. > Perhaps it should be implemented in Haskell compilers? Overall I don't see the rush for these changes, let's try putting our faith in a new Haskell committee, whomever it is comprised of. Best wishes, Jos? Manuel P.S. A year ago Prof. Hinze sent me some Miranda code of his from 1995 as I was studying his thesis. I was able to run the code without issue, allowing me to be more productive in my research ;-) On Tue, Oct 6, 2015 at 2:29 PM, Gregory Collins wrote: > > On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > >> In fact I think all of these apart from the FFI one could be solved with a >> -compat package, could they not? >> > > Who cares? In practice, the programs break and I have to fix them. Most of > the time, CPP is the lowest-friction solution -- if I rely on a -compat > package, first I have to know it exists and that I should use it to fix my > compile error, and then I've added an additional non-platform dependency > that I'm going to have to go back and clean up in 18 months. Usually, to be > honest, *actually* the procedure is that the new RC comes out and I get > github pull requests from hvr@ :-) :-) > > In response to the other person who asked "why do you want to support so > many GHC versions anyways?" --- because I don't hate my users, and don't > want to force them to run on the upgrade treadmill if they don't have to? > Our policy is to support the last 4 major GHC versions (or 2 years, > whichever is shorter). And if we support a version of GHC, I want our > libraries to compile on it without warnings, I don't think that should > mystify anyone. > > -- > Gregory Collins > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Tue Oct 6 23:24:15 2015 From: mwm at mired.org (Mike Meyer) Date: Tue, 06 Oct 2015 23:24:15 +0000 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner wrote: > > On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel > wrote: > >> TLDR: To complete the AMP, turn `Monad(return)` method into a >> top-level binding aliasing `Applicative(pure)`. >> > > Sure... if we had a language that no one uses and could keep reforming > like putty until it is perfect. But we don't. > > A modest proposal: > > We can't keep tinkering with a language and it's libraries like this AND > have a growing ecosystem that serves an ever widening base, including the > range from newcomer to commercial deployment. SO - Why let's do all the > language tinkering in GHC 8 there can be as many prereleases of that as > needed until it is just right. ...and leave GHC 7 (7.10? roll back to > 7.8.4?) for all of us doing essential and dependable libraries, commercial > work, projects on Haskell that we don't want to have to go back and #ifdefs > to twice a year just to keep running, educators, people writing books. We > can keep improving GHC 7 as needed, and focus on bugs, security issues, > patches, cross compatibility, etc. > I'm just curious how much you think this would help, assuming that your solution would imply not upgrading to 8 until you're ready to. After all, you can already simply not upgrade now, and create (and distribute) fixes for bugs, security issues, cross-compatibility for 7 as you see fit. While that's a popular thing to do in lots of systems (but if we don't it. for gnus sake let's not adopt the inane parity implies stability numbering convention), it leaves two major issues unaddressed. #1, developer time. You need to get the people doing the work now to divide their efforts into the two branches.I don't know what percentage of that work is volunteer time, but I expect the answer is "most of it". If they aren't interested doing that now, what do you expect to change their mind? #2, everything else in the ecosystem. If you need updates to a library that require the branch you're not using, where does that leave you? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Wed Oct 7 01:18:03 2015 From: gershomb at gmail.com (Gershom B) Date: Tue, 6 Oct 2015 21:18:03 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87612k6j1v.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: Dear all, I think this discussion has gotten quite heated for reasons not related to the concrete MRP proposal, which, to be honest, I considered quite modest in terms of both scope and impact. Instead, I think it is a proxy for lots of remaining frustration and anxiety over the poor handling over the Foldable Traversable Proposal. I would like to remind everyone that due to the broad discussions and concerns over the proposal, a very rare, careful poll of Haskell users was taken, announced broadly in many channels. [1] The poll, overwhelmingly, revealed a mandate for the FTP. The breakdown of that mandate was 87% in favor among hobbyists and 79% in favor among non-hobbyists (who constituted a majority of those polled).? I. Generalities That said, even the _best_ poll was not a substitute for a better earlier discussion. The handling of the AMP and FTP, which I think was heroic in terms of minimizing breakage while accomplishing long-desired change also still could have been better. As a whole, the work accomplished the mandate of allowing code to be written backwards-compatible without requiring CPP. However, it did not also seek to prevent warnings. This in itself was an enormous step forward from changes in the past which have _not_ even managed to prevent the need for CPP. At the time, I think it was not recognized how much desire there would be for things that were _both_ CPP free and _also_ warning-free for 3 releases. I think one of the great elements of progress in the current discussion is that there is now a proposal on the table which recognizes this, and seeks to accomplish this change in accordance with this desire. It is not the world?s most important change, but the recognition that change should seek to be both CPP _and_ warning free is a good recognition, and I?m sure it will be taken into account in future proposals as well. I don?t think it is useful to continue to have abstract discussions on the conflict between desire for incremental improvement versus the need to minimize pain on maintainers. We might as well continue to argue about the need for purely functional programming versus the need to print ?hello world? to the console. Rather, we should put our collective minds together as collaborators and colleagues to accomplish _both_, and to come up with solutions that should work for everyone. To the extent this discussion has been about that, I think it has been useful and positive. However, to the extent this discussion insists, on either side, on the shallow idea that we must treat ?improvement? versus ?stability? as irreconcilable factions in necessary conflict, then I fear it will be a missed opportunity. II. Particulars With that in mind, I think the _concrete_ voices of concern have been the most useful. Gregory Collins? list of issues requiring CPP should be very sobering. Of note, I think they point to areas where the core libraries committee has not paid _enough_ attention (or perhaps has not been sufficiently empowered: recall that not all core libraries fall under its maintenance [2]). Things like the newtype FFI issue, the changes to prim functions, the splitup of old-time and the changes to exception code were _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently being. I don?t know all the reasons for this, but I suspect they just somewhat slipped under the radar. In any case, if all those changes were as carefully engineered as the MRP proposal has been, then imho things would have been much smoother. So, while this discussion may be frustrating, it nonetheless in some ways provides a model of how people have sought to do better and be more proactive with careful discussion of changes. This is much appreciated. Personally, since the big switch to extensible exceptions back prior in 6.10, and since the split-base nonsense prior to that, very few changes to the core libraries have really caused too much disruption in my code. Since then, the old-time cleanup was the worst, and the big sin there was that time-locale-compat was only written some time after the fact by a helpful third-party contributor and not engineered from the start. (I will note that the time library is one of the core libraries that is _not_ maintained by the core libraries committee).? Outside of that, the most disruptive changes to my code that I can recall have been from changes to the aeson library over the years ? particularly but not only regarding its handling of doubles. I don?t begrudge these changes ? they iteratively arrived at a _much_ better library than had they not been made. [3] After than, I made a few changes regarding Happstack and Snap API changes if I recall. Additionally, the addition of ?die? to System.Exit caused a few name clashes. My point is simply that there are many packages outside of base that also move, and ?real? users with ?real? code will these days often have quite a chain of dependencies, and will encounter movement and change from across many of them. So if we say ?base never changes? that does not mean ?packages will never break? ? it just means that base will not have the same opportunity to improve that other packages do, which will eventually lead to frustration, just as it did in the past and in the leadup to the BBP. III. Discussions Further, since there has been much discussion of a window of opportunity, I would like to offer a counterpoint to the (sound) advice that we take into consideration voices with long experience in Haskell. The window of opportunity is, by definition, regarding takeup of Haskell by new users. And so if newer users favor certain changes, then it is good evidence that those changes will help with uptake among other new users. So, if they are good changes on their own, then the fact that they are appealing to newer users should be seen as a point in their favor, rather than a reason to dismiss those opinions. But if we are in a situation where we see generations of adopters pitted against one another, then we already have deeper problems that need to be sorted out. Regarding where and how to have these discussions ? the decision was made some time ago (I believe at the start of the initial Haskell Prime process if not sooner, so circa 2009?) that the prime committee would focus on language extensions and not library changes, and that those changes would be delegated to the libraries@ list. The lack of structure to the libraries@ list is what prompted the creation of the libraries committee, whose ultimately responsibility it is to decide on and shepherd through these changes, in consultation with others and ideally driven by broad consensus. Prior to this structure, things broke even more, imho, and simultaneously the things that were widely desired were still not implemented. So I thank the libraries committee for their good work so far. So, it may be that the process of community discussion on core libraries changes is not best suited for the libraries@ list. But if not there, Where? I worry that the proliferation of lists will not improve things here. Those involved with Haskell have multiplied (this is good). The voices to take into account have multiplied (this is good). Necessarily, this means that there will just be _more_ stuff, and making sure that everyone can filter to just that part they want to is difficult. Here, perhaps, occasional libraries-related summary addenda to the ghc newsletter could be appropriate? Or is there another venue we should look towards???Chair?s reports? to the Haskell Weekly News maybe? IV. Summing up We should bear in mind after all that this is just about cleaning up a redundant typeclass method (albeit one in a very prominent place) and hardly the hill anyone would want to die on [4]. Nonetheless,?I think it would be?a good sign of progress and collaboration if we can find a way to implement a modest change like this in a way that everyone finds acceptable vis a vis a sufficiently slow pace, the lack of a need for CPP and the lack of any induced warnings. On the other hand, other opportunities will doubtless present themselves in the future. Best, Gershom [1] https://mail.haskell.org/pipermail/libraries/2015-February/025009.html [2]?https://wiki.haskell.org/Library_submissions#The_Core_Libraries [3] and in any case I am sure Bryan would be the last to want us to treat him as some sort of ?guru? on these matters.? [4] for those in search of better hills to die on, this is a list of some good ones: http://www.theawl.com/2015/07/hills-to-die-on-ranked? P.S. In case there is any question, this email, as all emails I write that do not state otherwise, is not being written in any particular capacity regarding the various infra-related hats I wear, but is just an expression of my own personal views. From mwm at mired.org Wed Oct 7 02:24:58 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 07 Oct 2015 02:24:58 +0000 Subject: [Haskell-cafe] Haskell ecosystem improvements meta-propsal In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: There's been a lot of complaints about the way things have worked in the past, with things going to fast, or to slow, or the right people not being heard, or notices not going to the right places, etc. As far as I can tell, the current process is that someone make a proposal on some mailing list, that gets debated by those who find out about it, maybe a wiki page gets set up and announced to those who already know about the proposal, and then it either happens or not. There's actually quite a bit of experience with dealing with such. I've dealt with the IETF RFC process and the Python PEP process, and both of them worked better than that. So I think we can do better. I'd like to suggest we adapt something a bit more formal that any process that changes a developer-visible API should have to go through. Note that bug fixes, most security fixes, and other things that don't change the API wouldn't be subject to this requirement. However, any change in an API, even one that's 100% backward compatible, not possibly breaking any code, would be. Initial thoughts on scope are anything in the Haskell Platform, as that seems to be a minimal definition of "Haskell ecosystem". Further, anything on hackage should be able to avail itself of the process. My concrete, though very broad proposal, with lots of details to be filled in yet, is that we need: 1) A wiki page that lists all proposals being considered, along with their current status and other relevant information. 2) A set of requirements a proposal must meet in order to be listed on that page. 3) An announcements list that only has announcements of things being added to the list. Anybody who has time to vote on a proposal should have time to be on this list. 4) An editorial group responsible for maintaining the list and providing guidance on meeting the requirements to get on it. The first three are easy. The fourth one is the killer. Somebody to do the work is the stumbling block for most proposals. This doesn't require deep technical knowledge of Haskell or the current ecosystem, but the ability to implement a process and judge things based on form and not content, Since it's my proposal, I'll volunteer as the first editor. Hopefully, others with better reputation will alsob e available. If adopted, the first two things on the list need to be a description of the process, followed shortly by a description of the requirements to be met. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasen.dubi at gmail.com Wed Oct 7 04:28:26 2015 From: rasen.dubi at gmail.com (Alexey Shmalko) Date: Wed, 7 Oct 2015 07:28:26 +0300 Subject: [Haskell-cafe] OShack hackathon (offer of help) Message-ID: Hi! We have the OShack hackathon[1] in Kyiv, Ukraine this weekend. It's a 24-hour hackathon dedicated to Open-Source projects. I with friends want to offer our help of time to any Haskell project that needs it. Just ping me back so we can discuss the details. If you're in Kyiv and want to join our team, we'll be glad to see you! You can also join online. Regards, Alexey Shmalko [1]: http://hackraft.com/hackathon/oshack/ From mark.lentczner at gmail.com Wed Oct 7 06:36:39 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 6 Oct 2015 23:36:39 -0700 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: Mike - You might look up the phrase "A modest proposal". ... for gnus sake let's not adopt the inane parity implies stability > numbering convention ... > 6.10 .. 6.12 .. 7.0 .. 7.2 .. 7.4 .. 7.8 .. 7.10 - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Wed Oct 7 06:45:15 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 6 Oct 2015 23:45:15 -0700 Subject: [Haskell-cafe] Haskell ecosystem improvements meta-propsal In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer wrote: > I've dealt with the IETF RFC process and the Python PEP process, and both > of them worked better than that. While both those are good examples of mostly working organizations shepherding foundational technical standard(s) along... there is one thing more important than their processes: Their stance. Both organizations have a very strong engineering discipline of keeping deployed things working without change. I don't think it is enough to simply model their process. Until about three years ago, the Haskell community also had such a discipline. It has been steadily eroding over the last few years. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Wed Oct 7 07:13:00 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 7 Oct 2015 09:13:00 +0200 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: References: <56142DE3.30604@home.nl> <561436B8.8090804@home.nl> Message-ID: <5614C5FC.1020508@home.nl> Maybe im on the wrong track now. I know that if three numbers are the same then the outcome will be false. The same if two numbers are the same. Can I not do something like this : prop_different x y z = not( (x /= y && y /= z && x /= z)) to test all cases at once. Roelof Op 7-10-2015 om 00:28 schreef Rogan Creswick: > On Tue, Oct 6, 2015 at 2:01 PM, Roelof Wobben wrote: >> but why this part : >> >> x (x + y) (x - (y + 1)) > That is buggy. I was trying to quickly create three arguments that > are guaranteed to be different by some random amount, but what I wrote > doesn't always work (eg: if y = 0, then the first two arguments are > the same, if y is -1, the first and 3rd are the same, if x is MAX_INT, > then it may or may not be the same as other arguments, depending on Y, > etc...) > > The predicate guard should work, though it may take longer to run. > > --Rogan > >> >> Roelof >> >> Op 6-10-2015 om 22:31 schreef Rogan Creswick: >>> On Tue, Oct 6, 2015 at 1:24 PM, Roelof Wobben wrote: >>>> Hello, >>>> >>>> I have written a function to test if three numbers are the same. >>>> >>>> Now I want to test my functions by using quickCheck. >>>> >>>> So I thought to test first if all three are the same. >>>> >>>> but how can I tell quickcheck that all numbers are the same. >>> Just have quickcheck generate one number, and use it for all three >>> arguments, eg: >>> >>> prop_allSame :: Int -> Bool >>> prop_allSame x = yourFn x x x >>> >>> then test the other cases: >>> >>> prop_different :: Int -> Int -> Int -> Property >>> prop_different x y z = x /= y && y /= z && x /= z ==> not $ yourFn x y z >>> >>> That's probably OK for ints, but generally the guard in that style >>> isn't a great solution, since quickcheck will just keep generating >>> inputs until the predicate is satisfied. That can take a while, so >>> you could also manually offset the first input in various ways: >>> >>> prop_different :: Int -> Int -> Bool >>> prop_different x y = not $ yourFn x (x + y) (x - (y + 1)) -- I put a >>> +1 in here to avoid returning true where y = 0, >>> >>> There are probably other ways to mutate a randomly generated input for >>> your problem that may work better, but that's the general idea. >>> >>> --Rogan >>> >>>> and second question : hwo do the test likeif two numbers are the same. >>>> >>>> I ask this because I try to solve a exercise of the programming Haskell >>>> book, >>>> IM have read chapter 3 now. >>>> >>>> Roelof >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> ----- >>> Geen virus gevonden in dit bericht. >>> Gecontroleerd door AVG - www.avg.com >>> Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte: >>> 10/06/15 >>> >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > ----- > Geen virus gevonden in dit bericht. > Gecontroleerd door AVG - www.avg.com > Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte: 10/06/15 > > From mwm at mired.org Wed Oct 7 07:21:54 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 07 Oct 2015 07:21:54 +0000 Subject: [Haskell-cafe] Haskell ecosystem improvements meta-propsal In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On Wed, Oct 7, 2015 at 1:45 AM Mark Lentczner wrote: > On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer wrote: > >> I've dealt with the IETF RFC process and the Python PEP process, and both >> of them worked better than that. > > > While both those are good examples of mostly working organizations > shepherding foundational technical standard(s) along... there is one thing > more important than their processes: Their stance. Both organizations have > a very strong engineering discipline of keeping deployed things working > without change. I don't think it is enough to simply model their process. > Well, until Python 3, anyway. My goal wasn't to recreate the engineering discipline that deployed things keep working without change as you upgrade the ecosystem, it's to provide a mechanism so the community can more easily engage with the evolution of the ecosystem. Hopefully this will make it easier for the community to move things forward in a desirable manner. But it's a process, and leaves the question of whether the desire is for more stability or a less stagnant language up to the users of the process. I don't necessarily want to model the IETF or PEP processes. Those are a starting point. I tried to abstract the initial points out enough that the final result could be either one of them, or something totally unrelated that's a better fit for the Haskell community. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Oct 7 07:35:21 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 07 Oct 2015 09:35:21 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: (Sven Panne's message of "Tue, 6 Oct 2015 19:41:51 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: <87lhbfm8qu.fsf@gnu.org> On 2015-10-06 at 19:41:51 +0200, Sven Panne wrote: > 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel : > >> [...] That being said, as how to write your Monad instances today with GHC >> 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This >> *does* work (admittedly for an easy example, but this can be >> generalised): >> >> >> --8<---------------cut here---------------start------------->8--- >> module MyMaybe where >> >> import Control.Applicative (Applicative(..)) >> import Prelude (Functor(..), Monad(..), (.)) >> -- or alternatively: `import qualified Prelude as P` >> [...] >> --8<---------------cut here---------------end--------------->8--- >> >> This example above compiles -Wall-clean and satisfies all your 3 stated >> requirements afaics. I do admit this probably not what you had in mind. >> > > OK, so the trick is that you're effectively hiding Applicative from the > Prelude (which might be a no-op). This "works" somehow, but is not > satisfactory IMHO for several reasons: [...] Btw, I've also seen the trick below, in which you use the aliased `A.` prefix just once so GHC considers the import non-redundant, and don't have to suffer from prefixed operators in the style of `A.<*>`. Is this any better? --8<---------------cut here---------------start------------->8--- import Control.Applicative as A (Applicative(..)) data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance A.Applicative Maybe' where pure = Just' f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1) instance Monad Maybe' where Nothing' >>= _ = Nothing' Just' x >>= f = f x return = pure -- "deprecated" since GHC 7.10 --8<---------------cut here---------------end--------------->8--- -- hvr From svenpanne at gmail.com Wed Oct 7 08:07:38 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 7 Oct 2015 10:07:38 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87lhbfm8qu.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <87lhbfm8qu.fsf@gnu.org> Message-ID: 2015-10-07 9:35 GMT+02:00 Herbert Valerio Riedel : > Btw, I've also seen the trick below, in which you use the aliased `A.` > prefix just once so GHC considers the import non-redundant, and don't > have to suffer from prefixed operators in the style of `A.<*>`. > > Is this any better? [...] > While not perfect, it's much better than having to fiddle around with Prelude imports. Although there's the slight danger that somebody else (or the author 1 year later) looks at the code and has a WTF-moment... ;-) To be honest, while it's somehow obvious how it works when you read it, I've never seen that trick. Perhaps stuff like this belongs into some general "Porting Guide", along with its alternatives. It's general enough that it should not be buried in some AMP/FTP/return/... transitioning guide. Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Oct 7 15:36:41 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 7 Oct 2015 15:36:41 +0000 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: <3d672fd5db1546b189f16d2a890a953d@DB4PR30MB030.064d.mgd.msft.net> I think there are several different conversations going on at once in this thread. I think it?s worth keeping them separate. ? Haskell Prime. The intention there is to take a set of language features that are already in wide use in GHC (i.e. have demonstrably proved valuable), work out any dark corners, formalise them, and embody the result in a new Haskell Report. That puts a useful stake in the ground, empowers alternative implementations of Haskell, gives confidence all round. I think it?d be unusual for the Haskell Prime committee to specify a new feature of the language, one that had not been field tested. ? Libraries. AMP, BBP, and Monad(return) are small but fundamental changes to the core libraries. I think there was a consensus (not universal in the case of BBP) that the change was good. Yet AMP and BBP (esp) were controversial. The issues were mostly around how to make the transition; and, given that the transition is expensive, whether the cost/benefit tradeoff justifies the change. The question of moving ?return? out of Monad is in this category. The Core Libraries Committee was formed explicitly to handle this stuff. So my prior assumption was that the CLC would handle the Monad(return) question, not Haskell Prime. Mark?s suggestion of a ?stable? GHC 7.10 and a new GHC 8.0 is a reasonable one. But I for one would find it hard to promise to back-port every bug fix, especially as the two code bases diverge (which they will). Here is another idea. GHC knows very little about Monad. It would take work, but it probably wouldn?t be impossible to make the same GHC work with two different ?base? libraries, each with a different definitions of the Monad class. That would not solve the problem: you still could not use one library that used old Monad with another library that used new Monad. But at least it?d decouple it from which version of GHC you were using. I stress: it would take some work to make this go, and I?d prefer not to do this. Returning to ?return?, my instinct is that when these pervasive breaking library changes come up, we should batch them into larger clumps. The ?treadmill? complaint is real: small change A made me re-release my library; then small change B came along; and so on. Perhaps if we saved them up this would be less of an issue, for two reasons. First, the work happens once rather than many times. Second, the benefits of the change is the sum of the benefits of the little component changes, and so is more attractive to library authors and library clients. That line of thinking would suggest that the Core Libraries Committee might want to maintain a list of well-worked out agreed changes that are being ?saved up? for execution at some later date. Simon From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Mike Meyer Sent: 07 October 2015 00:24 To: Mark Lentczner; Johan Tibell Cc: Haskell Libraries; haskell cafe; haskell-prime at haskell.org List Subject: Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner > wrote: On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel > wrote: TLDR: To complete the AMP, turn `Monad(return)` method into a top-level binding aliasing `Applicative(pure)`. Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't. A modest proposal: We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc. I'm just curious how much you think this would help, assuming that your solution would imply not upgrading to 8 until you're ready to. After all, you can already simply not upgrade now, and create (and distribute) fixes for bugs, security issues, cross-compatibility for 7 as you see fit. While that's a popular thing to do in lots of systems (but if we don't it. for gnus sake let's not adopt the inane parity implies stability numbering convention), it leaves two major issues unaddressed. #1, developer time. You need to get the people doing the work now to divide their efforts into the two branches.I don't know what percentage of that work is volunteer time, but I expect the answer is "most of it". If they aren't interested doing that now, what do you expect to change their mind? #2, everything else in the ecosystem. If you need updates to a library that require the branch you're not using, where does that leave you? -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Wed Oct 7 16:04:11 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 7 Oct 2015 18:04:11 +0200 Subject: [Haskell-cafe] Looking for a new maintainer for the network package Message-ID: I find myself with too little time to maintain the network package anymore, so I'm hereby announcing that I'm looking for a new maintainer. Since lots of people depend on the network package, the maintainer should probably be someone that values stability. If you want to completely rethink how networking APIs should work in Haskell, this is probably not for you. Please email me if you're interested. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Wed Oct 7 16:05:03 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 7 Oct 2015 18:05:03 +0200 Subject: [Haskell-cafe] Looking for a new maintainer for the template package Message-ID: I find myself with too little time to maintain the template package anymore, so I'm hereby announcing that I'm looking for a new maintainer. The template package is a quaint little package for doing Python-style string interpolation. Please email me if you're interested. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Wed Oct 7 16:09:06 2015 From: greg at gregorycollins.net (Gregory Collins) Date: Wed, 7 Oct 2015 09:09:06 -0700 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On Tue, Oct 6, 2015 at 6:18 PM, Gershom B wrote: > > With that in mind, I think the _concrete_ voices of concern have been the > most useful. Gregory Collins? list of issues requiring CPP should be very > sobering. Of note, I think they point to areas where the core libraries > committee has not paid _enough_ attention (or perhaps has not been > sufficiently empowered: recall that not all core libraries fall under its > maintenance [2]). Things like the newtype FFI issue, the changes to prim > functions, the splitup of old-time and the changes to exception code were > _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently > being. I don?t know all the reasons for this, but I suspect they just > somewhat slipped under the radar. In fact, more often than I would like, I can recall arguing against a particular change on the grounds that it would break user code, and in Haskell land this is a battle I usually lose. Usually the argument on the other side boils down to expediency or hygiene/aesthetics -- it's *difficult* to engineer a change to some core infra in a way that minimizes impact on people downstream, and it takes a long time. Often "this change is going to cause a small amount of work for all of my users" is something that seems to not be taken into consideration at all. For this particular proposal, every user will have some small amount of work *w* to do (to read the change notes, understand why 'return' is going away, train yourself to use "pure" now instead of "return" like you've been using for 15 years, etc). It might feel like *w* is small and so the change isn't burdensome, but *n* is literally everyone who uses the language, so the total work *w***n* is going to amount to quite a few person-hours. I just want to make sure that everyone is keeping that in mind and weighing that effort against the benefits. Outside of that, the most disruptive changes to my code that I can recall > have been from changes to the aeson library over the years ? particularly > but not only regarding its handling of doubles. I don?t begrudge these > changes ? they iteratively arrived at a _much_ better library than had they > not been made. [3] After than, I made a few changes regarding Happstack and > Snap API changes if I recall. Additionally, the addition of ?die? to > System.Exit caused a few name clashes. My point is simply that there are > many packages outside of base that also move, and ?real? users with ?real? > code will these days often have quite a chain of dependencies, and will > encounter movement and change from across many of them. So if we say ?base > never changes? that does not mean ?packages will never break? ? it just > means that base will not have the same opportunity to improve that other > packages do, which will eventually lead to frustration, just as it did in > the past and in the leadup to the BBP. > Culturally, we have a problem with library authors of all stripes being too cavalier about breaking user programs: we definitely lean towards "move fast and break things" vs "stay stable and don't make work for users". As you write more and more Haskell code, you depend on more and more of these libraries, and this means that once you go beyond a certain threshold you will be spending a significant amount of your time just running to keep up with the treadmill. Personally I just don't have enough time for writing Haskell code as I used to (or I would like), so I would say for me that the treadmill tax is now probably exceeding 50% of my total hours invested. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From b at chreekat.net Wed Oct 7 16:15:58 2015 From: b at chreekat.net (Bryan Richter) Date: Wed, 7 Oct 2015 09:15:58 -0700 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: <56142DE3.30604@home.nl> References: <56142DE3.30604@home.nl> Message-ID: <20151007161558.GA15337@fuzzbomb> On Tue, Oct 06, 2015 at 10:24:03PM +0200, Roelof Wobben wrote: > Hello, > > I have written a function to test if three numbers are the same. > > Now I want to test my functions by using quickCheck. > > So I thought to test first if all three are the same. > > but how can I tell quickcheck that all numbers are the same. Easy, just generate a single number. :) Make it correct by construction. prop_allSame x = yourFunc x x x == True > and second question : hwo do the test likeif two numbers are the same. Now the hard part is not generating two numbers that are the same, but generating two *different* numbers. To do that you may need to create a custom generator. unequalPair = do x <- arbitrary y <- arbitrary `suchThat` y /= x return (x,y) Now you can use that generator: prop_twoSame = forAll unequalPair $ \(x,y) -> yourFunc x x y == False -- But you might want to test all permutations! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From creswick at gmail.com Wed Oct 7 16:32:02 2015 From: creswick at gmail.com (Rogan Creswick) Date: Wed, 7 Oct 2015 09:32:02 -0700 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: <5614C5FC.1020508@home.nl> References: <56142DE3.30604@home.nl> <561436B8.8090804@home.nl> <5614C5FC.1020508@home.nl> Message-ID: On Wed, Oct 7, 2015 at 12:13 AM, Roelof Wobben wrote: > I know that if three numbers are the same then the outcome will be false. > The same if two numbers are the same. > > Can I not do something like this : > > prop_different x y z = not( (x /= y && y /= z && x /= z)) > > to test all cases at once. That looks like it will work (I'm assuming you're actually calling your function in the property and comparing with that boolean expression); is that the same way your function is implemented? --Rogan > > Roelof > > > > Op 7-10-2015 om 00:28 schreef Rogan Creswick: > >> On Tue, Oct 6, 2015 at 2:01 PM, Roelof Wobben wrote: >>> >>> but why this part : >>> >>> x (x + y) (x - (y + 1)) >> >> That is buggy. I was trying to quickly create three arguments that >> are guaranteed to be different by some random amount, but what I wrote >> doesn't always work (eg: if y = 0, then the first two arguments are >> the same, if y is -1, the first and 3rd are the same, if x is MAX_INT, >> then it may or may not be the same as other arguments, depending on Y, >> etc...) >> >> The predicate guard should work, though it may take longer to run. >> >> --Rogan >> >>> >>> Roelof >>> >>> Op 6-10-2015 om 22:31 schreef Rogan Creswick: >>>> >>>> On Tue, Oct 6, 2015 at 1:24 PM, Roelof Wobben wrote: >>>>> >>>>> Hello, >>>>> >>>>> I have written a function to test if three numbers are the same. >>>>> >>>>> Now I want to test my functions by using quickCheck. >>>>> >>>>> So I thought to test first if all three are the same. >>>>> >>>>> but how can I tell quickcheck that all numbers are the same. >>>> >>>> Just have quickcheck generate one number, and use it for all three >>>> arguments, eg: >>>> >>>> prop_allSame :: Int -> Bool >>>> prop_allSame x = yourFn x x x >>>> >>>> then test the other cases: >>>> >>>> prop_different :: Int -> Int -> Int -> Property >>>> prop_different x y z = x /= y && y /= z && x /= z ==> not $ yourFn x y z >>>> >>>> That's probably OK for ints, but generally the guard in that style >>>> isn't a great solution, since quickcheck will just keep generating >>>> inputs until the predicate is satisfied. That can take a while, so >>>> you could also manually offset the first input in various ways: >>>> >>>> prop_different :: Int -> Int -> Bool >>>> prop_different x y = not $ yourFn x (x + y) (x - (y + 1)) -- I put a >>>> +1 in here to avoid returning true where y = 0, >>>> >>>> There are probably other ways to mutate a randomly generated input for >>>> your problem that may work better, but that's the general idea. >>>> >>>> --Rogan >>>> >>>>> and second question : hwo do the test likeif two numbers are the same. >>>>> >>>>> I ask this because I try to solve a exercise of the programming Haskell >>>>> book, >>>>> IM have read chapter 3 now. >>>>> >>>>> Roelof >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>>> ----- >>>> Geen virus gevonden in dit bericht. >>>> Gecontroleerd door AVG - www.avg.com >>>> Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte: >>>> 10/06/15 >>>> >>>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> ----- >> Geen virus gevonden in dit bericht. >> Gecontroleerd door AVG - www.avg.com >> Versie: 2015.0.6140 / Virusdatabase: 4435/10768 - datum van uitgifte: >> 10/06/15 >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From hesselink at gmail.com Wed Oct 7 16:38:01 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 7 Oct 2015 18:38:01 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On 7 October 2015 at 18:09, Gregory Collins wrote: > For this particular proposal, every user will have some small amount of work > w to do (to read the change notes, understand why 'return' is going away, > train yourself to use "pure" now instead of "return" like you've been using > for 15 years, etc). While I don't think it detracts from your argument, it seems you misread the original proposal. At no point will it remove `return` completely. It would be moved out of the `Monad` class and be made into a top-level definition instead, so you would still be able to use it. Erik From r.wobben at home.nl Wed Oct 7 17:01:15 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 7 Oct 2015 19:01:15 +0200 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: References: <56142DE3.30604@home.nl> <561436B8.8090804@home.nl> <5614C5FC.1020508@home.nl> Message-ID: <56154FDB.3040503@home.nl> Op 7-10-2015 om 18:32 schreef Rogan Creswick: > On Wed, Oct 7, 2015 at 12:13 AM, Roelof Wobben wrote: >> I know that if three numbers are the same then the outcome will be false. >> The same if two numbers are the same. >> >> Can I not do something like this : >> >> prop_different x y z = not( (x /= y && y /= z && x /= z)) >> >> to test all cases at once. > That looks like it will work (I'm assuming you're actually calling > your function in the property and comparing with that boolean > expression); is that the same way your function is implemented? > > --Rogan > Unfortanally yes but I do not know another way to test it. Im only a beginner which has read 2 chapters of the Crafts book. Roelof From rasen.dubi at gmail.com Wed Oct 7 17:13:55 2015 From: rasen.dubi at gmail.com (Alexey Shmalko) Date: Wed, 7 Oct 2015 20:13:55 +0300 Subject: [Haskell-cafe] Looking for a new maintainer for the template package In-Reply-To: References: Message-ID: Hi, Johan! I would like to maintain the template package. It seems small enough, so I can easily handle it. Regards, Alexey On Wed, Oct 7, 2015 at 7:05 PM, Johan Tibell wrote: > I find myself with too little time to maintain the template package anymore, > so I'm hereby announcing that I'm looking for a new maintainer. > > The template package is a quaint little package for doing Python-style > string interpolation. > > Please email me if you're interested. > > -- Johan > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From michael at orlitzky.com Wed Oct 7 17:34:21 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Wed, 7 Oct 2015 13:34:21 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: <5615579D.5040900@orlitzky.com> (replying to no one in particular) This problem isn't specific to Haskell. In every other language, you have projects that support major versions of toolkits, compilers, libraries and whatnot. And there's already a tool for it: git. Instead of using #ifdef to handle four different compilers, keep a branch for each. Git is designed to make this easy, and it's usually trivial to merge changes from the master branch back into e.g. the ghc-7.8 branch. That way the code in your master branch stays clean. When you want to stop supporting an old GHC, delete that branch. From fa-ml at ariis.it Wed Oct 7 17:48:13 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 7 Oct 2015 19:48:13 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5615579D.5040900@orlitzky.com> References: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> Message-ID: <20151007174812.GA14335@casa.casa> On Wed, Oct 07, 2015 at 01:34:21PM -0400, Michael Orlitzky wrote: > Instead of using #ifdef to handle four different compilers, keep a > branch for each. Git is designed to make this easy, and it's usually > trivial to merge changes from the master branch back into e.g. the > ghc-7.8 branch. That way the code in your master branch stays clean. > When you want to stop supporting an old GHC, delete that branch. I suspect `cabal install your-library` without CPP would explode in the face of (some of) your users though. From taruti at taruti.net Wed Oct 7 18:02:39 2015 From: taruti at taruti.net (Taru Karttunen) Date: Wed, 7 Oct 2015 21:02:39 +0300 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5615579D.5040900@orlitzky.com> References: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> Message-ID: <9CEC20CB3BDE0224EDFFAD9B171DC0@mail.local> On 07.10 13:34, Michael Orlitzky wrote: > (replying to no one in particular) > > This problem isn't specific to Haskell. In every other language, you > have projects that support major versions of toolkits, compilers, > libraries and whatnot. And there's already a tool for it: git. > > Instead of using #ifdef to handle four different compilers, keep a > branch for each. Git is designed to make this easy, and it's usually > trivial to merge changes from the master branch back into e.g. the > ghc-7.8 branch. That way the code in your master branch stays clean. > When you want to stop supporting an old GHC, delete that branch. Isn't this hard to do correctly for libraries with Hackage and Cabal and narrowly versioned dependencies and deep import graphs? E.g. when adding a new feature to the library and merging it back to the ghc-7.8 branch the versions needed for features vs compiler support could end up causing complex dependency clauses for users of such libraries. - Taru Karttunen From michael at orlitzky.com Wed Oct 7 18:06:28 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Wed, 7 Oct 2015 14:06:28 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <20151007174812.GA14335@casa.casa> References: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <20151007174812.GA14335@casa.casa> Message-ID: <56155F24.9030207@orlitzky.com> On 10/07/2015 01:48 PM, Francesco Ariis wrote: > On Wed, Oct 07, 2015 at 01:34:21PM -0400, Michael Orlitzky wrote: >> Instead of using #ifdef to handle four different compilers, keep a >> branch for each. Git is designed to make this easy, and it's usually >> trivial to merge changes from the master branch back into e.g. the >> ghc-7.8 branch. That way the code in your master branch stays clean. >> When you want to stop supporting an old GHC, delete that branch. > > I suspect `cabal install your-library` without CPP would explode in > the face of (some of) your users though. The different branches would have different cabal files saying with which version of GHC they work. If the user has ghc-7.8 installed, then cabal-install (or at least, any decent package manager) should pick the latest version supporting ghc-7.8 to install. From michael at orlitzky.com Wed Oct 7 18:12:49 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Wed, 7 Oct 2015 14:12:49 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <9CEC20CB3BDE0224EDFFAD9B171DC0@mail.local> References: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <9CEC20CB3BDE0224EDFFAD9B171DC0@mail.local> Message-ID: <561560A1.1020100@orlitzky.com> On 10/07/2015 02:02 PM, Taru Karttunen wrote: >> >> Instead of using #ifdef to handle four different compilers, keep a >> branch for each. Git is designed to make this easy, and it's usually >> trivial to merge changes from the master branch back into e.g. the >> ghc-7.8 branch. That way the code in your master branch stays clean. >> When you want to stop supporting an old GHC, delete that branch. > > Isn't this hard to do correctly for libraries with Hackage > and Cabal and narrowly versioned dependencies and deep > import graphs? It can be... > E.g. when adding a new feature to the library and merging > it back to the ghc-7.8 branch the versions needed for > features vs compiler support could end up causing > complex dependency clauses for users of such libraries. > but can you think of an example where you don't have the same problem with #ifdef? If I need to use a new version of libfoo and the new libfoo only supports ghc-7.10, then I'm screwed either way right? From creswick at gmail.com Wed Oct 7 18:25:16 2015 From: creswick at gmail.com (Rogan Creswick) Date: Wed, 7 Oct 2015 11:25:16 -0700 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: <56154FDB.3040503@home.nl> References: <56142DE3.30604@home.nl> <561436B8.8090804@home.nl> <5614C5FC.1020508@home.nl> <56154FDB.3040503@home.nl> Message-ID: On Wed, Oct 7, 2015 at 10:01 AM, Roelof Wobben wrote: > Op 7-10-2015 om 18:32 schreef Rogan Creswick: >> >> On Wed, Oct 7, 2015 at 12:13 AM, Roelof Wobben wrote: >>> >>> I know that if three numbers are the same then the outcome will be false. >>> The same if two numbers are the same. >>> >>> Can I not do something like this : >>> >>> prop_different x y z = not( (x /= y && y /= z && x /= z)) >>> >>> to test all cases at once. >> >> That looks like it will work (I'm assuming you're actually calling >> your function in the property and comparing with that boolean >> expression); is that the same way your function is implemented? >> >> --Rogan >> > > Unfortanally yes but I do not know another way to test it. > Im only a beginner which has read 2 chapters of the Crafts book. Then I'd suggest using the quickcheck property guards ( `==>`) to only generate inputs that are known to be equal, or not equal and test separately in a few different properties. --Rogan > > > Roelof > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From ozgurakgun at gmail.com Wed Oct 7 18:33:32 2015 From: ozgurakgun at gmail.com (Ozgur Akgun) Date: Wed, 7 Oct 2015 19:33:32 +0100 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: References: <56142DE3.30604@home.nl> <561436B8.8090804@home.nl> <5614C5FC.1020508@home.nl> <56154FDB.3040503@home.nl> Message-ID: On 7 October 2015 at 19:25, Rogan Creswick wrote: > Then I'd suggest using the quickcheck property guards ( `==>`) to only > generate inputs that are known to be equal, or not equal and test > separately in a few different properties. > This is not true, ==> still does generate and test. Prelude> import Test.QuickCheck Prelude Test.QuickCheck> let f x = x == 13 ==> mod x 2 == 1 Prelude Test.QuickCheck> quickCheck f *** Gave up! Passed only 6 tests. Also try verboseCheck to see what values are generated. Ozgur -------------- next part -------------- An HTML attachment was scrubbed... URL: From creswick at gmail.com Wed Oct 7 18:39:32 2015 From: creswick at gmail.com (Rogan Creswick) Date: Wed, 7 Oct 2015 11:39:32 -0700 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: References: <56142DE3.30604@home.nl> <561436B8.8090804@home.nl> <5614C5FC.1020508@home.nl> <56154FDB.3040503@home.nl> Message-ID: On Wed, Oct 7, 2015 at 11:33 AM, Ozgur Akgun wrote: > This is not true, ==> still does generate and test. I could have phrased that better. Sure, it generates values, but it will never provide them to your test, so your logic is simpler. > Prelude> import Test.QuickCheck > Prelude Test.QuickCheck> let f x = x == 13 ==> mod x 2 == 1 > Prelude Test.QuickCheck> quickCheck f > *** Gave up! Passed only 6 tests. That's unlikely to be a problem given the test inputs in the original question, but yes, it is certainly an issue to know about. Roelof - The issue Ozgur is demonstrating is that the ==> operator will just discard test inputs that were generated but which did not satisfy the predicate (here that x == 13). QuickCheck will eventually stop trying to generate inputs (you can tune this), and produce something like the above result. --Rogan > > Also try verboseCheck to see what values are generated. > > Ozgur > From davidleothomas at gmail.com Wed Oct 7 19:50:43 2015 From: davidleothomas at gmail.com (David Thomas) Date: Wed, 7 Oct 2015 12:50:43 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5615579D.5040900@orlitzky.com> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> Message-ID: This sounds like the right approach. To whatever degree existing tooling makes this difficult, maybe we can fix existing tooling? On Wed, Oct 7, 2015 at 10:34 AM, Michael Orlitzky wrote: > (replying to no one in particular) > > This problem isn't specific to Haskell. In every other language, you > have projects that support major versions of toolkits, compilers, > libraries and whatnot. And there's already a tool for it: git. > > Instead of using #ifdef to handle four different compilers, keep a > branch for each. Git is designed to make this easy, and it's usually > trivial to merge changes from the master branch back into e.g. the > ghc-7.8 branch. That way the code in your master branch stays clean. > When you want to stop supporting an old GHC, delete that branch. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From mark.lentczner at gmail.com Wed Oct 7 21:13:02 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Wed, 7 Oct 2015 22:13:02 +0100 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink wrote: > While I don't think it detracts from your argument, it seems you > misread the original proposal. At no point will it remove `return` > completely. It would be moved out of the `Monad` class and be made > into a top-level definition instead, so you would still be able to use > it. > Then why bother? If you don't intend to regard code that uses "return" as old, out-dated, in need of updating, etc.... If you don't intend to correct people on #haskell to use pure instead of return... If you don't tsk tsk all mentions of it in books.... If you don't intend to actually deprecate it. Why bother? But seriously, why do you think that "you would still be able to use it"? That is true for only the simplest of code - and untrue for anyone who has a library that defines a Monad - or anyone who has a library that they want to keep "up to date". Do you really want to have a library where all your "how to use this" code has return in the examples? Shouldn't now be pure? Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown in Hackage? This is just a nightmare for a huge number of libraries, and especially many commonly used ones. Why bother! -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Wed Oct 7 21:34:50 2015 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 7 Oct 2015 23:34:50 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: On 10/07/2015 08:36 AM, Mark Lentczner wrote: > Mike - > > You might look up the phrase "A modest proposal". > While I personally appreciated it, I don't think irony/sarcasm/satire is particularly appropriate given the state of discussion at this point ;). Regards, From achudnov at gmail.com Wed Oct 7 22:08:43 2015 From: achudnov at gmail.com (Andrey Chudnov) Date: Wed, 7 Oct 2015 18:08:43 -0400 Subject: [Haskell-cafe] status and future of haskell98 and haskell2010 packages Message-ID: <561597EB.8020906@gmail.com> Hello, My e-mail was rejected from libraries at haskell.org (the official maintenance contact of the two packages in question), so I'm trying my luck here instead. Hoping I can get some answers on the following questions: 1. What is the status of `haskell2010` and `haskell98` packages? Are they supported? Deprecated? In need of new maintainers? 2. Assuming the answer to the previous question is "alive and well", are there any plans to release new versions of those for GHC 7.10 and beyond? Thanks in advance, Andrey From targen at gmail.com Wed Oct 7 22:42:09 2015 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Wed, 7 Oct 2015 18:12:09 -0430 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On Wed, Oct 7, 2015 at 4:43 PM, Mark Lentczner wrote: > If you don't intend to actually deprecate it. > Why bother? > > But seriously, why do you think that "you would still be able to use it"? > That is true for only the simplest of code - and untrue for anyone who has a > library that defines a Monad - or anyone who has a library that they want to > keep "up to date". Do you really want to have a library where all your "how > to use this" code has return in the examples? Shouldn't now be pure? Do I > now need -XCPP just for Haddock? and my wiki page? And what gets shown in > Hackage? This is just a nightmare for a huge number of libraries, and > especially many commonly used ones. > > Why bother! This is explained in the original proposal. In particular, it eliminates opportunities for errors and simplifies ApplicativeDo. I don?t believe anyone has proposed removing return from base. The only proposed change is turning return into a stand-alone function instead of a method in Monad. There is no proposal for removing return. From allbery.b at gmail.com Wed Oct 7 23:05:44 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 7 Oct 2015 19:05:44 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson wrote: > Please consider that the the way practical development really happens[2] ...among web developers, who of course are the only real developers? Have you considered that there are developers who are not web developers? The past day has convinced me that the web devs have relegated everyone else to fake-non-programmer status and actively want them out of the community because fake programmers don't benefit you real programmers. I had heard that the financial users generally refused to have anything to do with the Haskell community. Now I know why. I wonder how many of them, if any indeed are left after past breaking changes, are in the process of switching to OCaml. I'm sure you consider that a good thing, because they're obviously just holding back "real programmers". -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Wed Oct 7 23:16:29 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 8 Oct 2015 12:16:29 +1300 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: References: <56142DE3.30604@home.nl> <561436B8.8090804@home.nl> Message-ID: You can generate two unequal integers by doing prop_twoDifferent :: Int -> Int -> Bool prop_twoDifferent x y = yourFn2 x y' where y' = if y >= x then y+1 else y Letting the number of distinct Int values be N, there are N*N pairs of Ints but only N*(N-1) pairs of *different* Ints, so this technique will generate some x y' pairs more often than others. In fact you will get (x,minBound::Int) with probability 2/N and (x,y>minBound) with probability 1/N. The advantage of using a guard is that the probabilities come out right (it's the "rejection method", in statistical parlance). You can use that method to generate x x y x y x y x x You can iterate the same idea to generate triples. From spam at scientician.net Wed Oct 7 23:38:51 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 8 Oct 2015 01:38:51 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: On 10/08/2015 01:05 AM, Brandon Allbery wrote: > On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson > wrote: > >> Please consider that the the way practical development really happens[2] > > > ....among web developers, who of course are the only real developers? > Nononono, I only provided that as an example. I'm well aware that there are whole other ecosystems. (I, for example, am currently doing full-stack.) > Have you considered that there are developers who are not web developers? > The past day has convinced me that the web devs have relegated everyone > else to fake-non-programmer status and actively want them out of the > community because fake programmers don't benefit you real programmers. > Re-read your own words. You're doing exactly the same, just in reverse. > I had heard that the financial users generally refused to have anything to > do with the Haskell community. > Now I know why. I think Standard Charatered might disagree, but... whatevs. > > I wonder how many of them, if any indeed are left after past breaking > changes, are in the process of switching to OCaml. I'm sure you consider > that a good thing, because they're obviously just holding back "real > programmers". > O'calm down! :) The world isn't going to end over this. (And... if you still think it is: Provide quantifiable data: Tell us how many of *your* MLoC will be affected. Tell us... whatever you can without violating NDAs, etc. "We" *will* apprectiate and take this into account.) Regards, From mwm at mired.org Wed Oct 7 23:39:19 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 07 Oct 2015 23:39:19 +0000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: On Wed, Oct 7, 2015 at 6:05 PM Brandon Allbery wrote: > On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson > wrote: > >> Please consider that the the way practical development really happens[2] > > ...among web developers, who of course are the only real developers? > [...] > I had heard that the financial users generally refused to have anything to > do with the Haskell community. > Now I know why. > I'm curious - do "practical" developers really feel like they have to rush out and update their tool chain whenever a new version of part of it comes out? Most of the projects I've worked on considered the language version as a fixed part of the technology stack, and almost never updated it. Even when using Python, which valued not breaking working code more than it's own zen. But changing anything that potentially affected all the code in a working project was pretty much never done, and always involved a lot of effort. So the worst headache I got from language evolution was from trying to remember which set of features I had available for each project. No, that's second - the biggest one was from arguments about when we should adopt a new version. But breaking working code pretty much didn't happen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Thu Oct 8 03:58:45 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 8 Oct 2015 16:58:45 +1300 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5613B14F.9070107@nottingham.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5613B14F.9070107@nottingham.ac.uk> Message-ID: <6E5715BB-FB3D-436D-A1A3-38EC72BA77D7@cs.otago.ac.nz> The change to make Monad a special case of Applicative has been a long time coming, and it has been a long time coming precisely because it's going to break things. I feel ambivalent about this. As soon as the question was raised, it was clear that it *would have been* nicer had Haskell been this way originally. I'm not looking forward to the consequences of the change. On 7/10/2015, at 12:32 am, Henrik Nilsson wrote: > While we can discuss the extent of additional breakage > MRP would cause, the fact remains it is a further > breaking change. A survey of breakage to books as > Herbert did is certainly valuable (thanks!), but > much breakage will (effectively) remain unquantifiable. This suggests one way in which one of the costs of the change could be reduced. Not just to survey the breakage, but to actually put revised material up on the Haskell.org web site, with a prominent link from the home page. From r.wobben at home.nl Thu Oct 8 05:03:48 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 8 Oct 2015 07:03:48 +0200 Subject: [Haskell-cafe] quickCheck problem In-Reply-To: References: <56142DE3.30604@home.nl> <561436B8.8090804@home.nl> Message-ID: <5615F934.1030705@home.nl> Op 8-10-2015 om 01:16 schreef Richard A. O'Keefe: > You can generate two unequal integers by doing > > prop_twoDifferent :: Int -> Int -> Bool > prop_twoDifferent x y = yourFn2 x y' > where y' = if y >= x then y+1 else y > > Letting the number of distinct Int values be N, > there are N*N pairs of Ints but only N*(N-1) pairs of > *different* Ints, so this technique will generate some > x y' pairs more often than others. In fact you will > get (x,minBound::Int) with probability 2/N and > (x,y>minBound) with probability 1/N. > The advantage of using a guard is that the probabilities > come out right (it's the "rejection method", in > statistical parlance). > > You can use that method to generate > x x y > x y x > y x x > > You can iterate the same idea to generate triples. > > > > ----- > Geen virus gevonden in dit bericht. > Gecontroleerd door AVG - www.avg.com > Versie: 2015.0.6140 / Virusdatabase: 4435/10775 - datum van uitgifte: 10/07/15 > > Thanks all. Enough to study and try. Roelof From ok at cs.otago.ac.nz Thu Oct 8 05:04:21 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 8 Oct 2015 18:04:21 +1300 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: <6405267D-7487-4793-8B0B-609E63740526@cs.otago.ac.nz> On 8/10/2015, at 12:39 pm, Mike Meyer wrote: > > I'm curious - do "practical" developers really feel like they have to rush out and update their tool chain whenever a new version of part of it comes out? Most of the projects I've worked on considered the language version as a fixed part of the technology stack, and almost never updated it. Even when using Python, which valued not breaking working code more than it's own zen. But changing anything that potentially affected all the code in a working project was pretty much never done, and always involved a lot of effort. My computer spends more of its time installing new versions of Java 1.8 than it does running Java. An application I found very useful stopped working when Java 1.6 went away, but Java 1.6 had to go away because of (in)security concerns. How anyone managed to write a program in Java 1.6 that would not run in 1.8 I hope never to know. (No, rebuilding from sources didn't work either. Tried that.) From tonymorris at gmail.com Thu Oct 8 05:25:56 2015 From: tonymorris at gmail.com (Tony Morris) Date: Thu, 8 Oct 2015 15:25:56 +1000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <6405267D-7487-4793-8B0B-609E63740526@cs.otago.ac.nz> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <6405267D-7487-4793-8B0B-609E63740526@cs.otago.ac.nz> Message-ID: <5615FE64.8060903@gmail.com> Java is not backward compatible, even between minor release. On 08/10/15 15:04, Richard A. O'Keefe wrote: > > On 8/10/2015, at 12:39 pm, Mike Meyer wrote: >> >> I'm curious - do "practical" developers really feel like they have to rush out and update their tool chain whenever a new version of part of it comes out? Most of the projects I've worked on considered the language version as a fixed part of the technology stack, and almost never updated it. Even when using Python, which valued not breaking working code more than it's own zen. But changing anything that potentially affected all the code in a working project was pretty much never done, and always involved a lot of effort. > > My computer spends more of its time installing new versions of Java 1.8 > than it does running Java. An application I found very useful stopped > working when Java 1.6 went away, but Java 1.6 had to go away because of > (in)security concerns. How anyone managed to write a program in Java > 1.6 that would not run in 1.8 I hope never to know. > > (No, rebuilding from sources didn't work either. Tried that.) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From rustompmody at gmail.com Thu Oct 8 07:01:16 2015 From: rustompmody at gmail.com (Rustom Mody) Date: Thu, 8 Oct 2015 12:31:16 +0530 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <3d672fd5db1546b189f16d2a890a953d@DB4PR30MB030.064d.mgd.msft.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <3d672fd5db1546b189f16d2a890a953d@DB4PR30MB030.064d.mgd.msft.net> Message-ID: *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On Behalf Of *Mike Meyer *Sent:* 07 October 2015 00:24 *To:* Mark Lentczner; Johan Tibell *Cc:* Haskell Libraries; haskell cafe; haskell-prime at haskell.org List *Subject:* Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner wrote: On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel wrote: TLDR: To complete the AMP, turn `Monad(return)` method into a top-level binding aliasing `Applicative(pure)`. Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't. A modest proposal: We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc. On Wed, Oct 7, 2015 at 9:06 PM, Simon Peyton Jones wrote: > I think there are several different conversations going on at once in this > thread. I think it?s worth keeping them separate. > > > > Returning to ?return?, my instinct is that when these pervasive breaking > library changes come up, we should batch them into larger clumps. The > ?treadmill? complaint is real: small change A made me re-release my > library; then small change B came along; and so on. Perhaps if we saved > them up this would be less of an issue, for two reasons. First, the work > happens once rather than many times. Second, the benefits of the change is > the sum of the benefits of the little component changes, and so is more > attractive to library authors and library clients. > > > > That line of thinking would suggest that the Core Libraries Committee > might want to maintain a list of well-worked out agreed changes that are > being ?saved up? for execution at some later date. > > > > Simon > > > This whole discussion is tilted towards the software engineering side. Of course from this side if someone keeps changing the underbelly in small but significant ways that has multiplicative effects on higher levels, people who have to manage the higher affected levels will protest. However I'd like to respectfully submit that the software engineering angle is not the only one; there's also the teaching angle. When the Haskell report first came out in 1990 this dual purpose was very clear in the first paras. Over years as Haskell has progressed from being an academic language to a 'Real World' one this balance has been lost. Whether Monads is really rocket science or its just ill-designed misnamed stuff that looks like a mess because no heavy duty vacuum cleaner has been applied, no one knows for sure because there's little pedagogic experience with any alternative 'cleaned out Haskell'. However this is just to point out that that possibility may be there. And from the pedagogic angle Haskell may be neat but functional programming is probably more significant and programming in general even more so. In this respect here are two posts: Functional Programming TimeLine: http://blog.languager.org/2015/04/cs-history-1.html and its sequel: http://blog.languager.org/2015/06/functional-programming-moving-target.html which is a more indepth analysis of FP in ACM curriculum 2013 and how pedagogic realities that were generally understood some decades ago have been increasingly forgotten today. For the specific case at hand -- return vs pure -- Ive no specific opinion However on a wider front, the confusion and frustration of the thousands of beginners who have to see the forbidding meaningless 'Functor' and 'Monad' instead of something more accessible like Mappable/Computational is IMHO a factor for Haskell not getting as much success as it should. Hopefully the community will take spj's call for significant batched-up changes seriously -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlang at delysid.org Thu Oct 8 08:21:25 2015 From: mlang at delysid.org (Mario Lang) Date: Thu, 08 Oct 2015 10:21:25 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: (=?utf-8?Q?=22Jos=C3=A9?= Manuel =?utf-8?Q?Calder=C3=B3n?= Trilla"'s message of "Tue, 6 Oct 2015 15:56:47 -0700") References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: <87lhbdzs6y.fsf@fx.delysid.org> Jos? Manuel Calder?n Trilla writes: > Many of us here learned from those texts or those courses. It's easy online > to say that materials being out of date isn't a big deal, but it can turn > people off the language when the code they paste into ghci doesn't > work. FWIW, I am a newbie, and currently learning a lot from the web. I've had a different feeling. Whenever I read something like "This is historical, and should have been fixed, but isn't yet", it were these sentences that almost turned me off the language, because I had a feeling that there is some stagnation going on. >From the POV of a newbie, I am all for fixing historical hickups. However, I realize that I have different priorities compared to long-time users and people needing to maintain a lot of existing code. Just my 0.01? -- CYa, ????? From tonymorris at gmail.com Thu Oct 8 08:52:19 2015 From: tonymorris at gmail.com (Tony Morris) Date: Thu, 8 Oct 2015 18:52:19 +1000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <87lhbdzs6y.fsf@fx.delysid.org> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <87lhbdzs6y.fsf@fx.delysid.org> Message-ID: <56162EC3.1020205@gmail.com> Many of my students are distracted by this too. This is why it is turned off and a practical type-class hierarchy is used to demonstrate concepts. As for use in production, it's been used for coming up to 10 years. I will wait. On 08/10/15 18:21, Mario Lang wrote: > Jos? Manuel Calder?n Trilla writes: > >> Many of us here learned from those texts or those courses. It's easy online >> to say that materials being out of date isn't a big deal, but it can turn >> people off the language when the code they paste into ghci doesn't >> work. > > FWIW, I am a newbie, and currently learning a lot from the web. > I've had a different feeling. Whenever I read something like "This is > historical, and should have been fixed, but isn't yet", it were these > sentences that almost turned me off the language, because I had a > feeling that there is some stagnation going on. > > From the POV of a newbie, I am all for fixing historical hickups. > However, I realize that I have different priorities compared to > long-time users and people needing to maintain a lot of existing code. > > Just my 0.01? > From _deepfire at feelingofgreen.ru Thu Oct 8 09:39:40 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Thu, 08 Oct 2015 12:39:40 +0300 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5615FE64.8060903@gmail.com> (sfid-20151008_094939_405258_6941E820) (Tony Morris's message of "Thu, 8 Oct 2015 15:25:56 +1000") References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <6405267D-7487-4793-8B0B-609E63740526@cs.otago.ac.nz> <5615FE64.8060903@gmail.com> Message-ID: <87wpuxog0z.fsf@feelingofgreen.ru> Tony Morris writes: > Java is not backward compatible, even between minor release. Is there an understanding of how they manage to qualify as an industrially-acceptable language in spite of this? -- ? ???????e? / respectfully, ??????? ?????? From tonymorris at gmail.com Thu Oct 8 09:41:47 2015 From: tonymorris at gmail.com (Tony Morris) Date: Thu, 8 Oct 2015 19:41:47 +1000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <87wpuxog0z.fsf@feelingofgreen.ru> References: <560E57D1.9060302@nottingham.ac.uk> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <6405267D-7487-4793-8B0B-609E63740526@cs.otago.ac.nz> <5615FE64.8060903@gmail.com> <87wpuxog0z.fsf@feelingofgreen.ru> Message-ID: <56163A5B.7080901@gmail.com> Successful marketing. On 08/10/15 19:39, Kosyrev Serge wrote: > Tony Morris writes: >> Java is not backward compatible, even between minor release. > > Is there an understanding of how they manage to qualify as an > industrially-acceptable language in spite of this? > From hvr at gnu.org Thu Oct 8 12:24:16 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 08 Oct 2015 14:24:16 +0200 Subject: [Haskell-cafe] status and future of haskell98 and haskell2010 packages In-Reply-To: <561597EB.8020906@gmail.com> (Andrey Chudnov's message of "Wed, 7 Oct 2015 18:08:43 -0400") References: <561597EB.8020906@gmail.com> Message-ID: <87egh57dlb.fsf@gnu.org> On 2015-10-08 at 00:08:43 +0200, Andrey Chudnov wrote: > My e-mail was rejected from libraries at haskell.org (the official > maintenance contact of the two packages in question), so I'm trying my > luck here instead. Hoping I can get some answers on the following > questions: > > 1. What is the status of `haskell2010` and `haskell98` packages? Are > they supported? Deprecated? In need of new maintainers? Short answer: with GHC 7.10 it is not possible anymore to implement a proper[1] `haskell98` or `haskell2010` package anymore. More details can be found at https://ghc.haskell.org/ticket/9590 > 2. Assuming the answer to the previous question is "alive and well", > are there any plans to release new versions of those for GHC 7.10 and > beyond? In order to be able to recover support for a `haskell2010` package in newer GHCs, GHC will need to be extended in some way. I can think of two different paths to pursue to accomplish this, depending on whether type(classes) need to be shared with `base` or not. Moreover, it wasn't clear how much actual demand there really is to have the recent GHCs support a legacy `haskell2010` mode. So if there's somebody interested in resuscitating a `haskell98`/`haskell2010` package, please tell us what your use-case is (to help understand whether type(class) sharing w/ `base` is essential or not -- it's *much* more easier to get this working w/o the typeclass sharing requirement, whereas the typeclass-sharing variant might not even be possible at all) Cheers, hvr [1]: I.e. with the requirement that all code written conforming to the respective Haskell Report will be compileable via e.g. ghc -XHaskell2010 -hide-all-packages -package haskell2010 -c *.hs (to some degree, this was already broken before GHC 7.10 due to the superclass-removal on `Num`, but with AMP this was broken beyond tolerance) From mike at proclivis.com Thu Oct 8 13:26:09 2015 From: mike at proclivis.com (Michael Jones) Date: Thu, 8 Oct 2015 07:26:09 -0600 Subject: [Haskell-cafe] Failing to catch exception Message-ID: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com> I?m having trouble with an exception that won?t catch and looking for suggestions. Basically, a ?fail? inside a ?catch? inside a unsafeIOToSTM, inside a wx callback, trying to catch SomeException or IOException. Details: I?m using Text.Regex.PCRE and the exception comes from a ?fail" in unwrap: unwrap :: (Show e) => Either e v -> IO v unwrap x = case x of Left err -> fail ("Text.Regex.PCRE.String died: "++ show err) Right v -> return v The catch is in this function, catching SomeException: filterTableRow _ record fils = do s <- showRecord record vs <- Control.Exception.catch ( return $ map (\(fil,col) -> let fil' = if fil == "" then "^" else fil in ((splitOn "," s)!!(fromIntegral (col+1))) =~ fil') (elems fils) ) ((\e -> do return $ replicate (length $ elems fils) False) :: SomeException -> IO [Bool]) return $ foldl (.&.) True vs filterTableRow is called from an unsafeIOToSTM: unsafeIOToSTM $ filterTableRow gridData row? fil which is called from a wx callback from a button press Before I added the catch, the application was working for over a year, so there is no general problem, All I added was the catch. Adding -xc to the ghc runtime shows the error: *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: Text.Regex.PCRE.String.matchTest, called from Text.Regex.PCRE.String.unwrap, ? user error (Text.Regex.PCRE.String died: (4,"unmatched parentheses")) Which indicates the text in unwrap, as if the exception is not caught. I have tried to catch it as IOException, and SomeException. Any ideas why it is not caught or some way to debug it? From hjgtuyl at chello.nl Thu Oct 8 13:35:16 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Thu, 08 Oct 2015 15:35:16 +0200 Subject: [Haskell-cafe] ANN: wxInstall Abriline and wxHaskell 0.92.1.0 Message-ID: L.S., I am happy to announce the installation packages for wxHaskell on Windows, and a new version of wxHaskell: 0.92.1.0 So far, the installation of wxHaskell on Windows has been difficult, but now it is just a matter of downloading an installation package[0][1], unzipping it to the directory where you want to have it installed, and clicking on Install.bat. A detailed description can be found at the wxHaskell-for-Windows homepage[2]. The current configuration of the installation packages (one package for 32 bit and one for 64 bit systems), is called Abriline and contains compiled wxWidgets 3.0.2 and all further necessary DLLs. The installation procedure automatically installs the latest version of wxHaskell and can be used for several of the most recent versions of GHC. In case you are wondering where the name Abriline comes from, it is generated by a girls name generator I wrote (in Haskell of course); I selected this name because a search on Internet seems to indicate that the name is brand new. The new version of wxHaskell is released because it solves a bug that could crash an application. What is wxHaskell? ------------------ wxHaskell[3] is a portable and native GUI library for Haskell. The goal of the project is to provide an industrial strength GUI library for Haskell, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore built on top of wxWidgets ? a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with the native look-and-feel. Links ----- See the homepage of wxHaskell for more information: https://wiki.haskell.org/WxHaskell The packages are: - wxc https://hackage.haskell.org/package/wxc - wxdirect https://hackage.haskell.org/package/wxdirect - wxcore https://hackage.haskell.org/package/wxcore - wx https://hackage.haskell.org/package/wx Regards, Henk-Jan van Tuyl [0] http://sourceforge.net/projects/wxhaskell/files/wxInstall/wxInstall-Abriline-32-0.1.zip/download [1] http://sourceforge.net/projects/wxhaskell/files/wxInstall/wxInstall-Abriline-64-0.1.zip/download [2] https://wiki.haskell.org/WxHaskell/Windows#Installing_the_easy_way [3] https://wiki.haskell.org/WxHaskell -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From hesselink at gmail.com Thu Oct 8 13:41:43 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 8 Oct 2015 15:41:43 +0200 Subject: [Haskell-cafe] Failing to catch exception In-Reply-To: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com> References: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com> Message-ID: Perhaps the value you're calculating is lazily computed, so the exception occurs only when using it, and by then you're already outside the catch? Try forcing things with `seq` or `deepseq` and see if that helps in catching the exception. Erik On 8 October 2015 at 15:26, Michael Jones wrote: > > I?m having trouble with an exception that won?t catch and looking for suggestions. Basically, a ?fail? inside a ?catch? inside a unsafeIOToSTM, inside a wx callback, trying to catch SomeException or IOException. > > Details: > > I?m using Text.Regex.PCRE > > and the exception comes from a ?fail" in unwrap: > > unwrap :: (Show e) => Either e v -> IO v > unwrap x = case x of Left err -> fail ("Text.Regex.PCRE.String died: "++ show err) > Right v -> return v > > The catch is in this function, catching SomeException: > > filterTableRow _ record fils = do > s <- showRecord record > vs <- Control.Exception.catch ( > return $ map (\(fil,col) -> let fil' = if fil == "" then "^" else fil in > ((splitOn "," s)!!(fromIntegral (col+1))) =~ fil') (elems fils) > ) > ((\e -> do return $ replicate (length $ elems fils) False) :: SomeException -> IO [Bool]) > return $ foldl (.&.) True vs > > filterTableRow is called from an unsafeIOToSTM: > > unsafeIOToSTM $ filterTableRow gridData row? fil > > which is called from a wx callback from a button press > > Before I added the catch, the application was working for over a year, so there is no general problem, All I added was the catch. > > Adding -xc to the ghc runtime shows the error: > > *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: > Text.Regex.PCRE.String.matchTest, > called from Text.Regex.PCRE.String.unwrap, > ? > user error (Text.Regex.PCRE.String died: (4,"unmatched parentheses")) > > > Which indicates the text in unwrap, as if the exception is not caught. I have tried to catch it as IOException, and SomeException. > > Any ideas why it is not caught or some way to debug it? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From alex323 at gmail.com Thu Oct 8 13:48:52 2015 From: alex323 at gmail.com (Alex) Date: Thu, 8 Oct 2015 09:48:52 -0400 Subject: [Haskell-cafe] Well-typed design issue Message-ID: <20151008094852.55a67308@gmail.com> Hello: I am implementing a high-level protocol which requires the use of various cryptographic primitives. I have the following goals in mind: 1. Allow others to extend the library to use different underlying crypto implementations, ciphers, curves, etc, and 2. Have the library be well-typed so that cryptographic operations are unambiguous, leading to code which can be easily audited. According to the spec, the user is allowed to instantiate the protocol with any combination of supported ciphers and curves, but the high-level operations always remain the same regardless of what primitives are used. Pursuant to the above goals, I've defined two typeclasses, "Cipher" and "Curve". I'm using TypeFamilies to facilitate the creation of data types that are independent of the underlying crypto library. The Cipher typeclass is as follows: class Cipher c where data Ciphertext c :: * data SymmetricKey c :: * data Nonce c :: * data Digest c :: * cipherName :: c -> ByteString cipherEncrypt :: SymmetricKey c -> Nonce c -> AssocData -> Plaintext -> Ciphertext c cipherDecrypt :: SymmetricKey c -> Nonce c -> AssocData -> Ciphertext c -> Maybe Plaintext cipherZeroNonce :: Nonce c cipherIncNonce :: Nonce c -> Nonce c cipherGetKey :: SymmetricKey c -> Nonce c -> SymmetricKey c cipherHashToKey :: Digest c -> SymmetricKey c cipherHashToAD :: Digest c -> AssocData cipherHash :: ScrubbedBytes -> Digest c cipherConcatHash :: Digest c -> ScrubbedBytes -> Digest c cipherHMAC :: SymmetricKey c -> ScrubbedBytes -> Digest c newtype Plaintext = Plaintext ScrubbedBytes newtype AssocData = AssocData ScrubbedBytes Unfortunately, the spec as written assumes that all variables are blobs of bytes. The issue I'm running in to is that, in my goal to have everything well-typed, my typeclasses are filling up with conversion functions like "cipherHashToKey" and "cipherHashToAD". These type conversions are necessary because I'm required to compute values like "HMAC-HASH(GETKEY(k, n), data)" (which returns "Digest c") and assign it to a variable whose type is "SymmetricKey c" (hence the need for cipherHashToKey). Is all my effort to write a well-typed library being done in vain? Should I just give up and have all the functions use ByteStrings? -- Alex From ben at smart-cactus.org Thu Oct 8 13:55:13 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 08 Oct 2015 15:55:13 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5615579D.5040900@orlitzky.com> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> Message-ID: <874mi15uta.fsf@smart-cactus.org> Michael Orlitzky writes: > (replying to no one in particular) > > This problem isn't specific to Haskell. In every other language, you > have projects that support major versions of toolkits, compilers, > libraries and whatnot. And there's already a tool for it: git. > > Instead of using #ifdef to handle four different compilers, keep a > branch for each. Git is designed to make this easy, and it's usually > trivial to merge changes from the master branch back into e.g. the > ghc-7.8 branch. That way the code in your master branch stays clean. > When you want to stop supporting an old GHC, delete that branch. > I don't find this option terribly appealing. As a maintainer I would far prefer maintaining a bit of CPP than a proliferation of branches, with all of the cherry-picking and potential code divergence that they bring. Really though, the point I've been trying to make throughout is that I think that much of the CPP that we are currently forced to endure isn't even strictly necessary. With a few changes to our treatment of warnings and some new pragmas (aimed at library authors), we can greatly reduce the impact that library interface changes have on users. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From eir at cis.upenn.edu Thu Oct 8 16:51:00 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 8 Oct 2015 12:51:00 -0400 Subject: [Haskell-cafe] Well-typed design issue In-Reply-To: <20151008094852.55a67308@gmail.com> References: <20151008094852.55a67308@gmail.com> Message-ID: What's going wrong? It looks like you're off to a solid start here. I don't know about these cryptographic primitives you speak of, but it sounds like the type conversion functions you're railing against are indeed necessary -- that is, they perform a runtime action. So where's the problem? Richly typed interfaces are sometimes more verbose (especially when you're just setting things up), but you're getting safety guarantees for that payment. Richard On Oct 8, 2015, at 9:48 AM, Alex wrote: > Hello: > > I am implementing a high-level protocol which requires the use of > various cryptographic primitives. I have the following goals in mind: > > 1. Allow others to extend the library to use different underlying > crypto implementations, ciphers, curves, etc, and > 2. Have the library be well-typed so that cryptographic operations are > unambiguous, leading to code which can be easily audited. > > According to the spec, the user is allowed to instantiate the protocol > with any combination of supported ciphers and curves, but the > high-level operations always remain the same regardless of what > primitives are used. > > Pursuant to the above goals, I've defined two typeclasses, "Cipher" and > "Curve". I'm using TypeFamilies to facilitate the creation of data > types that are independent of the underlying crypto library. > > The Cipher typeclass is as follows: > > class Cipher c > where > data Ciphertext c :: * > data SymmetricKey c :: * > data Nonce c :: * > data Digest c :: * > > cipherName :: c -> ByteString > cipherEncrypt :: SymmetricKey c -> Nonce c -> AssocData -> Plaintext -> Ciphertext c > cipherDecrypt :: SymmetricKey c -> Nonce c -> AssocData -> Ciphertext c -> Maybe Plaintext > cipherZeroNonce :: Nonce c > cipherIncNonce :: Nonce c -> Nonce c > cipherGetKey :: SymmetricKey c -> Nonce c -> SymmetricKey c > cipherHashToKey :: Digest c -> SymmetricKey c > cipherHashToAD :: Digest c -> AssocData > cipherHash :: ScrubbedBytes -> Digest c > cipherConcatHash :: Digest c -> ScrubbedBytes -> Digest c > cipherHMAC :: SymmetricKey c -> ScrubbedBytes -> Digest c > > newtype Plaintext = Plaintext ScrubbedBytes > newtype AssocData = AssocData ScrubbedBytes > > Unfortunately, the spec as written assumes that all variables are blobs > of bytes. The issue I'm running in to is that, in my goal to have > everything well-typed, my typeclasses are filling up with conversion > functions like "cipherHashToKey" and "cipherHashToAD". These type > conversions are necessary because I'm required to compute values like > "HMAC-HASH(GETKEY(k, n), data)" (which returns "Digest c") and assign > it to a variable whose type is "SymmetricKey c" (hence the need for > cipherHashToKey). > > Is all my effort to write a well-typed library being done in vain? > Should I just give up and have all the functions use ByteStrings? > > -- > Alex > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From alex323 at gmail.com Thu Oct 8 16:57:17 2015 From: alex323 at gmail.com (Alex) Date: Thu, 8 Oct 2015 12:57:17 -0400 Subject: [Haskell-cafe] Well-typed design issue In-Reply-To: References: <20151008094852.55a67308@gmail.com> Message-ID: <20151008125717.1c8c7d92@gmail.com> On Thu, 8 Oct 2015 12:51:00 -0400 Richard Eisenberg wrote: > What's going wrong? It looks like you're off to a solid start here. > > I don't know about these cryptographic primitives you speak of, but > it sounds like the type conversion functions you're railing against > are indeed necessary -- that is, they perform a runtime action. So > where's the problem? Richly typed interfaces are sometimes more > verbose (especially when you're just setting things up), but you're > getting safety guarantees for that payment. > > Richard > After a discussion with Cale in #haskell, I've been convinced of the point that you're making. The reason I was feeling uneasy was because I incorrectly equated verbosity to inelegance. -- Alex From eir at cis.upenn.edu Thu Oct 8 17:05:24 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 8 Oct 2015 13:05:24 -0400 Subject: [Haskell-cafe] Support for library improvement In-Reply-To: <874mi15uta.fsf@smart-cactus.org> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> Message-ID: <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu> On Oct 8, 2015, at 9:55 AM, Ben Gamari wrote: > With a few changes to our treatment of warnings > and some new pragmas (aimed at library authors), we can greatly reduce > the impact that library interface changes have on users. My loose following of the interweaved threads has led me to this same conclusion. Have you paid close enough attention to list exactly what these changes should be? I have not. But I'd love to find a general solution to the migration problem so that we can continue to tinker with our beloved language without fear of flames burning down the house. Richard From mike at proclivis.com Thu Oct 8 17:14:18 2015 From: mike at proclivis.com (Michael Jones) Date: Thu, 8 Oct 2015 11:14:18 -0600 Subject: [Haskell-cafe] Failing to catch exception In-Reply-To: References: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com> Message-ID: <690B3420-3146-4D1D-9800-F72443356D58@proclivis.com> Erik, deepseq was the trick. It was not front of mind that a catch would not enforce evaluation, as it ?naturally" is supposed to catch. Retuned my intuition :-) Mike > On Oct 8, 2015, at 7:41 AM, Erik Hesselink wrote: > > Perhaps the value you're calculating is lazily computed, so the > exception occurs only when using it, and by then you're already > outside the catch? Try forcing things with `seq` or `deepseq` and see > if that helps in catching the exception. > > Erik > > On 8 October 2015 at 15:26, Michael Jones wrote: >> >> I?m having trouble with an exception that won?t catch and looking for suggestions. Basically, a ?fail? inside a ?catch? inside a unsafeIOToSTM, inside a wx callback, trying to catch SomeException or IOException. >> >> Details: >> >> I?m using Text.Regex.PCRE >> >> and the exception comes from a ?fail" in unwrap: >> >> unwrap :: (Show e) => Either e v -> IO v >> unwrap x = case x of Left err -> fail ("Text.Regex.PCRE.String died: "++ show err) >> Right v -> return v >> >> The catch is in this function, catching SomeException: >> >> filterTableRow _ record fils = do >> s <- showRecord record >> vs <- Control.Exception.catch ( >> return $ map (\(fil,col) -> let fil' = if fil == "" then "^" else fil in >> ((splitOn "," s)!!(fromIntegral (col+1))) =~ fil') (elems fils) >> ) >> ((\e -> do return $ replicate (length $ elems fils) False) :: SomeException -> IO [Bool]) >> return $ foldl (.&.) True vs >> >> filterTableRow is called from an unsafeIOToSTM: >> >> unsafeIOToSTM $ filterTableRow gridData row? fil >> >> which is called from a wx callback from a button press >> >> Before I added the catch, the application was working for over a year, so there is no general problem, All I added was the catch. >> >> Adding -xc to the ghc runtime shows the error: >> >> *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: >> Text.Regex.PCRE.String.matchTest, >> called from Text.Regex.PCRE.String.unwrap, >> ? >> user error (Text.Regex.PCRE.String died: (4,"unmatched parentheses")) >> >> >> Which indicates the text in unwrap, as if the exception is not caught. I have tried to catch it as IOException, and SomeException. >> >> Any ideas why it is not caught or some way to debug it? >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From mike at proclivis.com Thu Oct 8 17:22:18 2015 From: mike at proclivis.com (Michael Jones) Date: Thu, 8 Oct 2015 11:22:18 -0600 Subject: [Haskell-cafe] Failing to catch exception In-Reply-To: References: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com> Message-ID: <48338709-4FF7-47E5-98A3-6FF6786ADF31@proclivis.com> Erik, Ok, I need some conceptual help on this one. If the action ?in" the catch is not evaluated, I would think the catch itself cannot be fully evaluated. Once IO demands the value from the work ?in? the catch, how can it escape the catch? To me it seemed like the exception triggered the death of the wx callback without an evaluation of the catch, like the runtime let it escape. Mike > On Oct 8, 2015, at 7:41 AM, Erik Hesselink wrote: > > Perhaps the value you're calculating is lazily computed, so the > exception occurs only when using it, and by then you're already > outside the catch? Try forcing things with `seq` or `deepseq` and see > if that helps in catching the exception. > > Erik > > On 8 October 2015 at 15:26, Michael Jones wrote: >> >> I?m having trouble with an exception that won?t catch and looking for suggestions. Basically, a ?fail? inside a ?catch? inside a unsafeIOToSTM, inside a wx callback, trying to catch SomeException or IOException. >> >> Details: >> >> I?m using Text.Regex.PCRE >> >> and the exception comes from a ?fail" in unwrap: >> >> unwrap :: (Show e) => Either e v -> IO v >> unwrap x = case x of Left err -> fail ("Text.Regex.PCRE.String died: "++ show err) >> Right v -> return v >> >> The catch is in this function, catching SomeException: >> >> filterTableRow _ record fils = do >> s <- showRecord record >> vs <- Control.Exception.catch ( >> return $ map (\(fil,col) -> let fil' = if fil == "" then "^" else fil in >> ((splitOn "," s)!!(fromIntegral (col+1))) =~ fil') (elems fils) >> ) >> ((\e -> do return $ replicate (length $ elems fils) False) :: SomeException -> IO [Bool]) >> return $ foldl (.&.) True vs >> >> filterTableRow is called from an unsafeIOToSTM: >> >> unsafeIOToSTM $ filterTableRow gridData row? fil >> >> which is called from a wx callback from a button press >> >> Before I added the catch, the application was working for over a year, so there is no general problem, All I added was the catch. >> >> Adding -xc to the ghc runtime shows the error: >> >> *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: >> Text.Regex.PCRE.String.matchTest, >> called from Text.Regex.PCRE.String.unwrap, >> ? >> user error (Text.Regex.PCRE.String died: (4,"unmatched parentheses")) >> >> >> Which indicates the text in unwrap, as if the exception is not caught. I have tried to catch it as IOException, and SomeException. >> >> Any ideas why it is not caught or some way to debug it? >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From mike at proclivis.com Thu Oct 8 17:55:15 2015 From: mike at proclivis.com (Michael Jones) Date: Thu, 8 Oct 2015 11:55:15 -0600 Subject: [Haskell-cafe] Failing to catch exception In-Reply-To: <48338709-4FF7-47E5-98A3-6FF6786ADF31@proclivis.com> References: <305E198E-C7A6-4D29-8E5C-A54334C631D6@proclivis.com> <48338709-4FF7-47E5-98A3-6FF6786ADF31@proclivis.com> Message-ID: This was in a draft that got sent by accident. No help needed. I understand why deepseq fixes the problem. > On Oct 8, 2015, at 11:22 AM, Michael Jones wrote: > > Erik, > > Ok, I need some conceptual help on this one. If the action ?in" the catch is not evaluated, I would think the catch itself cannot be fully evaluated. Once IO demands the value from the work ?in? the catch, how can it escape the catch? > > To me it seemed like the exception triggered the death of the wx callback without an evaluation of the catch, like the runtime let it escape. > > Mike > From mail at joachim-breitner.de Thu Oct 8 18:05:43 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 08 Oct 2015 20:05:43 +0200 Subject: [Haskell-cafe] Support for library improvement In-Reply-To: <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu> Message-ID: <1444327543.21428.6.camel@joachim-breitner.de> Hi, Am Donnerstag, den 08.10.2015, 13:05 -0400 schrieb Richard Eisenberg: > On Oct 8, 2015, at 9:55 AM, Ben Gamari wrote: > > With a few changes to our treatment of warnings > > and some new pragmas (aimed at library authors), we can greatly > > reduce > > the impact that library interface changes have on users. > > My loose following of the interweaved threads has led me to this same > conclusion. Have you paid close enough attention to list exactly what > these changes should be? I have not. But I'd love to find a general > solution to the migration problem so that we can continue to tinker > with our beloved language without fear of flames burning down the > house. how willing are we to make the compiler smarter and more complicate to make sure old code does what it originally meant to do, as long as it is among the (large number close to 100)% common case? For example, in this case (as was suggested in some trac ticket, I believe), ignore a method definition for a method that * is no longer in the class and * where a normal function is in scope and * these are obvious equivalent where obvious may mean various things, depending on our needs. One could think this further: If the compiler sees a set of Applicative and Monad instances for the same type in the same module, and it has "return = something useful" and "pure = return", can?t it just do what we expect everyone to do manually and change that to "pure = something useful" and remove return? In other words, can we replace pain and hassle for a lot of people by implementation work (and future maintenance cost) for one or a few people? Or will that lead to another hell where code does no longer mean what it says? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From nicola.gigante at gmail.com Thu Oct 8 18:24:28 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Thu, 8 Oct 2015 20:24:28 +0200 Subject: [Haskell-cafe] Interfacing with the GHC runtime from a library Message-ID: <2D70B8F4-55AD-46ED-84BF-EA942A2DAD03@gmail.com> Hi everybody, suppose to have an Haskell library which is in part implemented in C for whatever reason. Can the C part talk with the runtime, in particular the scheduler? In other words, does the runtime expose the functionality needed to implement, for example, the STM library from outside the GHC runtime itself? Thank you, Nicola From defigueiredo at ucdavis.edu Thu Oct 8 18:32:13 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Thu, 8 Oct 2015 12:32:13 -0600 Subject: [Haskell-cafe] Well-typed design issue In-Reply-To: <20151008094852.55a67308@gmail.com> References: <20151008094852.55a67308@gmail.com> Message-ID: <5616B6AD.5060504@ucdavis.edu> The cryptographic building blocks we use every day (e.g. blockciphers, symmetric encryption schemes, message authentication schemes, etc) have been formalized. I suggest the library follows the mathematical notions. A good place to see the definitions of the cryptographic building blocks are Phil Rogaway's lecture notes [1]. For example, there are 2 types of ciphers: blockciphers and streamciphers. A blockcipher is family of permutations, but a cipher is a distinct thing from a symmetric encryption scheme. I would say they have different types. You can build a symmetric encryption scheme using: 1. a blockcipher; 2. a mode of operation (such as Cipher-Block-Chaining, a.k.a CBC); and, 3. a random number (a nonce). Blockciphers are also distinct from message authentication schemes. The most famous message authentication scheme is HMAC. It can use a variety of underlying hash functions (such as SHA1, SHA256, etc). With this in mind, I find it that the classes you propose should separate the concepts as they have been formalized. Here's a first rough pass at a reorg: class SymEncryptionScheme c where data Ciphertext c :: * data SymmetricKey c :: * data Nonce c :: * data Plaintext c :: * KeyGenerationAlgo :: Int -> IO (SymmetricKey c) -- this is necessarily probabilistic EncryptionAlgo :: Nonce c -> SymmetricKey c -> Plaintext c -> Ciphertext c DecryptionAlgo :: SymmetricKey c -> Ciphertext c -> Plaintext c class Blockcipher c where data PlaintextBlock c :: * data CiphertextBlock c :: * data SymmetricKey c :: * blockSize :: c -> Int encipher :: SymmetricKey c -> PlaintextBlock c -> CiphertextBlock c decipher :: SymmetricKey c -> CiphertextBlock c -> PlaintextBlock c class MAC c where data Plaintext c :: * data MessageDigest c :: * data SymmetricKey c :: * HashFunction :: Plaintext c -> MessageDigest c mac :: SymmetricKey c -> Plaintext c -> MessageDigest c class HashFunction f where data inputBlock f :: * data ouputBlock f :: * compressionFunction :: inputBlock f -> inputBlock f -> ouputBlock f padding :: ... hash :: ... I think it is a great idea to use the types to makes sure those building blocks are assembled together in ways that make sense. I have a feeling constraints will come in handy. Hope this helps, Dimitri [1] http://cseweb.ucsd.edu/~mihir/cse207/classnotes.html On 10/8/15 7:48 AM, Alex wrote: > Hello: > > I am implementing a high-level protocol which requires the use of > various cryptographic primitives. I have the following goals in mind: > > 1. Allow others to extend the library to use different underlying > crypto implementations, ciphers, curves, etc, and > 2. Have the library be well-typed so that cryptographic operations are > unambiguous, leading to code which can be easily audited. > > According to the spec, the user is allowed to instantiate the protocol > with any combination of supported ciphers and curves, but the > high-level operations always remain the same regardless of what > primitives are used. > > Pursuant to the above goals, I've defined two typeclasses, "Cipher" and > "Curve". I'm using TypeFamilies to facilitate the creation of data > types that are independent of the underlying crypto library. > > The Cipher typeclass is as follows: > > class Cipher c > where > data Ciphertext c :: * > data SymmetricKey c :: * > data Nonce c :: * > data Digest c :: * > > cipherName :: c -> ByteString > cipherEncrypt :: SymmetricKey c -> Nonce c -> AssocData -> Plaintext -> Ciphertext c > cipherDecrypt :: SymmetricKey c -> Nonce c -> AssocData -> Ciphertext c -> Maybe Plaintext > cipherZeroNonce :: Nonce c > cipherIncNonce :: Nonce c -> Nonce c > cipherGetKey :: SymmetricKey c -> Nonce c -> SymmetricKey c > cipherHashToKey :: Digest c -> SymmetricKey c > cipherHashToAD :: Digest c -> AssocData > cipherHash :: ScrubbedBytes -> Digest c > cipherConcatHash :: Digest c -> ScrubbedBytes -> Digest c > cipherHMAC :: SymmetricKey c -> ScrubbedBytes -> Digest c > > newtype Plaintext = Plaintext ScrubbedBytes > newtype AssocData = AssocData ScrubbedBytes > > Unfortunately, the spec as written assumes that all variables are blobs > of bytes. The issue I'm running in to is that, in my goal to have > everything well-typed, my typeclasses are filling up with conversion > functions like "cipherHashToKey" and "cipherHashToAD". These type > conversions are necessary because I'm required to compute values like > "HMAC-HASH(GETKEY(k, n), data)" (which returns "Digest c") and assign > it to a variable whose type is "SymmetricKey c" (hence the need for > cipherHashToKey). > > Is all my effort to write a well-typed library being done in vain? > Should I just give up and have all the functions use ByteStrings? > From michael at orlitzky.com Thu Oct 8 18:52:58 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Thu, 8 Oct 2015 14:52:58 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <874mi15uta.fsf@smart-cactus.org> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> Message-ID: <5616BB8A.1080807@orlitzky.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/08/2015 09:55 AM, Ben Gamari wrote: > Michael Orlitzky writes: > >> (replying to no one in particular) >> >> This problem isn't specific to Haskell. In every other language, >> you have projects that support major versions of toolkits, >> compilers, libraries and whatnot. And there's already a tool for >> it: git. >> >> Instead of using #ifdef to handle four different compilers, keep >> a branch for each. Git is designed to make this easy, and it's >> usually trivial to merge changes from the master branch back into >> e.g. the ghc-7.8 branch. That way the code in your master branch >> stays clean. When you want to stop supporting an old GHC, delete >> that branch. >> > I don't find this option terribly appealing. As a maintainer I > would far prefer maintaining a bit of CPP than a proliferation of > branches, with all of the cherry-picking and potential code > divergence that they bring. It's really not that bad. You only need a separate branch when things are actually incompatible, so while you may support four versions of GHC, you might only need two branches. And the difference between the branches should be exactly what you have wrapped in an #ifdef right now: a) If you're modifying something in an #ifdef, then the change only goes in one branch, and you don't have to cherry-pick anything. b) If the change wouldn't fall within an #ifdef, then it affects code common to all your branches, and the merge will be trivial. It's annoying to have to do that for every change, so don't. Keep a pile of common changes in your master branch, and then rebase/merge the other branches right before you make a release. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJWFruJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxNEU5RDcyRDdCMUFGREVGQzBCNDFDMUY2 RjQ4RDNEQTA1QzJEQURCAAoJEG9I09oFwtrbPB0P/37UFFBHqgN/Pspr26bdK4Hp j5TdF5RqP8BeiBg/shJyc1xrq4uB2wQZfrExCwfXssJYz+/Cuiw77MSYkay/ks3s LemyT6wIAypmjDOKHwzXw9mWU7oS9iL3CSPvZB07HLB4JNHpzBC0hAx3ZuMucyg7 xWFWgmlR5i1k069OCs+dgkfXotyt0zGtt17pw8YbX3X29/SOy9Y4K3+L6kfV8pOW dN/3/DIDakBDfLLLJG/pc57xq5GnTd77sCLNHrheWkybB3leW9t00Zq4erjBDyWt O7eO1jjTHoTo/S1iDWYGiy6zPI1dI+jDowUDLrZfIeAURw81ymqbfQlujwqoLB4j kWnaBDpT5JDhKZ3ZMWOcPtCGlUGbXIYh986s22jXfRhvO0dFNwwhbQOQdQMEUN74 XCggw4APIAHnA7lfg2s33bVOJr/d8XumnOCHD+7IEWYc+25lDWr42Ens7LOVJzv1 COh3JKAPbbWFpwmU2yKdowomiZglNZj9QW27e7x33ZU0rLITS2CdV/zmY5TLqf4S v40jJcQMt2ZSCW0X8HBpHdGG6tQxUWcYZR8kpbxoaoQgwwqYa+vN0aXyMd5tG3Bp cHyTDfya+Kt6lVa23kvs2YPXjUAXvSnoSBL646gpYvRvrx6L+T7Dd9UUNFGNg+8k +Dw1hH2mSYJ852ZreY9e =qH2g -----END PGP SIGNATURE----- From josh3light at gmail.com Thu Oct 8 19:10:57 2015 From: josh3light at gmail.com (Joshua Jordan) Date: Thu, 8 Oct 2015 15:10:57 -0400 Subject: [Haskell-cafe] minimizing overhead between c/c++ and Haskell Message-ID: I've been learning Haskell recently and I'm interested in exploring whether something I have in mind is feasible. I have several projects similar to the one below, this is just one example: I have written a plug-in for an existing software (which manages it's own threading, memory, etc). The plug-in interface is in c++ and is wrapped in an extern c call for the final connection to the software. The actual plugin is rather functional in nature, and at its core simply accepts float, int, and string values, does a certain amount of internal processing based on input criteria, and returns float values as a result. I'd like to re-factor it one day, so instead of doing it in c++, it would be interesting to rewrite my plug-in with the logic and structure (with memoization, etc) of the internal processing in Haskell, which is called from the other executable. The processing will be called by the c/c++ threads many millions of times in one run, so perhaps the overhead of separate processes and interprocess communication would be too great, and I'd hope for minimal time overhead between the c/c++ and Haskell calls. I imagine the process might go something like this, after looking over the documentation (Using the FFI with GHC): ------------------------------ -------- -the c/c++ plug-in initializes the GHC runtime in a set-up step -- begin call: repeated many millions of times -the c/c++ threads call the haskell function -the haskell function returns a value to the c/c++ threads -- end calls -after everything is finished, the c/c++ plug-in uninitializes the GHC runtime -------------------------------------- So before attempting this, my questions would be: 1) What do you guys think the overhead in this situation would be? 2) Would you suggest exploring anything besides what I've mentioned, and am I missing anything? -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidleothomas at gmail.com Thu Oct 8 21:12:41 2015 From: davidleothomas at gmail.com (David Thomas) Date: Thu, 8 Oct 2015 14:12:41 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5616BB8A.1080807@orlitzky.com> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> Message-ID: Right. With a nest of #ifdefs, you still have the same number of branches (at least - there may be some combinations of options that you don't support and it won't be obvious), they're just implicit and harder to work with. On Thu, Oct 8, 2015 at 11:52 AM, Michael Orlitzky wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 10/08/2015 09:55 AM, Ben Gamari wrote: >> Michael Orlitzky writes: >> >>> (replying to no one in particular) >>> >>> This problem isn't specific to Haskell. In every other language, >>> you have projects that support major versions of toolkits, >>> compilers, libraries and whatnot. And there's already a tool for >>> it: git. >>> >>> Instead of using #ifdef to handle four different compilers, keep >>> a branch for each. Git is designed to make this easy, and it's >>> usually trivial to merge changes from the master branch back into >>> e.g. the ghc-7.8 branch. That way the code in your master branch >>> stays clean. When you want to stop supporting an old GHC, delete >>> that branch. >>> >> I don't find this option terribly appealing. As a maintainer I >> would far prefer maintaining a bit of CPP than a proliferation of >> branches, with all of the cherry-picking and potential code >> divergence that they bring. > > It's really not that bad. You only need a separate branch when things > are actually incompatible, so while you may support four versions of > GHC, you might only need two branches. > > And the difference between the branches should be exactly what you > have wrapped in an #ifdef right now: > > a) If you're modifying something in an #ifdef, then the change only > goes in one branch, and you don't have to cherry-pick anything. > > b) If the change wouldn't fall within an #ifdef, then it affects code > common to all your branches, and the merge will be trivial. > > It's annoying to have to do that for every change, so don't. Keep a > pile of common changes in your master branch, and then rebase/merge > the other branches right before you make a release. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0 > > iQJ8BAEBCgBmBQJWFruJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxNEU5RDcyRDdCMUFGREVGQzBCNDFDMUY2 > RjQ4RDNEQTA1QzJEQURCAAoJEG9I09oFwtrbPB0P/37UFFBHqgN/Pspr26bdK4Hp > j5TdF5RqP8BeiBg/shJyc1xrq4uB2wQZfrExCwfXssJYz+/Cuiw77MSYkay/ks3s > LemyT6wIAypmjDOKHwzXw9mWU7oS9iL3CSPvZB07HLB4JNHpzBC0hAx3ZuMucyg7 > xWFWgmlR5i1k069OCs+dgkfXotyt0zGtt17pw8YbX3X29/SOy9Y4K3+L6kfV8pOW > dN/3/DIDakBDfLLLJG/pc57xq5GnTd77sCLNHrheWkybB3leW9t00Zq4erjBDyWt > O7eO1jjTHoTo/S1iDWYGiy6zPI1dI+jDowUDLrZfIeAURw81ymqbfQlujwqoLB4j > kWnaBDpT5JDhKZ3ZMWOcPtCGlUGbXIYh986s22jXfRhvO0dFNwwhbQOQdQMEUN74 > XCggw4APIAHnA7lfg2s33bVOJr/d8XumnOCHD+7IEWYc+25lDWr42Ens7LOVJzv1 > COh3JKAPbbWFpwmU2yKdowomiZglNZj9QW27e7x33ZU0rLITS2CdV/zmY5TLqf4S > v40jJcQMt2ZSCW0X8HBpHdGG6tQxUWcYZR8kpbxoaoQgwwqYa+vN0aXyMd5tG3Bp > cHyTDfya+Kt6lVa23kvs2YPXjUAXvSnoSBL646gpYvRvrx6L+T7Dd9UUNFGNg+8k > +Dw1hH2mSYJ852ZreY9e > =qH2g > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From taruti at taruti.net Thu Oct 8 22:05:34 2015 From: taruti at taruti.net (Taru Karttunen) Date: Fri, 9 Oct 2015 01:05:34 +0300 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> Message-ID: <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> On 08.10 14:12, David Thomas wrote: > Right. With a nest of #ifdefs, you still have the same number of > branches (at least - there may be some combinations of options that > you don't support and it won't be obvious), they're just implicit and > harder to work with. Have you got an example of a library that works with branches for GHC-versions while maintaining feature-parity across branches with a versioning scheme that works in practice with Hackage? - Taru Karttunen From hyarion at iinet.net.au Thu Oct 8 22:32:32 2015 From: hyarion at iinet.net.au (Ben) Date: Fri, 09 Oct 2015 09:32:32 +1100 Subject: [Haskell-cafe] Support for library improvement In-Reply-To: <1444327543.21428.6.camel@joachim-breitner.de> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu> <1444327543.21428.6.camel@joachim-breitner.de> Message-ID: <2602C21F-2BF5-4D93-A136-002561F8BC1B@iinet.net.au> I like the idea of a separate translator that understands how to make the obvious changes required by such minor improvements (remove/add definitions of return, remove/add imports of Applicative, etc), and having that applied by cabal when the code is built. Then library authors could write normal code conforming to *one* release, instead of figuring out the clever import gymnastics or CPP required to code simultaneously against several almost-compatible interfaces (or forking). Some meta data in a cabal file could hopefully be all you need to allow your code to be adjustible forward or backward a few dialects. On 9 October 2015 5:05:43 am AEDT, Joachim Breitner wrote: >Hi, > >Am Donnerstag, den 08.10.2015, 13:05 -0400 schrieb Richard Eisenberg: >> On Oct 8, 2015, at 9:55 AM, Ben Gamari wrote: >> > With a few changes to our treatment of warnings >> > and some new pragmas (aimed at library authors), we can greatly >> > reduce >> > the impact that library interface changes have on users. >> >> My loose following of the interweaved threads has led me to this same > >> conclusion. Have you paid close enough attention to list exactly what > >> these changes should be? I have not. But I'd love to find a general >> solution to the migration problem so that we can continue to tinker >> with our beloved language without fear of flames burning down the >> house. > >how willing are we to make the compiler smarter and more complicate to >make sure old code does what it originally meant to do, as long as it >is among the (large number close to 100)% common case? > >For example, in this case (as was suggested in some trac ticket, I >believe), ignore a method definition for a method that > * is no longer in the class and > * where a normal function is in scope and > * these are obvious equivalent >where obvious may mean various things, depending on our needs. > >One could think this further: If the compiler sees a set of Applicative >and Monad instances for the same type in the same module, and it has >"return = something useful" and "pure = return", can?t it just do what >we expect everyone to do manually and change that to "pure = something >useful" and remove return? > >In other words, can we replace pain and hassle for a lot of people by >implementation work (and future maintenance cost) for one or a few >people? > >Or will that lead to another hell where code does no longer mean what >it says? > >Greetings, >Joachim > >-- >Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > >------------------------------------------------------------------------ > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidleothomas at gmail.com Fri Oct 9 00:34:03 2015 From: davidleothomas at gmail.com (David Thomas) Date: Thu, 8 Oct 2015 17:34:03 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> References: <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> Message-ID: No, and I'm not sure just how well existing Hackage tooling/process matches the workflow (due mostly to ignorance of existing Hackage tooling/process). To the degree that there's a mismatch, it may have reason sufficient to abandon the approach - or it may suggest improvements to tooling/process. On Thu, Oct 8, 2015 at 3:05 PM, Taru Karttunen wrote: > On 08.10 14:12, David Thomas wrote: >> Right. With a nest of #ifdefs, you still have the same number of >> branches (at least - there may be some combinations of options that >> you don't support and it won't be obvious), they're just implicit and >> harder to work with. > > Have you got an example of a library that works with branches > for GHC-versions while maintaining feature-parity across > branches with a versioning scheme that works in practice with > Hackage? > > - Taru Karttunen From ok at cs.otago.ac.nz Fri Oct 9 00:36:27 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 9 Oct 2015 13:36:27 +1300 Subject: [Haskell-cafe] Support for library improvement In-Reply-To: <1444327543.21428.6.camel@joachim-breitner.de> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu> <1444327543.21428.6.camel@joachim-breitner.de> Message-ID: <02340601-50A8-4017-94C8-84D9DFC854CC@cs.otago.ac.nz> On 9/10/2015, at 7:05 am, Joachim Breitner wrote: > For example, in this case (as was suggested in some trac ticket, I > believe), ignore a method definition for a method that > * is no longer in the class and > * where a normal function is in scope and > * these are obvious equivalent > where obvious may mean various things, depending on our needs. > ... > Or will that lead to another hell where code does no longer mean what > it says? One help for avoiding that hell is for the compiler never to deviate from the apparent semantics of the code without SHOUTING about what it's doing. There is also a big difference between the compiler adapting code written for an old interface and tampering with code written for a new interface, even if both involve the same actions on the compiler's part. The former may be helpful, the latter not. I have long felt that version and dependency information should be in a source file. Arguably, the various language pragmas sort of do that for *language* aspects. When the compiler *knows* what language version a module was written for and which library versions, there are many possibilities: - refuse to compile code that's too old - quietly compile the code under the old rules - noisily compile the code under the old rules - quietly adapt the code to the new rules - noisily adapt the code to the new rules Speaking only for myself, dealing with the change in my own code is not going to be a big deal, because it affects the monads I *define*, not the monads I *use*. The main thing I need is very clear warning messages from the compiler. From eir at cis.upenn.edu Fri Oct 9 01:31:38 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 8 Oct 2015 21:31:38 -0400 Subject: [Haskell-cafe] Support for library improvement In-Reply-To: <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu> References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu> Message-ID: On Oct 8, 2015, at 1:05 PM, Richard Eisenberg wrote: > > My loose following of the interweaved threads has led me to this same conclusion. Have you paid close enough attention to list exactly what these changes should be? I have not. But I'd love to find a general solution to the migration problem so that we can continue to tinker with our beloved language without fear of flames burning down the house. I should have been more explicit. I was more thinking of a multi-tiered warning system, where we decide, as a community, not to be embarrassed by warnings of severity less than X. When putting a DEPRECATED pragma on a definition, we could then give an indication of how soon we expect the definition to be gone. I was not thinking of the sort of "smart" behavior that Joachim wrote about. I want my programs to do exactly what I say -- compilers should only be so clever. Richard From ok at cs.otago.ac.nz Fri Oct 9 03:10:24 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 9 Oct 2015 16:10:24 +1300 Subject: [Haskell-cafe] Monad of no `return` Proposal In-Reply-To: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU> References: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU> Message-ID: On 6/10/2015, at 11:59 am, Doug McIlroy wrote: > > Another trick is to use plain if rather than #if or #ifdef, > and let the compiler optimize away the unwanted side of the > branch. The University of Edinburgh had their own systems implementation language, IMP. Fortran -> Algol 60 -> Atlas Autocode -> IMP. It was no surprise to find that %if %then %else eliminated whichever branch would not be executed. But it was astonishing to discover that %if %then %start %finish %else %start %finish would only process the declarations in the chosen part. If you want to eliminate the preprocessor, you have got to handle conditional declarations. Even IMP did not handle %record %format table ( ... %if keeping statistics %then %start %integer accesses, hits, misses, %endif ...) which is something that a preprocessor can handle. From ok at cs.otago.ac.nz Fri Oct 9 03:18:19 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 9 Oct 2015 16:18:19 +1300 Subject: [Haskell-cafe] Monad of no `return` Proposal In-Reply-To: <87lhbgl5lb.fsf@feelingofgreen.ru> References: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU> <87lhbgl5lb.fsf@feelingofgreen.ru> Message-ID: <2053594A-C0F7-4A45-B794-7654C12E7342@cs.otago.ac.nz> On 6/10/2015, at 10:16 pm, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote: > As an example of the opposite end, consider Common Lisp, which: > > 1. reifies READ as the third processing phase (macroexpansion[1] and actual > compilation being the other two) > 2. operates at expression granularity > 3. makes the full power of the language available to support the > decision process of what subexpressions are available in which > contexts Except that the syntax for conditional reading in Common Lisp, #+ #- (a) is utterly different from conditional evaluation, like (if ). (b) does NOT make the full power of the language available. The feature test is a Boolean combination, using and, or, not of atoms, where the value of an atom is true iff it is a member of *features* (the asterisks are part of the name). From trupill at gmail.com Fri Oct 9 06:57:57 2015 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 9 Oct 2015 08:57:57 +0200 Subject: [Haskell-cafe] Support for library improvement In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <069629CD-C350-4B75-A6AB-CC98404A8039@cis.upenn.edu> Message-ID: I would like to throw something to the discussion. In UHC's build system a tool called Shuffle is used: http://foswiki.cs.uu.nl/foswiki/Ehc/ShuffleDocumentation It has three nice properties which I think could fit well with the problem: - You can define variants of code with given numbers and names, and then ask the tool to produce the output file. Something a bit better than CPP itself. - It understands some Haskell semantics. In particular, you can state functions imported or exported by each chunk (see http://foswiki.cs.uu.nl/foswiki/Ehc/ShuffleDocumentation#A_1.2_Output_specific_configuration) and the tool takes care of building up the module declaration on top of the file. - It ships with a hook to integrate with Cabal ( https://hackage.haskell.org/package/shuffle-0.1.3.3/docs/Distribution-Simple-Shuffle.html ). Just my two cents. 2015-10-09 3:31 GMT+02:00 Richard Eisenberg : > > > On Oct 8, 2015, at 1:05 PM, Richard Eisenberg wrote: > > > > My loose following of the interweaved threads has led me to this same > conclusion. Have you paid close enough attention to list exactly what these > changes should be? I have not. But I'd love to find a general solution to > the migration problem so that we can continue to tinker with our beloved > language without fear of flames burning down the house. > > I should have been more explicit. I was more thinking of a multi-tiered > warning system, where we decide, as a community, not to be embarrassed by > warnings of severity less than X. When putting a DEPRECATED pragma on a > definition, we could then give an indication of how soon we expect the > definition to be gone. > > I was not thinking of the sort of "smart" behavior that Joachim wrote > about. I want my programs to do exactly what I say -- compilers should only > be so clever. > > Richard > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Fri Oct 9 07:29:12 2015 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 9 Oct 2015 09:29:12 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> Message-ID: 2015-10-09 2:34 GMT+02:00 David Thomas : > No, and I'm not sure just how well existing Hackage tooling/process > matches the workflow (due mostly to ignorance of existing Hackage > tooling/process). To the degree that there's a mismatch, it may have > reason sufficient to abandon the approach - or it may suggest > improvements to tooling/process. > To be honest, I can't really see how git can help with the versioning issue at all. Let's think backwards: In the end, you must give your compiler a single version of your code which works with. The common solution for this is to run something before the actual compilation stage (preprocessing), which picks the right parts from a single source. Let assume that we don't want this preprocessing step, then you still have to give your compiler a single correct version of your sources. How do you want to accomplish that? Shipping separate source packages (be it via Hackage or through some other means) for each version? This would be maintenance hell and much work, especially when there is no 1:1 correspondence between branches and compilers/libraries (as was proposed above). Furthermore, having to remember which stuff has been merged where, solving merge conflicts, introducing new branches when compilers/libraries change, etc. etc. requires extensive bookkeeping beyond git, to such an extent that larger companies normally have several people working full-time on such non-technical stuff. This is definitely not the way to go when you want to encourage people to work on their free time in Haskell. In a nutshell: IMHO having #ifdefs in the code is the lesser evil. If somebody has a better, actually working idea, he can probably become a millionaire quickly by selling this to the industry... -------------- next part -------------- An HTML attachment was scrubbed... URL: From _deepfire at feelingofgreen.ru Fri Oct 9 09:00:09 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Fri, 09 Oct 2015 12:00:09 +0300 Subject: [Haskell-cafe] Monad of no `return` Proposal In-Reply-To: <2053594A-C0F7-4A45-B794-7654C12E7342@cs.otago.ac.nz> (sfid-20151009_074130_948575_0200F98E) (Richard A. O'Keefe's message of "Fri, 9 Oct 2015 16:18:19 +1300") References: <201510052259.t95MxLKS013731@coolidge.cs.Dartmouth.EDU> <87lhbgl5lb.fsf@feelingofgreen.ru> <2053594A-C0F7-4A45-B794-7654C12E7342@cs.otago.ac.nz> Message-ID: <87pp0ofmcm.fsf@feelingofgreen.ru> "Richard A. O'Keefe" writes: > On 6/10/2015, at 10:16 pm, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote: >> As an example of the opposite end, consider Common Lisp, which: >> >> 1. reifies READ as the third processing phase (macroexpansion[1] and actual >> compilation being the other two) >> 2. operates at expression granularity >> 3. makes the full power of the language available to support the >> decision process of what subexpressions are available in which >> contexts > > Except that the syntax for conditional reading in Common Lisp, > #+ > #- > > (a) is utterly different from conditional evaluation, > like (if ). > (b) does NOT make the full power of the language available. > The feature test is a Boolean combination, using and, or, not > of atoms, where the value of an atom is true iff it is a > member of *features* (the asterisks are part of the name). There are several issues mixed up here: 1. Desirability of expression-level granularity of pre-processing. 2. The desired palette of options for this pre-processing (if desired), that varies in expressive power. 3. The difference between #+/#- and #. (aka *READ-EVAL*, http://clhs.lisp.se/Body/v_rd_eva.htm) in Common Lisp. My original message was about point #1, but point #2 deserves a similar kind of attention. The point #3 is purely didactic -- the READ-time processing is layered in Common Lisp into: 1. the basic layer, covering 95% of cases, which uses the following primitives, to decide if an expression suffix needs to be included: - *FEATURES*, a variable containing a list of features - ability to test for presence of a certain symbol within *FEATURES* - ability to combine atomic tests using AND, OR, NOT It is, indeed, what is covered in the example that I have provided. 2. the full language layer, available through #. -- whatever is returned by the expression following #. is inserted as program text. This layered approach has some merit: - It provides a kind of frugal brevity, that is sufficient in 95% of cases - Whenever the soft option fails, it unleashes the whole language to express basically anything during that pre-processing phase. Except, in the latter case it /probably/ doesn't count as pre-processing anymore, since the inserted text is no longer external to the pre-processor directives. -- ? ???????e? / respectfully, ??????? ?????? -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? ? Friedrich Wilhelm Nietzsche From robstewart57 at gmail.com Fri Oct 9 11:30:57 2015 From: robstewart57 at gmail.com (Rob Stewart) Date: Fri, 9 Oct 2015 12:30:57 +0100 Subject: [Haskell-cafe] Time performance with inlining and space performance with newtype? Message-ID: Hi, I'm in search of clarifications and descriptions about code optimisations that are recommended in GHC docs, regarding inlining and newtype vs data. 1. Inlining small and often used functions See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html , Section "7.22.6.1. INLINE pragma". It says: "GHC tries to inline functions/values that are 'small enough', thus avoiding the call overhead and possibly exposing other more-wonderful optimisations." I understand the reason for function inlining with other languages like C, as it avoids the construction of new stack frames and coordinating stack pointers for each function call. In Haskell, rather than call stack we've got evaluation stacks. Here are my questions: what exactly is the call overhead of a non-inlned Haskell function? What additional runtime work needs to happen when calling to a non-inlined function? Specifically what other GHC optimisations are possible only if function inlining happens first? Can anyone provide a simple example where 1) a function is not inlined, versus 2) when that function is inlined, which demonstrates two things: 1) a GHC report of the additional optimisations that were applied because of inlining and 2) shorter program runtime as a result of inlining. 2. Calculating the memory costs of a data type As Don Stewart nicely explains on SO http://stackoverflow.com/a/5889784/1526266 , we should always use newtype when we have only a single constructor which has a single field. His example is this: data Book = Book Int Int newtype Book = Book (Int, Int) With newtype, the `Book` construct is guaranteed to be erased at compile time, to have the same representation as `(Int,Int)`. How to I measure the memory space costs of having `Book Int Int` hanging around at runtime, as opposed to just `(Int,Int)`? How many bytes does it cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)` ? Can I ask GHC to tell me how many bytes the storage of each object would require? Or more generally, would looking at GHC Core for all my data structures inform me of the memory space costs for each of them? Thanks -- Rob From blamario at ciktel.net Fri Oct 9 12:57:17 2015 From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Fri, 9 Oct 2015 08:57:17 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> Message-ID: <5617B9AD.90703@ciktel.net> On 10/09/2015 03:29 AM, Sven Panne wrote: > 2015-10-09 2:34 GMT+02:00 David Thomas >: > > No, and I'm not sure just how well existing Hackage tooling/process > matches the workflow (due mostly to ignorance of existing Hackage > tooling/process). To the degree that there's a mismatch, it may have > reason sufficient to abandon the approach - or it may suggest > improvements to tooling/process. > > > To be honest, I can't really see how git can help with the versioning > issue at all. Let's think backwards: In the end, you must give your > compiler a single version of your code which works with. The common > solution for this is to run something before the actual compilation > stage (preprocessing), which picks the right parts from a single > source. Let assume that we don't want this preprocessing step, then > you still have to give your compiler a single correct version of your > sources. How do you want to accomplish that? Shipping separate source > packages (be it via Hackage or through some other means) for each version? Via Hackage. Let's say my-package is at version 1.7.2 as far as features and bug fixes go; Hackage would then host my-package-1.7.2.708 and my-package-1.7.2.710. The former is uploaded by running cabal upload on branch ghc-7.8 of the source repository, the latter on branch ghc-7.10. The main difference between the branches would be in the .cabal file: on ghc-7.8 branch version: my-package-1.7.2.708 build-depends: ghc <= 7.8.*, on ghc-7.10 branch version: my-package-1.7.2.710 build-depends: ghc == 7.10.*, You can do this with no extra tooling, the only extra work is to run seven commands instead of one at publishing time: git checkout ghc-7.8 git merge master cabal upload git checkout ghc-7.10 git merge master cabal upload git checkout master Obviously it would be better to script this, or even to add support directly to cabal-install and stack. > This would be maintenance hell and much work, especially when there is > no 1:1 correspondence between branches and compilers/libraries (as was > proposed above). Furthermore, having to remember which stuff has been > merged where, solving merge conflicts, introducing new branches when > compilers/libraries change, etc. etc. requires extensive bookkeeping > beyond git, to such an extent that larger companies normally have > several people working full-time on such non-technical stuff. This is > definitely not the way to go when you want to encourage people to work > on their free time in Haskell. I really don't see what could possibly cause all that complexity. Conflicts between different GHC branches and master development branch should be minimal, with any care. > In a nutshell: IMHO having #ifdefs in the code is the lesser evil. If > somebody has a better, actually working idea, he can probably become a > millionaire quickly by selling this to the industry... The industry can be remarkably reluctant to take up a new idea; nobody has ever been fired for using #ifdef. From sumit.sahrawat.apm13 at iitbhu.ac.in Fri Oct 9 13:01:26 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Fri, 9 Oct 2015 18:31:26 +0530 Subject: [Haskell-cafe] Time performance with inlining and space performance with newtype? In-Reply-To: References: Message-ID: I can only answer the questions to the best of my understanding, here goes: On 9 October 2015 at 17:00, Rob Stewart wrote: > > Here are my questions: what exactly is the call overhead of a > non-inlned Haskell function? What additional runtime work needs to > happen when calling to a non-inlined function? Specifically what other > GHC optimisations are possible only if function inlining happens > first? Can anyone provide a simple example where 1) a function is not > inlined, versus 2) when that function is inlined, which demonstrates > two things: 1) a GHC report of the additional optimisations that were > applied because of inlining and 2) shorter program runtime as a result > of inlining. An example of optimizations becoming available after inlining: listAdd1 = map (+1) listAdd2 = map (+2) listAdd3 = listAdd2 . listAdd1 -- From the RHS of listAdd3 listAdd2 . listAdd1 == map (+2) . map (+1) == map ((+2) . (+1)) -- List fusion. Also works for types other than lists (see the talk [1] for more) == map (\x -> (+2) ((+1) x)) -- Inline the composition dot-operator (.) == map (\x -> (+2) (x + 1)) == map (\x -> x + 3) == map (+3) -- The order and the final result might not be the same, but it will be operationally equivalent. -- This prevents having to iterate over the whole list twice. On 9 October 2015 at 17:00, Rob Stewart wrote: > > As Don Stewart nicely explains on SO > http://stackoverflow.com/a/5889784/1526266 , we should always use > newtype when we have only a single constructor which has a single > field. His example is this: > > data Book = Book Int Int > newtype Book = Book (Int, Int) > > With newtype, the `Book` construct is guaranteed to be erased at > compile time, to have the same representation as `(Int,Int)`. How to I > measure the memory space costs of having `Book Int Int` hanging around > at runtime, as opposed to just `(Int,Int)`? How many bytes does it > cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)` > ? Can I ask GHC to tell me how many bytes the storage of each object > would require? Or more generally, would looking at GHC Core for all my > data structures inform me of the memory space costs for each of them? > I don't think it's possible to look into GHC's memory. Simon Marlow's book [2] explains laziness very well, but even he (he wrote the GHC runtime) says that there is no way to see the actual structure of memory usage. [1]: http://www.techcast.com/events/bigtechday6/odeon-1130/?q=odeon-1130 [2]: http://amzn.com/1449335942 -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Fri Oct 9 13:42:49 2015 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 9 Oct 2015 15:42:49 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5617B9AD.90703@ciktel.net> References: <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> Message-ID: 2015-10-09 14:57 GMT+02:00 Mario Bla?evi? : > [...] You can do this with no extra tooling, the only extra work is to run > seven commands instead of one at publishing time: > > git checkout ghc-7.8 > git merge master > cabal upload > git checkout ghc-7.10 > git merge master > cabal upload > git checkout master > Let's pray that no merge conflicts will happen. Furthermore, you've omitted the "git push"s to github to let Travis CI tell you what you've forgot. You should better do that before an upload. Ooops, and you forgot to tag the release, too (I mean 7 tags)... > [...] I really don't see what could possibly cause all that complexity. > Conflicts between different GHC branches and master development branch > should be minimal, with any care. For toy stuff you might be right, but in any larger project I've seen in the last decades, keeping branches well maintained *is* non-trivial. Normally you already have branches for different releases of your SW you still have to maintain, and with the proposed approach you would effectively multiply the number of those branches by the number of supported platforms/compilers. Much fun proposing that to your manager... This might work if you have only linear development and few platforms, but otherwise it won't scale. Furthermore, having #ifdef-free code is a non-goal in itself: The goal we talk about is ease of maintenance, and as it's proposed, it makes a maintainer's life harder, not easier (you need much more steps + bookkeeping). And the merges e.g. only work automatically when the change in the #ifdef'd code would be trivial, too (adding/removing lines, etc.), so git doesn't offer any advantage. > In a nutshell: IMHO having #ifdefs in the code is the lesser evil. If >> somebody has a better, actually working idea, he can probably become a >> millionaire quickly by selling this to the industry... >> > > The industry can be remarkably reluctant to take up a new idea; nobody > has ever been fired for using #ifdef. If you can provably speed up development time and/or release cycles, selling new ideas is easy: Nobody has been fired for reaching a deadline too early. OTOH making some work easier and at the same time other work more complicated (as is the case in the proposal) will meet some resistance... -------------- next part -------------- An HTML attachment was scrubbed... URL: From anselm.scholl at tu-harburg.de Fri Oct 9 13:48:06 2015 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Fri, 9 Oct 2015 15:48:06 +0200 Subject: [Haskell-cafe] Time performance with inlining and space performance with newtype? In-Reply-To: References: Message-ID: <5617C596.4080000@tu-harburg.de> On 10/09/2015 01:30 PM, Rob Stewart wrote: > Hi, > > I'm in search of clarifications and descriptions about code > optimisations that are recommended in GHC docs, regarding inlining and > newtype vs data. > > 1. Inlining small and often used functions > > See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html > , Section "7.22.6.1. INLINE pragma". It says: > > "GHC tries to inline functions/values that are 'small enough', thus > avoiding the call overhead and possibly exposing other more-wonderful > optimisations." > > I understand the reason for function inlining with other languages > like C, as it avoids the construction of new stack frames and > coordinating stack pointers for each function call. In Haskell, rather > than call stack we've got evaluation stacks. I am not an expert, but I can try to share my understanding of the issue. For one, you have the possibility for other optimisations. Consider: addThree :: Int -> Int -> Int addThree a b c = a + b + c This is compiled to the following core (simplified): addThree = \ a b c -> (+) $dNum_Int ((+) $dNum_Int a b) c (+) is a record selector for the Num dictionary. By inlining (+) and $dNum_Int we get this core: add_Int = \ a b -> case a of I# a# -> case b of I# b# -> I# (a# +# b#) addThree = \ a b c -> add_Int (add_Int a b) c where Int is defined as data Int = I# Int# and (+#) implements primitive (C-like) addition and has type Int# -> Int# -> Int#. add_Int is again a small function and we inline it: addThree = \ a b c -> add_Int (case a of I# a# -> case b of I# b# -> I# (a# +# b#)) c So now we can see the code allocates an Int (the I# constructor) only to pattern match on it immediately again. If we inline the second occurrence of add_Int, we get this: addThree = \ a b c -> case (case a of I# a# -> case b of I# b# -> I# (a# +# b#)) of I# a' -> case c of I# c# -> I# (a' +# c#) Now we can not inline further, but the simplifier can apply transformations it couldn't do previously. For example it can apply the case-of-case transformation: addThree = \ a b c -> case a of I# a# -> case b of I# b# -> case I# (a# +# b#) of I# a' -> case c of I# c# -> I# (a' +# c#) Now it sees it can eliminate the I# constructor: addThree = \ a b c -> case a of I# a# -> case b of I# b# -> case a# +# b# of a' -> case c of I# c# -> I# (a' +# c#) I think GHC now floats the addition to its usage site, so we get: addThree = \ a b c -> case a of I# a# -> case b of I# b# -> case c of I# c# -> I# ((a# +# b#) +# c#) So inlining did not only save some function calls, but we also avoided to allocate a boxed Int value. > > Here are my questions: what exactly is the call overhead of a > non-inlned Haskell function? What additional runtime work needs to > happen when calling to a non-inlined function? Specifically what other > GHC optimisations are possible only if function inlining happens > first? Can anyone provide a simple example where 1) a function is not > inlined, versus 2) when that function is inlined, which demonstrates > two things: 1) a GHC report of the additional optimisations that were > applied because of inlining and 2) shorter program runtime as a result > of inlining. As I tried to show in the above example, its not about the call overhead, but additional possible simplifications. Inlining a function can make polymorphic arguments monomorphic and provides the possibility to inline other small functions. It can further expose combinations of functions used for list- or stream-fusion (many fusing functions are implemented as unstream . streamedOp . stream with a rule stream . unsteam = id). Without inlining, fusion would not work at all. > > 2. Calculating the memory costs of a data type > > As Don Stewart nicely explains on SO > http://stackoverflow.com/a/5889784/1526266 , we should always use > newtype when we have only a single constructor which has a single > field. His example is this: > > data Book = Book Int Int > newtype Book = Book (Int, Int) > > With newtype, the `Book` construct is guaranteed to be erased at > compile time, to have the same representation as `(Int,Int)`. How to I > measure the memory space costs of having `Book Int Int` hanging around > at runtime, as opposed to just `(Int,Int)`? How many bytes does it > cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)` > ? Can I ask GHC to tell me how many bytes the storage of each object > would require? Or more generally, would looking at GHC Core for all my > data structures inform me of the memory space costs for each of them? There is no difference in your example. Consider instead data BookD = BookD Int newtype BookN = BookN Int BookD consumes 2 pointers (info pointer and pointer to the boxed Int) while BookN has only the size of a boxed Int (a pointer and a machine word for the Int# stored in the boxed Int). So by using a newtype you save 2 pointers and an additional indirection. It also changes the semantics of the code: Because a newtype is "free", it has to be strict in its one and only field. So if you evaluate BookD undefined to WHNF, you will get no exception while evaluating BookN undefined will throw an exception. Back to your example: Here we have either a constructor with two fields, so we need three pointers to store the object (one for the info pointer), or we have a tuple, which also contains two pointers, so it is again three pointers large. The only difference is the newtype can reuse the already existing info table for the (,) data type while the Book data type needs its own info table, so we save a few bytes of generated code (if at all, I do not know if GHC reuses info tables in such a situation). > > Thanks > You're welcome. > -- > Rob > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From robstewart57 at gmail.com Fri Oct 9 14:06:32 2015 From: robstewart57 at gmail.com (Rob Stewart) Date: Fri, 9 Oct 2015 15:06:32 +0100 Subject: [Haskell-cafe] Time performance with inlining and space performance with newtype? In-Reply-To: References: Message-ID: To add third case: 1. which optimising GHC passes does SPECIALIZE enable? Taking the example from the GHC docs https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html#specialize-pragma : hammeredLookup :: Ord key => [(key, value)] -> key -> value {-# SPECIALIZE hammeredLookup :: [(Widget, value)] -> Widget -> value #-} This means that the type class dictionary for Ord will not be passed as a (hidden) argument in Core to `hammeredLookup` when Widget is the key. The GHC docs about overloading https://wiki.haskell.org/Performance/Overloading says "The presence of overloading can prevent many other optimisations, such as Strictness, from kicking in". So we lose the strictness GHC optimiser in the absence of SPECIALIZE rules on overloaded functions. Other than strictness analysis, what other GHC optimisations are being missed when overloading is not dealt with using monomorphism? And what are the specific runtime overheads of passing type class constraints as dictionaries to overloaded functions at runtime? -- Rob On 9 October 2015 at 12:30, Rob Stewart wrote: > Hi, > > I'm in search of clarifications and descriptions about code > optimisations that are recommended in GHC docs, regarding inlining and > newtype vs data. > > 1. Inlining small and often used functions > > See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html > , Section "7.22.6.1. INLINE pragma". It says: > > "GHC tries to inline functions/values that are 'small enough', thus > avoiding the call overhead and possibly exposing other more-wonderful > optimisations." > > I understand the reason for function inlining with other languages > like C, as it avoids the construction of new stack frames and > coordinating stack pointers for each function call. In Haskell, rather > than call stack we've got evaluation stacks. > > Here are my questions: what exactly is the call overhead of a > non-inlned Haskell function? What additional runtime work needs to > happen when calling to a non-inlined function? Specifically what other > GHC optimisations are possible only if function inlining happens > first? Can anyone provide a simple example where 1) a function is not > inlined, versus 2) when that function is inlined, which demonstrates > two things: 1) a GHC report of the additional optimisations that were > applied because of inlining and 2) shorter program runtime as a result > of inlining. > > 2. Calculating the memory costs of a data type > > As Don Stewart nicely explains on SO > http://stackoverflow.com/a/5889784/1526266 , we should always use > newtype when we have only a single constructor which has a single > field. His example is this: > > data Book = Book Int Int > newtype Book = Book (Int, Int) > > With newtype, the `Book` construct is guaranteed to be erased at > compile time, to have the same representation as `(Int,Int)`. How to I > measure the memory space costs of having `Book Int Int` hanging around > at runtime, as opposed to just `(Int,Int)`? How many bytes does it > cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)` > ? Can I ask GHC to tell me how many bytes the storage of each object > would require? Or more generally, would looking at GHC Core for all my > data structures inform me of the memory space costs for each of them? > > Thanks > > -- > Rob From michael at orlitzky.com Fri Oct 9 14:09:59 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Fri, 9 Oct 2015 10:09:59 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> Message-ID: <5617CAB7.4070507@orlitzky.com> On 10/09/2015 09:42 AM, Sven Panne wrote: > > For toy stuff you might be right, but in any larger project I've seen in > the last decades, keeping branches well maintained *is* non-trivial. > Normally you already have branches for different releases of your SW you > still have to maintain, and with the proposed approach you would > effectively multiply the number of those branches by the number of > supported platforms/compilers. Much fun proposing that to your > manager... This might work if you have only linear development and few > platforms, but otherwise it won't scale. > > Furthermore, having #ifdef-free code is a non-goal in itself: The goal > we talk about is ease of maintenance, and as it's proposed, it makes a > maintainer's life harder, not easier (you need much more steps + > bookkeeping). And the merges e.g. only work automatically when the > change in the #ifdef'd code would be trivial, too (adding/removing > lines, etc.), so git doesn't offer any advantage. > It works, everyone else already does it, the complexity is there whether you branch or not, you'll never have merge conflicts, etc. I'm not sure how much effort you want me to expend convincing you to improve your life. I don't have this problem. Go try it instead of arguing that it can't possibly work. From robstewart57 at gmail.com Fri Oct 9 14:16:04 2015 From: robstewart57 at gmail.com (Rob Stewart) Date: Fri, 9 Oct 2015 15:16:04 +0100 Subject: [Haskell-cafe] Time performance with inlining and space performance with newtype? In-Reply-To: <5617C596.4080000@tu-harburg.de> References: <5617C596.4080000@tu-harburg.de> Message-ID: Thank you Jonas, both answers were very nicely explained! On 9 October 2015 at 14:48, Jonas Scholl wrote: > On 10/09/2015 01:30 PM, Rob Stewart wrote: >> Hi, >> >> I'm in search of clarifications and descriptions about code >> optimisations that are recommended in GHC docs, regarding inlining and >> newtype vs data. >> >> 1. Inlining small and often used functions >> >> See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/pragmas.html >> , Section "7.22.6.1. INLINE pragma". It says: >> >> "GHC tries to inline functions/values that are 'small enough', thus >> avoiding the call overhead and possibly exposing other more-wonderful >> optimisations." >> >> I understand the reason for function inlining with other languages >> like C, as it avoids the construction of new stack frames and >> coordinating stack pointers for each function call. In Haskell, rather >> than call stack we've got evaluation stacks. > > I am not an expert, but I can try to share my understanding of the issue. > > For one, you have the possibility for other optimisations. Consider: > > addThree :: Int -> Int -> Int > addThree a b c = a + b + c > > This is compiled to the following core (simplified): > > addThree = \ a b c -> (+) $dNum_Int ((+) $dNum_Int a b) c > > (+) is a record selector for the Num dictionary. By inlining (+) and > $dNum_Int we get this core: > > add_Int = \ a b -> case a of > I# a# -> case b of > I# b# -> I# (a# +# b#) > > addThree = \ a b c -> add_Int (add_Int a b) c > > where Int is defined as > data Int = I# Int# > > and (+#) implements primitive (C-like) addition and has type Int# -> > Int# -> Int#. > > add_Int is again a small function and we inline it: > > addThree = \ a b c -> add_Int (case a of > I# a# -> case b of > I# b# -> I# (a# +# b#)) c > > So now we can see the code allocates an Int (the I# constructor) only to > pattern match on it immediately again. If we inline the second > occurrence of add_Int, we get this: > > addThree = \ a b c -> case (case a of > I# a# -> case b of > I# b# -> I# (a# +# b#)) of > I# a' -> case c of > I# c# -> I# (a' +# c#) > > Now we can not inline further, but the simplifier can apply > transformations it couldn't do previously. For example it can apply the > case-of-case transformation: > > addThree = \ a b c -> case a of > I# a# -> case b of > I# b# -> case I# (a# +# b#) of > I# a' -> case c of > I# c# -> I# (a' +# c#) > > Now it sees it can eliminate the I# constructor: > > addThree = \ a b c -> case a of > I# a# -> case b of > I# b# -> case a# +# b# of > a' -> case c of > I# c# -> I# (a' +# c#) > > I think GHC now floats the addition to its usage site, so we get: > > addThree = \ a b c -> case a of > I# a# -> case b of > I# b# -> case c of > I# c# -> I# ((a# +# b#) +# c#) > > So inlining did not only save some function calls, but we also avoided > to allocate a boxed Int value. > >> >> Here are my questions: what exactly is the call overhead of a >> non-inlned Haskell function? What additional runtime work needs to >> happen when calling to a non-inlined function? Specifically what other >> GHC optimisations are possible only if function inlining happens >> first? Can anyone provide a simple example where 1) a function is not >> inlined, versus 2) when that function is inlined, which demonstrates >> two things: 1) a GHC report of the additional optimisations that were >> applied because of inlining and 2) shorter program runtime as a result >> of inlining. > > As I tried to show in the above example, its not about the call > overhead, but additional possible simplifications. Inlining a function > can make polymorphic arguments monomorphic and provides the possibility > to inline other small functions. It can further expose combinations of > functions used for list- or stream-fusion (many fusing functions are > implemented as unstream . streamedOp . stream with a rule stream . > unsteam = id). Without inlining, fusion would not work at all. > >> >> 2. Calculating the memory costs of a data type >> >> As Don Stewart nicely explains on SO >> http://stackoverflow.com/a/5889784/1526266 , we should always use >> newtype when we have only a single constructor which has a single >> field. His example is this: >> >> data Book = Book Int Int >> newtype Book = Book (Int, Int) >> >> With newtype, the `Book` construct is guaranteed to be erased at >> compile time, to have the same representation as `(Int,Int)`. How to I >> measure the memory space costs of having `Book Int Int` hanging around >> at runtime, as opposed to just `(Int,Int)`? How many bytes does it >> cost to store `Book 4 5`? How many bytes does it cost to store `(4,5)` >> ? Can I ask GHC to tell me how many bytes the storage of each object >> would require? Or more generally, would looking at GHC Core for all my >> data structures inform me of the memory space costs for each of them? > > There is no difference in your example. Consider instead > > data BookD = BookD Int > newtype BookN = BookN Int > > BookD consumes 2 pointers (info pointer and pointer to the boxed Int) > while BookN has only the size of a boxed Int (a pointer and a machine > word for the Int# stored in the boxed Int). So by using a newtype you > save 2 pointers and an additional indirection. It also changes the > semantics of the code: Because a newtype is "free", it has to be strict > in its one and only field. So if you evaluate BookD undefined to WHNF, > you will get no exception while evaluating BookN undefined will throw an > exception. > > Back to your example: Here we have either a constructor with two fields, > so we need three pointers to store the object (one for the info > pointer), or we have a tuple, which also contains two pointers, so it is > again three pointers large. The only difference is the newtype can reuse > the already existing info table for the (,) data type while the Book > data type needs its own info table, so we save a few bytes of generated > code (if at all, I do not know if GHC reuses info tables in such a > situation). > >> >> Thanks >> > > You're welcome. > >> -- >> Rob >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From taruti at taruti.net Fri Oct 9 14:32:24 2015 From: taruti at taruti.net (Taru Karttunen) Date: Fri, 9 Oct 2015 17:32:24 +0300 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5617B9AD.90703@ciktel.net> References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> Message-ID: On 09.10 08:57, Mario Bla?evi? wrote: > Via Hackage. Let's say my-package is at version 1.7.2 as far as features > and bug fixes go; Hackage would then host my-package-1.7.2.708 and > my-package-1.7.2.710. The former is uploaded by running cabal upload on > branch ghc-7.8 of the source repository, the latter on branch ghc-7.10. The > main difference between the branches would be in the .cabal file: > > on ghc-7.8 branch > > version: my-package-1.7.2.708 > build-depends: ghc <= 7.8.*, > > > on ghc-7.10 branch > > version: my-package-1.7.2.710 > build-depends: ghc == 7.10.*, > > You can do this with no extra tooling, the only extra work is to run > seven commands instead of one at publishing time: > > git checkout ghc-7.8 > git merge master > cabal upload > git checkout ghc-7.10 > git merge master > cabal upload > git checkout master And then GHC 8.0 is released and your library is broken until you update the cabal file or add a new branch. Which means that all libraries depending on your library refuse to build... This would mean that all libraries would need a new release on each GHC major version? Oh and testing your library on HEAD before release? Not supported? Using any library depending on your library before the release? - Taru Karttunen From michael at orlitzky.com Fri Oct 9 14:37:33 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Fri, 9 Oct 2015 10:37:33 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> Message-ID: <5617D12D.6080207@orlitzky.com> On 10/09/2015 10:32 AM, Taru Karttunen wrote: >> >> You can do this with no extra tooling, the only extra work is to run >> seven commands instead of one at publishing time: >> >> git checkout ghc-7.8 >> git merge master >> cabal upload >> git checkout ghc-7.10 >> git merge master >> cabal upload >> git checkout master > > And then GHC 8.0 is released and your library is broken until you > update the cabal file or add a new branch. Which means that all > libraries depending on your library refuse to build... > > This would mean that all libraries would need a new release > on each GHC major version? Oh and testing your library on > HEAD before release? Not supported? Using any library depending > on your library before the release? > This has nothing to do with git. You have that problem anyway. Don't want a version bound on your latest branch? Don't put one there. From mblazevic at stilo.com Fri Oct 9 15:47:04 2015 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Fri, 9 Oct 2015 11:47:04 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> Message-ID: <5617E178.9000506@stilo.com> On 15-10-09 10:32 AM, Taru Karttunen wrote: > On 09.10 08:57, Mario Bla?evi? wrote: >> ... >> on ghc-7.10 branch >> >> version: my-package-1.7.2.710 >> build-depends: ghc == 7.10.*, >> >> ... > > And then GHC 8.0 is released and your library is broken until you > update the cabal file or add a new branch. Which means that all > libraries depending on your library refuse to build... > > This would mean that all libraries would need a new release > on each GHC major version? Oh and testing your library on > HEAD before release? Not supported? Using any library depending > on your library before the release? Relax. Take a deep breath. The above branching scheme extends the PVP guidance to GHC as well; which is to say, it assumes every major GHC release to have a potential to break your package. But if you trust that GHC 8.0 will be backward compatible with 7.10 as far as your code goes, you can change the same .cabal file to >> on ghc-7.10 branch >> >> version: my-package-1.7.2.710 >> build-depends: ghc >= 7.10 && < 8.1, and if you're confident that GHC will *never* break your code again, you can even have >> on ghc-forever branch >> >> version: my-package-1.7.2.0 >> build-depends: ghc >= 7.10 From dhelta.diaz at gmail.com Fri Oct 9 16:33:53 2015 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Fri, 9 Oct 2015 12:33:53 -0400 Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0 Message-ID: Dear Haskell users, I just released a new version of haskintex, the program that runs Haskell code inside LaTeX documents. http://hackage.haskell.org/package/haskintex # More about haskintex For those who don't know the program yet, _haskintex_ is a tool that executes Haskell code inside LaTeX documents, creating a new LaTeX document where each Haskell expression has been replaced by its result. Furthermore, since haskintex has a special command for using the HaTeX library, you will be able to write Haskell code that generates LaTeX code. Find more details in the haskintex documentation page: http://daniel-diaz.github.io/projects/haskintex # What's new? One of the main issues when evaluating Haskell code with haskintex was that haskintex was not aware of sandbox environments, so it had to rely on user or global package databases. From version 0.6.0.0, haskintex can now detect and use sandbox package databases, with no additional effort required from you. The -nosandbox flag has been added in case you still want the old behavior. Another addition is the -autotexy flag. Without the flag, every expression contained in a \hatex command is required to have type LaTeX. When the flag is enabled, this restriction is relaxed to any type that is an instance of the Texy typeclass. This typeclass contains instances for types that can be rendered to LaTeX syntax. Could be some text, numbers, or even matrices. You can create your own instances too. Suggestions, bugs, questions? Head to the haskintex issue tracker: https://github.com/Daniel-Diaz/haskintex/issues Happy texing, Daniel D?az. -------------- next part -------------- An HTML attachment was scrubbed... URL: From achudnov at gmail.com Fri Oct 9 19:32:07 2015 From: achudnov at gmail.com (Andrey Chudnov) Date: Fri, 9 Oct 2015 15:32:07 -0400 Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0 In-Reply-To: References: Message-ID: <56181637.30607@gmail.com> Daniel, Can this be used in conjunction with the `diagrams` package to generate diagrams in LaTeX instead of suffering through Tikz? Is it possible to include a Haskell source file instead of inlining it in the tex file? On 10/09/2015 12:33 PM, Daniel D?az Casanueva wrote: > Dear Haskell users, > > I just released a new version of haskintex, the program that runs > Haskell code inside LaTeX documents. > > http://hackage.haskell.org/package/haskintex > > # More about haskintex > > For those who don't know the program yet, _haskintex_ is a tool that > executes Haskell code inside LaTeX documents, creating a new LaTeX > document where each Haskell expression has been replaced by its > result. Furthermore, since haskintex has a special command for using > the HaTeX library, you will be able to write Haskell code that > generates LaTeX code. Find more details in the haskintex documentation > page: > > http://daniel-diaz.github.io/projects/haskintex > > # What's new? > > One of the main issues when evaluating Haskell code with haskintex was > that haskintex was not aware of sandbox environments, so it had to > rely on user or global package databases. From version 0.6.0.0, > haskintex can now detect and use sandbox package databases, with no > additional effort required from you. The -nosandbox flag has been > added in case you still want the old behavior. > > Another addition is the -autotexy flag. Without the flag, every > expression contained in a \hatex command is required to have type > LaTeX. When the flag is enabled, this restriction is relaxed to any > type that is an instance of the Texy typeclass. This typeclass > contains instances for types that can be rendered to LaTeX syntax. > Could be some text, numbers, or even matrices. You can create your own > instances too. > > Suggestions, bugs, questions? Head to the haskintex issue tracker: > > https://github.com/Daniel-Diaz/haskintex/issues > > Happy texing, > Daniel D?az. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhelta.diaz at gmail.com Fri Oct 9 19:46:10 2015 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Fri, 9 Oct 2015 15:46:10 -0400 Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0 In-Reply-To: <56181637.30607@gmail.com> References: <56181637.30607@gmail.com> Message-ID: > Can this be used in conjunction with the `diagrams` package to generate diagrams in LaTeX instead of suffering through Tikz? There is no way of using haskintex combined with diagrams at the moment. But using the HaTeX library you don't have to write the tikz code! Let the library generate the tikz code for you: http://hackage.haskell.org/package/HaTeX-3.16.1.1/docs/Text-LaTeX-Packages-TikZ-Simple.html Unfortunately, it doesn't have most of the features diagrams offer. > Is it possible to include a Haskell source file instead of inlining it in the tex file? You can write the source file and then use the Haskell import. You can also open a ticket requesting a feature to include source files with a special command. In any case, I take note of the suggestion. ;) Best regards, Daniel D?az. On Fri, Oct 9, 2015 at 3:32 PM, Andrey Chudnov wrote: > Daniel, > Can this be used in conjunction with the `diagrams` package to generate > diagrams in LaTeX instead of suffering through Tikz? > Is it possible to include a Haskell source file instead of inlining it in > the tex file? > > > On 10/09/2015 12:33 PM, Daniel D?az Casanueva wrote: > > Dear Haskell users, > > I just released a new version of haskintex, the program that runs Haskell > code inside LaTeX documents. > > http://hackage.haskell.org/package/haskintex > > # More about haskintex > > For those who don't know the program yet, _haskintex_ is a tool that > executes Haskell code inside LaTeX documents, creating a new LaTeX document > where each Haskell expression has been replaced by its result. Furthermore, > since haskintex has a special command for using the HaTeX library, you will > be able to write Haskell code that generates LaTeX code. Find more details > in the haskintex documentation page: > > http://daniel-diaz.github.io/projects/haskintex > > # What's new? > > One of the main issues when evaluating Haskell code with haskintex was > that haskintex was not aware of sandbox environments, so it had to rely on > user or global package databases. From version 0.6.0.0, haskintex can now > detect and use sandbox package databases, with no additional effort > required from you. The -nosandbox flag has been added in case you still > want the old behavior. > > Another addition is the -autotexy flag. Without the flag, every expression > contained in a \hatex command is required to have type LaTeX. When the flag > is enabled, this restriction is relaxed to any type that is an instance of > the Texy typeclass. This typeclass contains instances for types that can be > rendered to LaTeX syntax. Could be some text, numbers, or even matrices. > You can create your own instances too. > > Suggestions, bugs, questions? Head to the haskintex issue tracker: > > https://github.com/Daniel-Diaz/haskintex/issues > > Happy texing, > Daniel D?az. > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Fri Oct 9 20:16:11 2015 From: trebla at vex.net (Albert Y. C. Lai) Date: Fri, 9 Oct 2015 16:16:11 -0400 Subject: [Haskell-cafe] Time performance with inlining and space performance with newtype? In-Reply-To: References: Message-ID: <5618208B.8000107@vex.net> On 2015-10-09 07:30 AM, Rob Stewart wrote: > Can I ask GHC to tell me how many bytes the storage of each object > would require? Or more generally, would looking at GHC Core for all my > data structures inform me of the memory space costs for each of them? Cmm (-ddump-opt-cmm) is where you see the actual numbers directly. But if you already know the stuff in https://github.com/takenobu-hs/haskell-ghc-illustrated then you can just look at the Haskell level and predict. From rickdzekman at gmail.com Fri Oct 9 21:44:41 2015 From: rickdzekman at gmail.com (Rick Dzekman) Date: Sat, 10 Oct 2015 08:44:41 +1100 Subject: [Haskell-cafe] Vote/comment on usability survey feedback Message-ID: *Responses* Over 100 people responded to the Hackage usability survey. For a qualitative survey this was far more than expected so thank you all for contributing. I'm still going through the responses and will post a csv of the combined web, email and reddit responses soon. *Vote and comment* In the meantime I went through and collated all of the gripes and suggestions people made into two Trello boards: Suggestions board: https://trello.com/b/WJRNDtkD/hackage-usability-suggestions Issues & bugs board: https://trello.com/b/8YSJ5XYV/hackage-usability-issues If you have a Trello account (it's free to register) you can comment and vote on issues. *Please vote on the issues/suggestions you think are the best or most important*. Feel free to make any relevant comments on the cards as well. To vote simply open the card, look in the "Actions" section and select vote. That's it. If reading through the suggestions/issues makes you think of something new simply comment on the very top card and I can add your new suggestion to the list. *What happens next?* There are two things that I want to achieve: 1. Come up with a list of simple, easy to implement changes that can be done on Hackage/Haddocks 2. Come up with wireframes for a potential future state of Hackage that the community can comment on / contribute to, which encompasses everything learned from the survey Not every suggestion is going to be feasible regardless of how popular it is. Additionally, any suggestions which are feasible have to be implemented by someone. The more enthusiasm there is behind an idea (or issue) the more likely we are to see progress. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Fri Oct 9 22:07:12 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 9 Oct 2015 23:07:12 +0100 Subject: [Haskell-cafe] Vote/comment on usability survey feedback In-Reply-To: References: Message-ID: Thank you Rick. This looks like a great start to a list of well-defined manageable tasks which we can act upon to improve our ecosystem. I will make sure to mention this list at the hackathon in London tomorrow. Matt On Friday, October 9, 2015, Rick Dzekman wrote: > Responses > Over 100 people responded to the Hackage usability survey. For a qualitative survey this was far more than expected so thank you all for contributing. I'm still going through the responses and will post a csv of the combined web, email and reddit responses soon. > Vote and comment > In the meantime I went through and collated all of the gripes and suggestions people made into two Trello boards: > Suggestions board: https://trello.com/b/WJRNDtkD/hackage-usability-suggestions > Issues & bugs board: https://trello.com/b/8YSJ5XYV/hackage-usability-issues > If you have a Trello account (it's free to register) you can comment and vote on issues. Please vote on the issues/suggestions you think are the best or most important. Feel free to make any relevant comments on the cards as well. > To vote simply open the card, look in the "Actions" section and select vote. That's it. > If reading through the suggestions/issues makes you think of something new simply comment on the very top card and I can add your new suggestion to the list. > What happens next? > There are two things that I want to achieve: > 1. Come up with a list of simple, easy to implement changes that can be done on Hackage/Haddocks > 2. Come up with wireframes for a potential future state of Hackage that the community can comment on / contribute to, which encompasses everything learned from the survey > Not every suggestion is going to be feasible regardless of how popular it is. Additionally, any suggestions which are feasible have to be implemented by someone. The more enthusiasm there is behind an idea (or issue) the more likely we are to see progress. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fryguybob at gmail.com Fri Oct 9 23:48:38 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Fri, 9 Oct 2015 19:48:38 -0400 Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0 In-Reply-To: <56181637.30607@gmail.com> References: <56181637.30607@gmail.com> Message-ID: You can incorporate diagrams from the `diagrams` package inline in LaTeX using diagrams-builder. We have a tutorial written up here: http://projects.haskell.org/diagrams/doc/latex.html I imagine haskintex has a more sophisticated technique and it would be interesting to integrate diagrams with that approach too. Ryan On Fri, Oct 9, 2015 at 3:32 PM, Andrey Chudnov wrote: > Daniel, > Can this be used in conjunction with the `diagrams` package to generate > diagrams in LaTeX instead of suffering through Tikz? > Is it possible to include a Haskell source file instead of inlining it in > the tex file? > > > On 10/09/2015 12:33 PM, Daniel D?az Casanueva wrote: > > Dear Haskell users, > > I just released a new version of haskintex, the program that runs Haskell > code inside LaTeX documents. > > http://hackage.haskell.org/package/haskintex > > # More about haskintex > > For those who don't know the program yet, _haskintex_ is a tool that > executes Haskell code inside LaTeX documents, creating a new LaTeX document > where each Haskell expression has been replaced by its result. Furthermore, > since haskintex has a special command for using the HaTeX library, you will > be able to write Haskell code that generates LaTeX code. Find more details > in the haskintex documentation page: > > http://daniel-diaz.github.io/projects/haskintex > > # What's new? > > One of the main issues when evaluating Haskell code with haskintex was > that haskintex was not aware of sandbox environments, so it had to rely on > user or global package databases. From version 0.6.0.0, haskintex can now > detect and use sandbox package databases, with no additional effort > required from you. The -nosandbox flag has been added in case you still > want the old behavior. > > Another addition is the -autotexy flag. Without the flag, every expression > contained in a \hatex command is required to have type LaTeX. When the flag > is enabled, this restriction is relaxed to any type that is an instance of > the Texy typeclass. This typeclass contains instances for types that can be > rendered to LaTeX syntax. Could be some text, numbers, or even matrices. > You can create your own instances too. > > Suggestions, bugs, questions? Head to the haskintex issue tracker: > > https://github.com/Daniel-Diaz/haskintex/issues > > Happy texing, > Daniel D?az. > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fryguybob at gmail.com Sat Oct 10 00:19:18 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Fri, 9 Oct 2015 20:19:18 -0400 Subject: [Haskell-cafe] Interfacing with the GHC runtime from a library In-Reply-To: <2D70B8F4-55AD-46ED-84BF-EA942A2DAD03@gmail.com> References: <2D70B8F4-55AD-46ED-84BF-EA942A2DAD03@gmail.com> Message-ID: Hi Nicola, You can sort of do this, but as far as I know there are still some missing pieces to getting everything you would want. I'm in the process of doing this for some STM implementations with some colleagues and what I have so far has a few changes to GHC (teaching the GC about some new heap objects) some cmm code in the library imported as foreign prim's and some C code in the library. I build this with a cabal file and use the "--extra-include-dirs" flag to pass the path to the "rts/" directory for ghc. This last bit is the unfortunate part that I imagine once we work out what all we need exposed, we could include in what is installed with GHC. It might already be there, I'm not sure. Ryan On Thu, Oct 8, 2015 at 2:24 PM, Nicola Gigante wrote: > Hi everybody, > > suppose to have an Haskell library which is in part implemented in C > for whatever reason. Can the C part talk with the runtime, in particular > the scheduler? In other words, does the runtime expose the functionality > needed to implement, for example, the STM library from outside the GHC > runtime itself? > > Thank you, > Nicola > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From achudnov at gmail.com Sat Oct 10 00:25:29 2015 From: achudnov at gmail.com (Andrey Chudnov) Date: Fri, 9 Oct 2015 20:25:29 -0400 Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0 In-Reply-To: References: <56181637.30607@gmail.com> Message-ID: <56185AF9.6080708@gmail.com> Thanks, Ryan. The tutorial is really good and to-the-point. By the way, it looks like haskintex has a more general approach to integrating Haskell in LaTeX. It seems that in principle it could just use that to enable including diagrams in latex, without `diagrams-latex`. And the same question about including a Haskell source instead of inlining applies. To me, having a standalone Haskell file is superior since I can get syntax highlighting, typechecking and even quick REPL debugging of diagrams that way. While with the inlined one needs to re-pdflatex the whole thing to get type errors (do they even show up in the latex output?) and reflect the changes. I guess, that could be done with the PGF backend for diagrams and a suitable Makefile, though. On 10/09/2015 07:48 PM, Ryan Yates wrote: > You can incorporate diagrams from the `diagrams` package inline in > LaTeX using diagrams-builder. We have a tutorial written up here: > > http://projects.haskell.org/diagrams/doc/latex.html > > I imagine haskintex has a more sophisticated technique and it would be > interesting to integrate diagrams with that approach too. > > Ryan > > On Fri, Oct 9, 2015 at 3:32 PM, Andrey Chudnov > wrote: > > Daniel, > Can this be used in conjunction with the `diagrams` package to > generate diagrams in LaTeX instead of suffering through Tikz? > Is it possible to include a Haskell source file instead of > inlining it in the tex file? > > > On 10/09/2015 12:33 PM, Daniel D?az Casanueva wrote: >> Dear Haskell users, >> >> I just released a new version of haskintex, the program that runs >> Haskell code inside LaTeX documents. >> >> http://hackage.haskell.org/package/haskintex >> >> # More about haskintex >> >> For those who don't know the program yet, _haskintex_ is a tool >> that executes Haskell code inside LaTeX documents, creating a new >> LaTeX document where each Haskell expression has been replaced by >> its result. Furthermore, since haskintex has a special command >> for using the HaTeX library, you will be able to write Haskell >> code that generates LaTeX code. Find more details in the >> haskintex documentation page: >> >> http://daniel-diaz.github.io/projects/haskintex >> >> # What's new? >> >> One of the main issues when evaluating Haskell code with >> haskintex was that haskintex was not aware of sandbox >> environments, so it had to rely on user or global package >> databases. From version 0.6.0.0, haskintex can now detect and use >> sandbox package databases, with no additional effort required >> from you. The -nosandbox flag has been added in case you still >> want the old behavior. >> >> Another addition is the -autotexy flag. Without the flag, every >> expression contained in a \hatex command is required to have type >> LaTeX. When the flag is enabled, this restriction is relaxed to >> any type that is an instance of the Texy typeclass. This >> typeclass contains instances for types that can be rendered to >> LaTeX syntax. Could be some text, numbers, or even matrices. You >> can create your own instances too. >> >> Suggestions, bugs, questions? Head to the haskintex issue tracker: >> >> https://github.com/Daniel-Diaz/haskintex/issues >> >> Happy texing, >> Daniel D?az. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Sat Oct 10 00:58:46 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sat, 10 Oct 2015 11:58:46 +1100 Subject: [Haskell-cafe] ANNOUNCE: unordered-graphs Message-ID: I have a relatively hacked-together graph library that uses unordered-containers as a backend available if anyone finds it interesting/useful: http://hackage.haskell.org/package/unordered-graphs It's primarily developed just for my own needs and thus I'm not sure how much future work I'll be doing on it, but I'm willing to accept pull requests. This library was semi-experimental in that I also tried a few things out with it: * Polymorphic node type * Fixed auto-generated edge type: this is because (node,node, label) triples (ala fgl) do not provide sufficient information to be able to distinguish between multiple edges, etc. * Type parameter to determine whether the graph is directed or undirected. * Typeclass to allow you to determine the type/output of a a match (I didn't end up actually using this, as the one time I needed to do a match I found the extra polymorphism caused problems; it also isn't comprehensive as I didn't write all that many instances.) -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ekmett at gmail.com Sat Oct 10 19:13:26 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Oct 2015 15:13:26 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On Tue, Oct 6, 2015 at 3:02 PM, Malcolm Wallace wrote: > > On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote: > > At the risk of stating the obvious: I don't think it matters from which > > group a given argument comes from as its validity doesn't depend on the > > messenger. > > In that case, I think you are misunderstanding the relevance of Johan's > argument here. Let me try to phrase it differently. Some people who can > reasonably claim to have experience with million-line plus codebases are > warning that this change is too disruptive, and makes maintenance harder > than it ought to be. On the other hand, of the people who say the change > is not really disruptive, none of them have (yet?) made claims to have > experience of the maintenance of extremely large-scale codebases. Very well. Let me offer a view from the "other side of the fence." I personally maintain about 1.3 million lines of Haskell, and over 120 packages on hackage. It took me less than a half a day to get everything running with 7.10, and about two days to build -Wall clean. In that first day I actually had to spend vastly more time fixing things related to changes in Typeable, template-haskell and a tweaked corner case in the typechecker than anything AMP/FTP related. In the end I had to add two type signatures. Most of the patches to go -Wall clean looked like +#if __GLASGOW_HASKELL__ < 710 import Control.Applicative import Data.Monoid +#endif Maybe 10% were more complicated. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Oct 10 19:16:10 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Oct 2015 15:16:10 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87lhbfm8qu.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <87lhbfm8qu.fsf@gnu.org> Message-ID: On Wed, Oct 7, 2015 at 3:35 AM, Herbert Valerio Riedel wrote: > --8<---------------cut here---------------start------------->8--- > import Control.Applicative as A (Applicative(..)) > > data Maybe' a = Nothing' | Just' a > > instance Functor Maybe' where > fmap f (Just' v) = Just' (f v) > fmap _ Nothing' = Nothing' > > instance A.Applicative Maybe' where > pure = Just' > f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1) > > instance Monad Maybe' where > Nothing' >>= _ = Nothing' > Just' x >>= f = f x > > return = pure -- "deprecated" since GHC 7.10 > --8<---------------cut here---------------end--------------->8--- > > Alternately, import Control.Applicative import Prelude data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance Applicative Maybe' where > -- hvr > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Oct 10 19:25:37 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Oct 2015 15:25:37 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: The part of the MRP proposal that I actively care about because it fixes a situation that *actually causes harm* is moving (>>) to the top level. Why? Right now (*>) and (>>) have different default definitions. This means that code runs often with different asymptotics depending on which one you pick. Folks often define one but not the other. This means that the performance of mapM_ and traverse_ needlessly differ. It means that we can't simply weaken the type constraint on mapM_ and sequence_ to Applicative, it as a knock-on consequence it means we can't migrate mapM and sequence out of Traversable to top level definitions and thereby simply provide folks with more efficient parallelizable mapping when they reach for the 'obvious tool'. return itself lurking in the class doesn't matter to me all that much as it doesn't break anybody's asymptotics and it already has a sensible definition in terms of pure as a default, so effectively you can write code as if MRP was already in effect today. It is a wart, but one that could be burned off on however long a time table we want if we choose to proceed. -Edward On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner wrote: > > On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink > wrote: > >> While I don't think it detracts from your argument, it seems you >> misread the original proposal. At no point will it remove `return` >> completely. It would be moved out of the `Monad` class and be made >> into a top-level definition instead, so you would still be able to use >> it. >> > > Then why bother? > If you don't intend to regard code that uses "return" as old, out-dated, > in need of updating, etc.... > If you don't intend to correct people on #haskell to use pure instead of > return... > If you don't tsk tsk all mentions of it in books.... > If you don't intend to actually deprecate it. > Why bother? > > But seriously, why do you think that "you would still be able to use it"? > That is true for only the simplest of code - and untrue for anyone who has > a library that defines a Monad - or anyone who has a library that they want > to keep "up to date". Do you really want to have a library where all your > "how to use this" code has return in the examples? Shouldn't now be pure? > Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown > in Hackage? This is just a nightmare for a huge number of libraries, and > especially many commonly used ones. > > Why bother! > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Oct 10 19:33:37 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Oct 2015 15:33:37 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On Tue, Oct 6, 2015 at 1:41 PM, Sven Panne wrote: > 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel : > >> [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings >> > across multiple GHC versions is not considered a show-stopper. >> > > That's your personal POV, I'm more leaning towards "-Wall -Werror". I've > seen too many projects where neglecting warning over an extended period of > time made fixing them basically impossible at the end. Anyway, I think that > a sane ecosystem should allow *both* POVs, the sloppy one and the strict > one. > Note: You haven't been able to upload a package that has -Werror turned on in the cabal file for a couple of years now -- even if it is only turned on on the test suite, so any -Werror discipline you choose to enforce is purely local. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Sat Oct 10 20:12:11 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sat, 10 Oct 2015 23:12:11 +0300 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: <1444507931.2047.14.camel@gmail.com> On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote: > The part of the MRP proposal that I actively care about because it > fixes a > situation that *actually causes harm* is moving (>>) to the top > level. Sorry if I'm missing something, but moving (>>) is not part of the proposal. At least it is not mentioned on the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn Is the wiki outdated? > return itself lurking in the class doesn't matter to me all that much > as it > doesn't break anybody's asymptotics and it already has a sensible > definition in terms of pure as a default, so effectively you can > write code > as if MRP was already in effect today. It is a wart, but one that > could be > burned off on however long a time table we want if we choose to > proceed. So the cost of not moving `return` to the top level is zero? For me the cost of moving it is pretty small, just an hour or two. Probably recompiling all the dependencies when switching to newer version of GHC will take longer. (Actually I'm still using 7.8 at work.) But the cost is definitely nonzero. The proposal (as written on the wiki page) provides two arguments for the change: There is no reason to include `return` into the next standard. That is true. But we can leave `return` is `GHC` as a compiler specific extension for backward compatibility, can't we? The second argument is `ApplicativeDo`, but I don't see the point. Breaking existing code "in order to benefit existing code" looks a bit strange. Could someone please clarify what is the cost of not moving `return` out of `Monad`? Sorry if it is already answered somewhere else, it is hard to find anything in such the huge email thread. Thanks, Yuras. From ekmett at gmail.com Sat Oct 10 20:39:10 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Oct 2015 16:39:10 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <1444507931.2047.14.camel@gmail.com> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <1444507931.2047.14.camel@gmail.com> Message-ID: On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich wrote: > On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote: > > The part of the MRP proposal that I actively care about because it > > fixes a > > situation that *actually causes harm* is moving (>>) to the top > > level. > > Sorry if I'm missing something, but moving (>>) is not part of the > proposal. At least it is not mentioned on the wiki page: > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn > > Is the wiki outdated? > It arose during the original thread discussing the MRP but wasn't included in the 'proposal as written' that was sent out. https://mail.haskell.org/pipermail/libraries/2015-September/026129.html In many ways that proposal would do better 'on its own' than as part of the MRP. > return itself lurking in the class doesn't matter to me all that much > > as it > > doesn't break anybody's asymptotics and it already has a sensible > > definition in terms of pure as a default, so effectively you can > > write code > > as if MRP was already in effect today. It is a wart, but one that > > could be > > burned off on however long a time table we want if we choose to > > proceed. > > So the cost of not moving `return` to the top level is zero? > > For me the cost of moving it is pretty small, just an hour or two. > Probably recompiling all the dependencies when switching to newer > version of GHC will take longer. (Actually I'm still using 7.8 at > work.) But the cost is definitely nonzero. > > The proposal (as written on the wiki page) provides two arguments for > the change: > > There is no reason to include `return` into the next standard. That is > true. Nobody is saying that we should remove return from the language. The proposal was to move it out of the class -- eventually. Potentially on a very very long time line. But we can leave `return` is `GHC` as a compiler specific extension for > backward compatibility, can't we? > This is effectively the status quo. There is a default definition of return in terms of pure today. The longer we wait the more tenable this proposal gets in many ways as fewer and fewer people start trying to support compilers versions below 7.10. Today isn't that day. There are some niggling corner cases around viewing its continued existence as a compiler "extension" though, even just around the behavior when you import the class with Monad(..) you get more or less than you'd expect. Could someone please clarify what is the cost of not moving `return` out of > `Monad`? > The cost of doing nothing is maintaining a completely redundant member inside the class for all time and an ever-so-slightly more expensive dictionaries for Monad, so retaining return in the class does no real harm operationally. While I'm personally somewhat in favor of its eventual migration on correctness grounds and believe it'd be nice to be able to justify the state of the world as more than a series of historical accidents when I put on my libraries committee hat I have concerns. I'm inclined to say at the least that IF we do decide to proceed on this, at least the return component should be on a long time horizon, with a clock tied to the release of a standard, say a Haskell2020. I stress IF, because I haven't had a chance to go through and do any sort of detailed tally or poll to get a sense of if there is a sufficient mandate. There is enough of a ruckus being raised that it is worth proceeding cautiously if we proceed at all. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.kholomiov at gmail.com Sat Oct 10 21:53:02 2015 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Sun, 11 Oct 2015 00:53:02 +0300 Subject: [Haskell-cafe] Monads for Drummers! Yet another monad tutorial with pictures! Message-ID: Yes! It's another monad tutorial. I've tried hard not to do it but finally it came out. I wrote a book on Haskell in Russian. It's a translation of the chapter that is dedicated to monads. I was convinced by friends to publish it. The monads are explained with pictures and Kleisli categories. Hope this can help to someone to grasp the monad concept. ------------------------------------- ps: pictures were made with diagrams Thank you for being kind with my awkward English! -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.kholomiov at gmail.com Sat Oct 10 21:53:20 2015 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Sun, 11 Oct 2015 00:53:20 +0300 Subject: [Haskell-cafe] Monads for Drummers! Yet another monad tutorial with pictures! In-Reply-To: References: Message-ID: https://github.com/anton-k/monads-for-drummers 2015-10-11 0:53 GMT+03:00 Anton Kholomiov : > Yes! > > It's another monad tutorial. I've tried hard not to do it but finally it > came out. > > I wrote a book on Haskell in Russian. It's a translation of the chapter > that is dedicated to monads. I was convinced by friends to publish it. > > The monads are explained with pictures and Kleisli categories. > Hope this can help to someone to grasp the monad concept. > > ------------------------------------- > > ps: pictures were made with diagrams > > Thank you for being kind with my awkward English! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From defigueiredo at ucdavis.edu Sun Oct 11 02:09:57 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Sat, 10 Oct 2015 20:09:57 -0600 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: <5617E178.9000506@stilo.com> References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> Message-ID: <5619C4F5.3060800@ucdavis.edu> We write software in teams. Most software development (or at least a large fraction of it) requires that more than one person work on the same codebase simultaneously. This means that in most software development there will *necessarily* be code merges. Every time we merge our work, on branch A, with that of others, on branch B, using git or most other tools we are doing a simple line-based merge on text files. This kind of merge can produce an output that introduces bugs that were not present on either branch A or B even if there are no conflicts. This is terrible! This "merge tool" can create bugs by itself out of thin air! Can we have a better merge tool? Ideally, I would like a merge tool to work like a compiler: If there are no conflicts, the merge tool guarantees the merge introduces no new bugs (other than those already found in A or B). In other words, the output of the merge tool is "merge bug free", if there are no conflicts. Unfortunately, this is rather tall order. Previous research found that for many languages it is impossible to write such a tool [1]. However, this may be asking the wrong question. Let's take a different point of view. Let's assume there will be software merges (and therefore that merge tools will be used in software development), here are better questions to ask: 1. How does the desire for a "compiler-like" merge tool constrain language design? Can we design a language for which such a merge tool is possible? 2. If it is not possible to get the guarantee that no bugs will be introduced during the merge process, what guarantees can we get? Can we at least get that at the module level? Does that constrain the available design space? Specializing those to Haskell: 1. Can we write a "compiler-like" merge tool for Haskell? 2. If not, can we tweak Haskell so that the existence of such a tool becomes possible? Can we at least get that at the module level? Cheers, Dimitri [1] D. Binkley, S. Horwitz, and T. Reps. 1995. Program integration for languages with procedure calls. /ACM Trans. Softw. Eng. Methodol./ 4, 1 (January 1995), 3-35. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Sun Oct 11 06:17:35 2015 From: sean.leather at gmail.com (Sean Leather) Date: Sun, 11 Oct 2015 08:17:35 +0200 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: <5619C4F5.3060800@ucdavis.edu> References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> Message-ID: On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote: > Can we write a "compiler-like" merge tool for Haskell? Merge could be considered to be a combination of diff and patch. And so you might want to merge ASTs, which are typically families of datatypes. Related: Type-Safe Diff for Families of Dataypes: http://www.andres-loeh.de/gdiff-wgp.pdf Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Sun Oct 11 09:49:39 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sun, 11 Oct 2015 12:49:39 +0300 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <1444507931.2047.14.camel@gmail.com> Message-ID: <1444556979.2047.27.camel@gmail.com> On Sat, 2015-10-10 at 16:39 -0400, Edward Kmett wrote: > On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich < > shumovichy at gmail.com> > wrote: > > > There is no reason to include `return` into the next standard. That > > is > > true. > > > Nobody is saying that we should remove return from the language. The > proposal was to move it out of the class -- eventually. Potentially > on a > very very long time line. Yes, I meant there were no reason to include `return` into `Monad` class in the next standard. > There are some niggling corner cases around viewing its continued > existence > as a compiler "extension" though, even just around the behavior when > you > import the class with Monad(..) you get more or less than you'd > expect. Indeed that is a good argument. > The cost of doing nothing is maintaining a completely redundant > member > inside the class for all time Well, it is just a single line of code. Of course, as any other technical dept, it can beat you later, e.g. it can make some other modification harder. But in the worst case it will cost one more deprecation circle. > and an ever-so-slightly more expensive > dictionaries for Monad Do you mean that moving `return` to the top level will give us noticeable performance improvement? > so retaining return in the class does no real harm > operationally. IMO that is the reason for the "ruckus". Thank you for the detailed answer. Yuras > > While I'm personally somewhat in favor of its eventual migration on > correctness grounds and believe it'd be nice to be able to justify > the > state of the world as more than a series of historical accidents when > I put > on my libraries committee hat I have concerns. > > I'm inclined to say at the least that IF we do decide to proceed on > this, > at least the return component should be on a long time horizon, with > a > clock tied to the release of a standard, say a Haskell2020. I stress > IF, > because I haven't had a chance to go through and do any sort of > detailed > tally or poll to get a sense of if there is a sufficient mandate. > There is > enough of a ruckus being raised that it is worth proceeding > cautiously if > we proceed at all. > > -Edward From hvr at gnu.org Sun Oct 11 21:27:13 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 11 Oct 2015 23:27:13 +0200 Subject: [Haskell-cafe] Final Call for Haskell Prime language committee Nominations! In-Reply-To: <87wpvh8ksg.fsf@gmail.com> (Herbert Valerio Riedel's message of "Wed, 23 Sep 2015 12:58:07 +0200") References: <87wpvh8ksg.fsf@gmail.com> Message-ID: <87twpxjdu6.fsf@gmail.com> The submission deadline (Wed, Oct 14 23:59:59 UTC 2015) for Haskell Prime self-nominations (see also original CfN at [1]) is near! If you have already submitted a self-nomination, please make sure (if it was sent to the haskell-prime list) that it shows up in the mailing list archives at - https://mail.haskell.org/pipermail/haskell-prime/2015-September/ or - https://mail.haskell.org/pipermail/haskell-prime/2015-October/ or (if you have only sent it to me directly) that I acknowledged receiving your submission by an email reply. Regards, Herbert Valerio Riedel [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html From roconnor at theorem.ca Sun Oct 11 23:11:15 2015 From: roconnor at theorem.ca (roconnor at theorem.ca) Date: Sun, 11 Oct 2015 16:11:15 -0700 (PDT) Subject: [Haskell-cafe] ANNOUNCE: mezzolens 0.0.0 & a puzzle Message-ID: This is a pre-release of mezzolens, a library of first-order functional references based purely on profunctors. I wrote it because https://www.reddit.com/user/Faucelme asked for one. You can find it at https://hackage.haskell.org/package/mezzolens The main purpose of this pre-release is to provide background for framing the following question: In a pure profunctor lens libray, how do you write choosing and beside in such a way that it supports all the following types? choosing :: Lens ta tb a b -> Lens sa sb a b -> Lens (Either ta sa) (Either sa sb) a b choosing :: Traversal ta tb a b -> Travesal sa sb a b -> Traversal (Either ta sa) (Either sa sb) a b choosing :: SEC ta tb a b -> SEC sa sb a b -> SEC (Either ta sa) (Either sa sb) a b beside :: Traversal ta tb a b -> Travesal sa sb a b -> Traversal (Either ta sa) (Either sa sb) a b beside :: SEC ta tb a b -> SEC sa sb a b -> SEC (Either ta sa) (Either sa sb) a b One sufficent solution for choosing would be to write a single function that combines lensVL :: (forall f. Functor f => (a -> f b) -> ta -> f tb) -> Lens ta tb a b traversal :: (forall f. Applicative f => (a -> f b) -> ta -> f tb) -> Traversal ta tb a b into one. The obvious approach is to write an suitable adaptor that transforms any (strong) profunctor into a functor, and if the profunctor is wandering, it produces an applicative functor. But I haven't been able to devise such a suitable adaptor. -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' From jeffbrown.the at gmail.com Mon Oct 12 00:10:29 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sun, 11 Oct 2015 17:10:29 -0700 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> Message-ID: +1 for AST merge. Writing code from text is reasonable, but storing code as text is lunacy. On Sat, Oct 10, 2015 at 11:17 PM, Sean Leather wrote: > On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote: > >> Can we write a "compiler-like" merge tool for Haskell? > > > Merge could be considered to be a combination of diff and patch. And so > you might want to merge ASTs, which are typically families of datatypes. > Related: Type-Safe Diff for Families of Dataypes: > http://www.andres-loeh.de/gdiff-wgp.pdf > > Regards, > Sean > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Jeffrey Benjamin Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkoster at gmail.com Mon Oct 12 00:45:20 2015 From: tkoster at gmail.com (Thomas Koster) Date: Mon, 12 Oct 2015 11:45:20 +1100 Subject: [Haskell-cafe] A GC'd heap using weak pointers In-Reply-To: References: Message-ID: On 6 October 2015 at 21:25, Thomas Koster wrote: > I am implementing a simple, interpreted language that needs a garbage- > collected heap for storage. Like most discussions on memory management, > I use the term "heap" by analogy - the actual data structure is not > necessarily a true heap. > > My Heap type is basically a map of "addresses" (Int) to values. Values > may themselves contain addresses, perhaps recursively to each other > (like letrec). The extra field in Heap stores the next unused address, > used to allocate fresh slots, as you can see in "heapAlloc". > >> type Address = Int >> data Value = ...things with Addresses... >> data Heap = Heap !Address (Map Address Value) >> >> heapAlloc :: Heap -> (Address, Heap) >> heapAlloc (Heap nextFreeAddr binds) = >> (nextFreeAddr, Heap (succ nextFreeAddr) binds) > > There is also a stack of roots and an expression under evaluation. > >> type Stack = [...things with Addresses...] >> data Expr = ...things with Addresses... > > The function I need to write is: > >> heapGC :: [Address] -> Heap -> Heap >> heapGC roots heap = ...collect unreachable values from heap... > > Rather than re-invent this particularly complex wheel, I am wondering > if I could use GHC weak pointers and have the GHC runtime collect values > in my heap for me. Something like this: > >> type Address = Int >> data Reference = Reference Address >> data Value = ...things with References... >> data Heap = Heap !Address (Map Address (Weak Value)) >> >> heapAlloc :: Heap -> (Reference, Heap) >> heapAlloc (Heap nextFreeAddr binds) = >> (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds) >> >> heapStore :: Reference -> Value -> Heap -> IO Heap >> heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do >> weakVal <- mkWeak ref val Nothing >> return $ Heap nextFreeAddr (Map.insert addr weakVal binds) > > Note the new type, Reference. This replaces Address everywhere except > in the heap's internal structure, which continues to use Address. > Reference values are opaque, unique and obtained from the heap using > heapAlloc. > > The idea is that only two things should cause Values to stay alive: > 1. reachable holders of Reference (by GHC's definition of "reachable"), > 2. ordinary Haskell closures arising from stepping the interpreter. > "Being in the Heap" should not be enough to keep a Value alive. Then, > my heapGC function should only have to prune dead addresses from the > map. > > I am having trouble getting a proof-of-concept working (I am unable to > observe any finalizers running, ever), but before I get into that, is > this idea sound? Has somebody else implemented this in a library > already? On 6 October 2015 at 21:39, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote: > This would be well recieved on ghc-devs mailing list. Adding to cc. Maybe. My question has nothing to do with the development of GHC itself. Perhaps I should have been more clear - I am implementing this interpreter as a straightforward Haskell program. I apologize to ghc-devs if this is inbox noise to them. To be clear, I will re-state my question another way. I am writing an interpreter for a simple programming language in Haskell. The interpreter needs to implement a garbage-collected storage area (heap). At this stage, my "Heap" is actually just a "Map Address Value", plus some administrative fields. Some of the constructors of Value contain Addresses. Address is just a newtype for Int. I am faced with the problem of removing unreachable Values from this map to fix unbounded space usage. My question is: Rather than traverse the graph of values and re-invent a true garbage collector, can I change this to "Map Address (Weak Value)" (Weak from System.Mem.Weak) and have the Haskell runtime reclaim unreachable Values for me? My original post (quoted above) has more detail on what I attempted (but it doesn't work - as far as I can tell nothing is ever reclaimed). Thanks, -- Thomas Koster From ratzes at gmail.com Mon Oct 12 00:58:53 2015 From: ratzes at gmail.com (Charles Durham) Date: Sun, 11 Oct 2015 20:58:53 -0400 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> Message-ID: 1. If you have a merge take place in two lines right next to each other, say one variable is declared in one and a function processes that variable in another, if those two are responsible together for exiting a loop, then you're going to be solving the Halting Problem to show there are no bugs. 2. If you have one function "f(x) = a + bx + cx^2 +..." and another function that iterates through integers until a solution is found in integers, then if the internals of either is changed (either the constants in f, or the search strategy), then you're going to have to be solving "Hilberts 10th Problem" to understand that there are no bugs introduced, thought this was interesting as the changes are "further" apart. At least for the general case, this should be a problem for all Turing Complete languages. It might be interesting to think about finding sections of code that are "Total", and perhaps put certain guarantees on that, but there still might be weird ways that two lines of code can play with each other beyond that. I hope this isn't overly pedantic, or that I'm not completely off base. On Sun, Oct 11, 2015 at 8:10 PM, Jeffrey Brown wrote: > +1 for AST merge. Writing code from text is reasonable, but storing code > as text is lunacy. > > On Sat, Oct 10, 2015 at 11:17 PM, Sean Leather > wrote: > >> On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote: >> >>> Can we write a "compiler-like" merge tool for Haskell? >> >> >> Merge could be considered to be a combination of diff and patch. And so >> you might want to merge ASTs, which are typically families of datatypes. >> Related: Type-Safe Diff for Families of Dataypes: >> http://www.andres-loeh.de/gdiff-wgp.pdf >> >> Regards, >> Sean >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > -- > Jeffrey Benjamin Brown > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.raga at gmail.com Mon Oct 12 12:34:54 2015 From: alexey.raga at gmail.com (Alexey Raga) Date: Mon, 12 Oct 2015 12:34:54 +0000 Subject: [Haskell-cafe] GHC 7.10.2 Stage 1 compiler Message-ID: Hello, On the "Download" page (https://www.haskell.org/ghc/download_ghc_7_10_2) I see the archive with the binaries for ARM. Unfortunately this archive doesn't seem to include stage 1 compiler (which would be a cross-compiler from x86 or x64 to ARM as far as I understand). I am trying to build one myself, but unfortunately no luck so far. Is it possible to know the detailed instructions on how the existing ARM package has been built? A script or a dockerfile would be ideal. I could tune that build and make a docker container that could cross-compile x64 -> ARM... Regards, Alexey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.j.thompson at kent.ac.uk Mon Oct 12 13:55:32 2015 From: s.j.thompson at kent.ac.uk (Simon Thompson) Date: Mon, 12 Oct 2015 14:55:32 +0100 Subject: [Haskell-cafe] CFP: Workshop on Real World Domain Specific Languages, March 2016 Message-ID: <57F1B9D7-FD15-4D3C-ACB8-FB0EA1AD1BA8@kent.ac.uk> CALL FOR PAPERS ================================= Workshop on Real World Domain Specific Languages https://sites.google.com/site/realworlddsl In conjunction with The International Symposium on Code Generation and Optimisation 2016. http://cgo.org/cgo2016 Barcelona, 12-13 March, 2016 ================================= As the use of computers proliferates, the complexity and variety of systems continues to grow. As a result, it is becoming increasingly inflexible to "hard wire? behaviours into software. Software developers can enable more control over their software configurations by exploiting Domain Specific Languages (DSLs). Such DSLs provide a systematic way to structure the underlying computational components: to coin a phrase, a DSL is a library with syntax. There is an enormous variety of DSLs for a very wide range of domains. Most DSLs are highly idiosyncratic, reflecting both the specific natures of their application domains and their designers? own preferences. This workshop will bring together constructors of DSLs for ?real world? domains; that is, DSLs intended primarily to aid in building software to solve real world problems rather than to explore the more theoretical aspects of language design and implementation. We are looking for submissions that present the motivation, design, implementation, use and evaluation of such DSLs. ================================= Key Dates: ---------------- Paper submission deadline: 10 January 2016. Author notification: 2 February 2016. Final manuscript due: 21 February 2016. Workshop: 12-13 March 2016. ---------------- Submission Instructions: The EasyChair submission page for this workshop is https://easychair.org/conferences/?conf=rwdsl16 Accepted submissions will be published in the ACM Digital Library within its International Conference Proceedings Series. Submissions should be 8-10 in ACM double-column format. Authors should follow the information for formatting ACM SIGPLAN conference papers, which can be found at http://www.sigplan.org/Resources/Author. We will provide more details of the submissions format and process at the beginning of November. ================================= Program Chairs Rob Stewart, Heriot-Watt University Greg Michaelson, Heriot-Watt University PC Members Jost Berthold, Commonwealth Bank of Australia Andy Gill, University of Kansas Kevin Hammond, University of St Andrews Rita Loogen, Philipps Universitat Marburg Patrick Maier, University of Glasgow Josef Svenningsson, Chalmers University Simon Thompson, University of Kent Phil Trinder, University of Glasgow Contact Please email inquiries concerning the workshop to: R.Stewart at hw.ac.uk Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt From defigueiredo at ucdavis.edu Mon Oct 12 19:20:29 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Mon, 12 Oct 2015 13:20:29 -0600 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> Message-ID: <561C07FD.5070304@ucdavis.edu> I think both these examples strengthen my argument! :-) There is no problem at all in the second and the first one precisely show us a situation when we would like to know there is a conflict. The guarantee I want is that when merging 2 branches A and B: *If there are no conflicts*, the merge tool guarantees the merge output introduces no new bugs *other than those already found in A or B*. Note: 1. we get to define what a conflict is and 2. we don't care if the bugs were already present in either branch. On the first example, I assume both branches A and B will compile and run before the merge so that we are really only changing the value of the variable on branch A and the definition of the function on branch B (otherwise the branches would not compile before the merge). Because the definition of the function depends on a *specific* value the variable, there is no way to avoid declaring a conflict. But notice that in the more general case where the function puts that value as a parameter there is no conflict, because if there were a bug it would already be present in branch B. So, the merge process is not introducing any bugs by itself. This is exactly what happens in the second example. I assume branch A provides the new definition of f(x) and that in branch B we change the search strategy in the search function g. However, I assume that g would take f as a parameter g:: (Integer -> Integer) -> Integer. In this case, if there were a bug in g in the merged output, then it would already be present in branch B before the merge. Therefore, there is no conflict at all here. In summary, there is no conflict on the second example and I would like to know about the conflict due to the global dependency on the first one. Dimitri On 10/11/15 6:58 PM, Charles Durham wrote: > 1. If you have a merge take place in two lines right next to each > other, say one variable is declared in one and a function processes > that variable in another, if those two are responsible together for > exiting a loop, then you're going to be solving the Halting Problem to > show there are no bugs. > > 2. If you have one function "f(x) = a + bx + cx^2 +..." and another > function that iterates through integers until a solution is found in > integers, then if the internals of either is changed (either the > constants in f, or the search strategy), then you're going to have to > be solving "Hilberts 10th Problem" to understand that there are no > bugs introduced, thought this was interesting as the changes are > "further" apart. > > At least for the general case, this should be a problem for all Turing > Complete languages. It might be interesting to think about finding > sections of code that are "Total", and perhaps put certain guarantees > on that, but there still might be weird ways that two lines of code > can play with each other beyond that. > > I hope this isn't overly pedantic, or that I'm not completely off base. > > On Sun, Oct 11, 2015 at 8:10 PM, Jeffrey Brown > > wrote: > > +1 for AST merge. Writing code from text is reasonable, but > storing code as text is lunacy. > > On Sat, Oct 10, 2015 at 11:17 PM, Sean Leather > > wrote: > > On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote: > > Can we write a "compiler-like" merge tool for Haskell? > > > Merge could be considered to be a combination of diff and > patch. And so you might want to merge ASTs, which are > typically families of datatypes. Related: Type-Safe Diff for > Families of Dataypes: http://www.andres-loeh.de/gdiff-wgp.pdf > > Regards, > Sean > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > -- > Jeffrey Benjamin Brown > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Mon Oct 12 20:16:13 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Mon, 12 Oct 2015 21:16:13 +0100 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: <5619C4F5.3060800@ucdavis.edu> References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> Message-ID: Hi, I work on a team of ~15 developers and we follow a merge-free process using rebasing. Although in theory it sounds like you'll get the same problems with rebasing as with merging, over 6 years and 100,000+ commits I'm struggling to think of a single bug silently introduced due to a rebase that succeeded without conflicts. It's a cunning bit of social engineering: when merging the work of two developers, it's easy for both of them to disclaim responsibility for any bugs introduced by the merge, but when rebasing the work of developer A on top of that of developer B it's clear that any bugs are dev A's responsibility as their commits come later in the published history than dev B's, and this gives dev A the incentive to check for semantic conflicts properly. That said, it's theoretically possible to introduce bugs with a 'clean' rebase, just as with merging, and I'm interested in your suggestion because of that. The difficulty I see is defining what you mean by "no new bugs". The two branches satisfy two different specifications, and my reading of "no new bugs" is that the merge result satisfies a merged specification. It sounds difficult to automatically merge two specs together in general, although in practice specs are often quite informal and where a rebase looks questionable a merged spec can be invented and verified with human intervention, remembering that the rebasing developer has a personal incentive to get this right. There's two kind of formal spec that I know of in common usage in the industry: types and tests. Using a type system gives you a bunch of theorems about what your program can and cannot do, and this is checked at compile time, and an automated test suite is basically a bunch of properties that your program satisfies which can be verified by running the test suite. Neither of these can capture the real spec exactly, but in practice they turn out to be good enough for many purposes. For those cases where that's not enough you can bring out the heavy artillery of a theorem prover, and this does let you write down the real spec exactly and verify it either side of a merge or rebase. I wouldn't say that approach was in common usage but it does get used where the investment is worth it. Verifying that changes to the type system leave the real spec satisfied sounds quite hard in general. Merging additions to the test suite sounds easy but other changes to the part of the spec embodied in the test suite also sounds hard in general. Of the three, merging changes to an automatically-proved theorem actually feels easiest - my experience is that keeping a (well-written) automatic proof in sync with changes to code is often not that hard, and when it is hard it's normally been because the changes to the code meant the theorem was no longer true. Perhaps enriching the type system to a point where you can write truly useful specs in it is the answer? Thus dependent types. Cheers, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Tue Oct 13 08:41:05 2015 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Tue, 13 Oct 2015 01:41:05 -0700 Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build problems Message-ID: Hello, I stumbled across hoq and it sounds very interesting to me. However, it has build problems now enumerated in the official build reports. I was thinking to investigate and possibly fix these build problems. However, when I run "cabal configure", I already ran into a problem: "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'" I have been trying to track this down. Not sure how to fix this. Any help?? Regards, Vasily From andreas.abel at ifi.lmu.de Tue Oct 13 17:22:30 2015 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Tue, 13 Oct 2015 19:22:30 +0200 Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build problems In-Reply-To: References: Message-ID: <561D3DD6.1060101@ifi.lmu.de> This worked for me: git clone git at github.com:valis/hoq.git cd hoq cabal install $ cabal --version cabal-install version 1.22.4.0 using version 1.22.2.0 of the Cabal library $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 Cheers, Andreas On 13.10.2015 10:41, Vasili I. Galchin wrote: > Hello, > > I stumbled across hoq and it sounds very interesting to me. > However, it has build problems now enumerated in the official build > reports. I was thinking to investigate and possibly fix these build > problems. > > However, when I run "cabal configure", I already ran into a problem: > > "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'" > > I have been trying to track this down. Not sure how to fix this. Any help?? > > Regards, > > Vasily > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From byorgey at gmail.com Tue Oct 13 17:59:24 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Tue, 13 Oct 2015 17:59:24 +0000 Subject: [Haskell-cafe] [Announce] haskintex-0.6.0.0 In-Reply-To: <56185AF9.6080708@gmail.com> References: <56181637.30607@gmail.com> <56185AF9.6080708@gmail.com> Message-ID: You can easily have a standalone Haskell file when using `diagrams-latex`. All you have to do is \begin{diagram}[width=100] import StandaloneHaskellFile dia = someDiagramDefinedThere \end{diagram} -Brent On Fri, Oct 9, 2015 at 7:25 PM Andrey Chudnov wrote: > Thanks, Ryan. The tutorial is really good and to-the-point. > > By the way, it looks like haskintex has a more general approach to > integrating Haskell in LaTeX. It seems that in principle it could just use > that to enable including diagrams in latex, without `diagrams-latex`. > > And the same question about including a Haskell source instead of inlining > applies. To me, having a standalone Haskell file is superior since I can > get syntax highlighting, typechecking and even quick REPL debugging of > diagrams that way. While with the inlined one needs to re-pdflatex the > whole thing to get type errors (do they even show up in the latex output?) > and reflect the changes. I guess, that could be done with the PGF backend > for diagrams and a suitable Makefile, though. > > > On 10/09/2015 07:48 PM, Ryan Yates wrote: > > You can incorporate diagrams from the `diagrams` package inline in LaTeX > using diagrams-builder. We have a tutorial written up here: > > http://projects.haskell.org/diagrams/doc/latex.html > > I imagine haskintex has a more sophisticated technique and it would be > interesting to integrate diagrams with that approach too. > > Ryan > > On Fri, Oct 9, 2015 at 3:32 PM, Andrey Chudnov wrote: > >> Daniel, >> Can this be used in conjunction with the `diagrams` package to generate >> diagrams in LaTeX instead of suffering through Tikz? >> Is it possible to include a Haskell source file instead of inlining it in >> the tex file? >> >> >> On 10/09/2015 12:33 PM, Daniel D?az Casanueva wrote: >> >> Dear Haskell users, >> >> I just released a new version of haskintex, the program that runs Haskell >> code inside LaTeX documents. >> >> http://hackage.haskell.org/package/haskintex >> >> # More about haskintex >> >> For those who don't know the program yet, _haskintex_ is a tool that >> executes Haskell code inside LaTeX documents, creating a new LaTeX document >> where each Haskell expression has been replaced by its result. Furthermore, >> since haskintex has a special command for using the HaTeX library, you will >> be able to write Haskell code that generates LaTeX code. Find more details >> in the haskintex documentation page: >> >> http://daniel-diaz.github.io/projects/haskintex >> >> # What's new? >> >> One of the main issues when evaluating Haskell code with haskintex was >> that haskintex was not aware of sandbox environments, so it had to rely on >> user or global package databases. From version 0.6.0.0, haskintex can now >> detect and use sandbox package databases, with no additional effort >> required from you. The -nosandbox flag has been added in case you still >> want the old behavior. >> >> Another addition is the -autotexy flag. Without the flag, every >> expression contained in a \hatex command is required to have type LaTeX. >> When the flag is enabled, this restriction is relaxed to any type that is >> an instance of the Texy typeclass. This typeclass contains instances for >> types that can be rendered to LaTeX syntax. Could be some text, numbers, or >> even matrices. You can create your own instances too. >> >> Suggestions, bugs, questions? Head to the haskintex issue tracker: >> >> https://github.com/Daniel-Diaz/haskintex/issues >> >> Happy texing, >> Daniel D?az. >> >> >> _______________________________________________ >> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.glushenkov at gmail.com Tue Oct 13 19:43:31 2015 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Tue, 13 Oct 2015 21:43:31 +0200 Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build problems In-Reply-To: References: Message-ID: Hi, On 13 October 2015 at 10:41, Vasili I. Galchin wrote: > [...] > "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'" > [...] Upgrading to a newer GHC and/or cabal-install should fix this, I think. Which versions of GHC/cabal-install are you using? What is the output of 'cabal configure -v3'? From defigueiredo at ucdavis.edu Tue Oct 13 20:08:14 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Tue, 13 Oct 2015 14:08:14 -0600 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> Message-ID: <561D64AE.8030308@ucdavis.edu> The 6 years and 100K+ commits data point is pretty impressive! It makes me question how much effort should be devoted to avoiding these "merge-introduced" bugs in the first place. I assume this data point does not capture bugs introduced by merges that were found by unit tests though. I hadn't looked at how to actually go about writing the "bug-free" merge tool (if it becomes possible to write one). However, I think my immediate approach would be different from your suggestion. I was thinking that we could just look at the dependency graph between the definitions. Consider 2 possible (previously suggested) merge scenarios where we define both a variable and a function. In both scenarios: - Branch A changes the "variable" (but does not change the function) - Branch B changes the function The scenarios are different because of the dependency between the function and the variable: 1. Function definition is independent of variable definition https://gist.github.com/dimitri-xyz/f0819c947ecd386b84d6 2. Function definition dependents on variable definition https://gist.github.com/dimitri-xyz/81a56b0ce0929e8513e9 Intuitively, I would like to have a merge conflict in scenario 2, but none in scenario 1. That suggests the following rule: We have a conflict iif a definition *that was changed* in branch B depends (transitively) on a definition *that was change* in branch A or vice-versa. In scenario 1, the definition of the function does not depend on the definition of the variable, so there is no conflict. Notice that 'main' depends on both, but it hasn't changed. In scenario 2, the definition of the functions has changed and it depends on the definition of the variable, so we would have a conflict. I understand this may not be sufficient to ensure no bugs are introduced, but this is my first approximation. The rule just captures the notion that programmer's shouldn't have their assumptions pulled from under their feet as they make changes. I wonder if/how I could claim that 'main' (that depends on both the function and the variable) is "merge-bug free" in the merged version. Cheers, Dimitri On 10/12/15 2:16 PM, David Turner wrote: > Hi, > > I work on a team of ~15 developers and we follow a merge-free process > using rebasing. Although in theory it sounds like you'll get the same > problems with rebasing as with merging, over 6 years and 100,000+ > commits I'm struggling to think of a single bug silently introduced > due to a rebase that succeeded without conflicts. It's a cunning bit > of social engineering: when merging the work of two developers, it's > easy for both of them to disclaim responsibility for any bugs > introduced by the merge, but when rebasing the work of developer A on > top of that of developer B it's clear that any bugs are dev A's > responsibility as their commits come later in the published history > than dev B's, and this gives dev A the incentive to check for semantic > conflicts properly. > > That said, it's theoretically possible to introduce bugs with a > 'clean' rebase, just as with merging, and I'm interested in your > suggestion because of that. The difficulty I see is defining what you > mean by "no new bugs". The two branches satisfy two different > specifications, and my reading of "no new bugs" is that the merge > result satisfies a merged specification. It sounds difficult to > automatically merge two specs together in general, although in > practice specs are often quite informal and where a rebase looks > questionable a merged spec can be invented and verified with human > intervention, remembering that the rebasing developer has a personal > incentive to get this right. > > There's two kind of formal spec that I know of in common usage in the > industry: types and tests. Using a type system gives you a bunch of > theorems about what your program can and cannot do, and this is > checked at compile time, and an automated test suite is basically a > bunch of properties that your program satisfies which can be verified > by running the test suite. Neither of these can capture the real spec > exactly, but in practice they turn out to be good enough for many > purposes. For those cases where that's not enough you can bring out > the heavy artillery of a theorem prover, and this does let you write > down the real spec exactly and verify it either side of a merge or > rebase. I wouldn't say that approach was in common usage but it does > get used where the investment is worth it. > > Verifying that changes to the type system leave the real spec > satisfied sounds quite hard in general. Merging additions to the test > suite sounds easy but other changes to the part of the spec embodied > in the test suite also sounds hard in general. Of the three, merging > changes to an automatically-proved theorem actually feels easiest - my > experience is that keeping a (well-written) automatic proof in sync > with changes to code is often not that hard, and when it is hard it's > normally been because the changes to the code meant the theorem was no > longer true. > > Perhaps enriching the type system to a point where you can write truly > useful specs in it is the answer? Thus dependent types. > > Cheers, > > David From alan.zimm at gmail.com Tue Oct 13 20:55:43 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 13 Oct 2015 22:55:43 +0200 Subject: [Haskell-cafe] ghc-mod and IDE / plugin integration Message-ID: Historically ghc-mod provided (and still does) support for emacs and vim as part of its distribution. It is also used by a number of other IDE backends to provide a way of getting information about a project without worrying too much about the details of how the project is organised on the file system. There is currently a discussion between various interested parties about adjusting the way ghc-mod communicates with the IDE, to make it simpler to provide this support for other environments. This should end up with a definition of a protocol that ghc-mod can expose, which should also allow tools (such as HaRe) to be plugged into it, so that IDE integration can be handled by the various IDE integrators in a clean, common way. This is all just hand waving at the moment, so if anyone would like to get involved I am proposing that we revive the "Haskell IDE implementation"[1] google group/mailing list to host the discussion. The new design is/will be captured here [2] Regards Alan [1] https://groups.google.com/forum/#!forum/haskell-ide [2] https://github.com/kazu-yamamoto/ghc-mod/wiki/Library-API-Redesign -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Wed Oct 14 01:18:55 2015 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Tue, 13 Oct 2015 18:18:55 -0700 Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build problems In-Reply-To: References: Message-ID: vasili at vasili-VirtualBox: cabal --version cabal-install version 1.20.0.3 using version 1.20.0.2 of the Cabal library vasili at vasili-VirtualBox: ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 OK ... I am running Ubuntu #31-Ubuntu. I am using apt-* install manager. I am relying on the install manager team to furnish versions of software. I will have to directly haskell.org to upgrade, yes?? Vasily On Tue, Oct 13, 2015 at 12:43 PM, Mikhail Glushenkov wrote: > Hi, > > On 13 October 2015 at 10:41, Vasili I. Galchin wrote: >> [...] >> "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'" >> [...] > > Upgrading to a newer GHC and/or cabal-install should fix this, I think. > > Which versions of GHC/cabal-install are you using? What is the output > of 'cabal configure -v3'? From sumit.sahrawat.apm13 at iitbhu.ac.in Wed Oct 14 02:20:14 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Wed, 14 Oct 2015 07:50:14 +0530 Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build problems In-Reply-To: References: Message-ID: The learnhaskell guide has instructions to get up to date versions of ghc and cabal. For Ubuntu: https://github.com/bitemyapp/learnhaskell/blob/master/install.md#ubuntu On 14 October 2015 at 06:48, Vasili I. Galchin wrote: > vasili at vasili-VirtualBox: cabal --version > cabal-install version 1.20.0.3 > using version 1.20.0.2 of the Cabal library > > vasili at vasili-VirtualBox: ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.6.3 > > > OK ... I am running Ubuntu #31-Ubuntu. I am using apt-* install > manager. I am relying on the install manager team to furnish versions > of software. I will have to directly haskell.org to upgrade, yes?? > > Vasily > > On Tue, Oct 13, 2015 at 12:43 PM, Mikhail Glushenkov > wrote: > > Hi, > > > > On 13 October 2015 at 10:41, Vasili I. Galchin > wrote: > >> [...] > >> "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'" > >> [...] > > > > Upgrading to a newer GHC and/or cabal-install should fix this, I think. > > > > Which versions of GHC/cabal-install are you using? What is the output > > of 'cabal configure -v3'? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Wed Oct 14 04:20:58 2015 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Tue, 13 Oct 2015 21:20:58 -0700 Subject: [Haskell-cafe] https://hackage.haskell.org/package/hoq build problems In-Reply-To: References: Message-ID: Thx everybody. Vasily On Tuesday, October 13, 2015, Sumit Sahrawat, Maths & Computing, IIT (BHU) < sumit.sahrawat.apm13 at iitbhu.ac.in> wrote: > The learnhaskell guide has instructions to get up to date versions of ghc > and cabal. > > For Ubuntu: > https://github.com/bitemyapp/learnhaskell/blob/master/install.md#ubuntu > > On 14 October 2015 at 06:48, Vasili I. Galchin > wrote: > >> vasili at vasili-VirtualBox: cabal --version >> cabal-install version 1.20.0.3 >> using version 1.20.0.2 of the Cabal library >> >> vasili at vasili-VirtualBox: ghc --version >> The Glorious Glasgow Haskell Compilation System, version 7.6.3 >> >> >> OK ... I am running Ubuntu #31-Ubuntu. I am using apt-* install >> manager. I am relying on the install manager team to furnish versions >> of software. I will have to directly haskell.org to upgrade, yes?? >> >> Vasily >> >> On Tue, Oct 13, 2015 at 12:43 PM, Mikhail Glushenkov >> > > wrote: >> > Hi, >> > >> > On 13 October 2015 at 10:41, Vasili I. Galchin > > wrote: >> >> [...] >> >> "unrecognized option `--extra-prog-path=/home/vasili/.cabal/bin'" >> >> [...] >> > >> > Upgrading to a newer GHC and/or cabal-install should fix this, I think. >> > >> > Which versions of GHC/cabal-install are you using? What is the output >> > of 'cabal configure -v3'? >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > -- > Regards > > Sumit Sahrawat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Wed Oct 14 06:42:42 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 14 Oct 2015 08:42:42 +0200 Subject: [Haskell-cafe] Haskell ecosystem improvements meta-propsal In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: Here is another example of a language change RFC process https://github.com/rust-lang/rfcs Alan On Wed, Oct 7, 2015 at 9:21 AM, Mike Meyer wrote: > On Wed, Oct 7, 2015 at 1:45 AM Mark Lentczner > wrote: > >> On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer wrote: >> >>> I've dealt with the IETF RFC process and the Python PEP process, and >>> both of them worked better than that. >> >> >> While both those are good examples of mostly working organizations >> shepherding foundational technical standard(s) along... there is one thing >> more important than their processes: Their stance. Both organizations have >> a very strong engineering discipline of keeping deployed things working >> without change. I don't think it is enough to simply model their process. >> > > Well, until Python 3, anyway. > > My goal wasn't to recreate the engineering discipline that deployed things > keep working without change as you upgrade the ecosystem, it's to provide a > mechanism so the community can more easily engage with the evolution of the > ecosystem. Hopefully this will make it easier for the community to move > things forward in a desirable manner. But it's a process, and leaves the > question of whether the desire is for more stability or a less stagnant > language up to the users of the process. > > I don't necessarily want to model the IETF or PEP processes. Those are a > starting point. I tried to abstract the initial points out enough that the > final result could be either one of them, or something totally unrelated > that's a better fit for the Haskell community. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Wed Oct 14 07:23:39 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 14 Oct 2015 09:23:39 +0200 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: <561D64AE.8030308@ucdavis.edu> References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> <561D64AE.8030308@ucdavis.edu> Message-ID: 2015-10-13 22:08 GMT+02:00 Dimitri DeFigueiredo : > [...] I hadn't looked at how to actually go about writing the "bug-free" > merge tool (if it becomes possible to write one). Isn't the whole approach limited by Rices's theorem? ( https://en.wikipedia.org/wiki/Rice%27s_theorem) In general we have to deal with partial functions, and the property you're talking about is definitely not trivial in the theorem's sense. So this implies 2 choices: * You don't detect all problems caused by merging (no point in putting some effort into that approach, it's basically what we have today with plain 'git merge'). * You have false positives, i.e. the merge tool complains although the merge is OK. So the best you can do AFAICT is to keep the amount of false positives low, hoping that people will see a benefit for the added annoyances. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Wed Oct 14 08:14:21 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Wed, 14 Oct 2015 09:14:21 +0100 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: <561D64AE.8030308@ucdavis.edu> References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> <561D64AE.8030308@ucdavis.edu> Message-ID: Yes, you're quite right, it's not uncommon for the result of a rebase either not to compile or else to fail some set of tests. But then that's also true of all code changes even by a single developer in isolation. A dependency analysis is an interesting idea (indeed, it's one of the tools we use to work out what the rough consequences of a change will be) but risks both false positives and false negatives. On the false positive side, as you observe, there'll often be something like 'main' which transitively depends on two parallel changes. On the false negative side, you can get conflicting changes that occur in separate programs - for instance the two sides of a network protocol - and a naive dependency analysis will miss this kind of problem. Heck, the changes could be in different languages (think browser-side JS talking via AJAX to server-side Haskell). Or even in separate repositories, possibly even developed by separate organisations, so you can't even tell you've done a merge let alone tell that it contains conflicts! Because of this sort of reasoning, I'm sceptical that the problem of 'bugs-introduced-by-merges' is really any easier than the general problem of 'bugs'. It's a continuum, not a clearly-defined subclass of bugs. I realised that there's another way to justify the unreasonable effectiveness of rebasing over merging. Assuming (conscientious) developers A & B making parallel changes: A1 -> A2 -> .... -> An B1 -> B2 -> .... -> Bm Each individual change can be seen to be correct, because that's how conscientious developers work. But then when it comes to merging, from their individual points of view it looks like: A1 -> A2 -> .... -> An -> [all of B's changes in one go] B1 -> B2 -> .... -> Bm -> [all of A's changes in one go] It's very hard for either A or B to reason about the correctness of that last step because it's such a big change. On the other hand, rebasing B's changes on top of A's looks like this: A1 -> A2 -> .... -> An -> B1' -> B2' -> .... -> Bm' Then B can go through their rebased changes and use pretty much the same reasoning as they were using before to check that they're still correct. Cheers, On 13 October 2015 at 21:08, Dimitri DeFigueiredo wrote: > The 6 years and 100K+ commits data point is pretty impressive! It makes me > question how much effort should be devoted to avoiding these > "merge-introduced" bugs in the first place. I assume this data point does > not capture bugs introduced by merges that were found by unit tests though. > > I hadn't looked at how to actually go about writing the "bug-free" merge > tool (if it becomes possible to write one). However, I think my immediate > approach would be different from your suggestion. I was thinking that we > could just look at the dependency graph between the definitions. > > Consider 2 possible (previously suggested) merge scenarios where we define > both a variable and a function. In both scenarios: > - Branch A changes the "variable" (but does not change the function) > - Branch B changes the function > > The scenarios are different because of the dependency between the function > and the variable: > 1. Function definition is independent of variable definition > https://gist.github.com/dimitri-xyz/f0819c947ecd386b84d6 > > 2. Function definition dependents on variable definition > https://gist.github.com/dimitri-xyz/81a56b0ce0929e8513e9 > > Intuitively, I would like to have a merge conflict in scenario 2, but none > in scenario 1. That suggests the following rule: > > We have a conflict iif a definition *that was changed* in branch B depends > (transitively) on a definition *that was change* in branch A or vice-versa. > > In scenario 1, the definition of the function does not depend on the > definition of the variable, so there is no conflict. Notice that 'main' > depends on both, but it hasn't changed. In scenario 2, the definition of > the functions has changed and it depends on the definition of the variable, > so we would have a conflict. > > I understand this may not be sufficient to ensure no bugs are introduced, > but this is my first approximation. The rule just captures the notion that > programmer's shouldn't have their assumptions pulled from under their feet > as they make changes. I wonder if/how I could claim that 'main' (that > depends on both the function and the variable) is "merge-bug free" in the > merged version. > > Cheers, > > Dimitri > > > > > On 10/12/15 2:16 PM, David Turner wrote: > >> Hi, >> >> I work on a team of ~15 developers and we follow a merge-free process >> using rebasing. Although in theory it sounds like you'll get the same >> problems with rebasing as with merging, over 6 years and 100,000+ commits >> I'm struggling to think of a single bug silently introduced due to a rebase >> that succeeded without conflicts. It's a cunning bit of social engineering: >> when merging the work of two developers, it's easy for both of them to >> disclaim responsibility for any bugs introduced by the merge, but when >> rebasing the work of developer A on top of that of developer B it's clear >> that any bugs are dev A's responsibility as their commits come later in the >> published history than dev B's, and this gives dev A the incentive to check >> for semantic conflicts properly. >> >> That said, it's theoretically possible to introduce bugs with a 'clean' >> rebase, just as with merging, and I'm interested in your suggestion because >> of that. The difficulty I see is defining what you mean by "no new bugs". >> The two branches satisfy two different specifications, and my reading of >> "no new bugs" is that the merge result satisfies a merged specification. It >> sounds difficult to automatically merge two specs together in general, >> although in practice specs are often quite informal and where a rebase >> looks questionable a merged spec can be invented and verified with human >> intervention, remembering that the rebasing developer has a personal >> incentive to get this right. >> >> There's two kind of formal spec that I know of in common usage in the >> industry: types and tests. Using a type system gives you a bunch of >> theorems about what your program can and cannot do, and this is checked at >> compile time, and an automated test suite is basically a bunch of >> properties that your program satisfies which can be verified by running the >> test suite. Neither of these can capture the real spec exactly, but in >> practice they turn out to be good enough for many purposes. For those cases >> where that's not enough you can bring out the heavy artillery of a theorem >> prover, and this does let you write down the real spec exactly and verify >> it either side of a merge or rebase. I wouldn't say that approach was in >> common usage but it does get used where the investment is worth it. >> >> Verifying that changes to the type system leave the real spec satisfied >> sounds quite hard in general. Merging additions to the test suite sounds >> easy but other changes to the part of the spec embodied in the test suite >> also sounds hard in general. Of the three, merging changes to an >> automatically-proved theorem actually feels easiest - my experience is that >> keeping a (well-written) automatic proof in sync with changes to code is >> often not that hard, and when it is hard it's normally been because the >> changes to the code meant the theorem was no longer true. >> >> Perhaps enriching the type system to a point where you can write truly >> useful specs in it is the answer? Thus dependent types. >> >> Cheers, >> >> David >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpmoresmau at gmail.com Wed Oct 14 08:19:42 2015 From: jpmoresmau at gmail.com (JP Moresmau) Date: Wed, 14 Oct 2015 09:19:42 +0100 Subject: [Haskell-cafe] ghc-mod and IDE / plugin integration In-Reply-To: References: Message-ID: ide-backend (https://github.com/fpco/ide-backend) provides a JSON layer ( https://github.com/commercialhaskell/stack-ide). I haven't tried it, since it requires stack and it's asking me to install the latest GHC 7.10.2 (sorry, I just wanted to have a look at the API, not reinstall a complete Haskell stack again), but maybe there are some good ideas there. But before talking about API, shouldn't we talk about why we have ghc-mod and ide-backend? Can we merge them, or be clear what are their differences and when/why we should use one and not the other? We don't have fragmentation at the compiler level itself (with the dominance of GHC) but we seem to have some at the "nicer API on top of GHC" level. Or maybe, should we have something in GHC itself, something like a GHC service that we could talk to via JSON or something, without having to use the complex, changing with each release GHC API, and have that part of GHC instead of having another tool to install? My 2 cents, JP On Tue, Oct 13, 2015 at 9:55 PM, Alan & Kim Zimmerman wrote: > Historically ghc-mod provided (and still does) support for emacs and vim > as part of its distribution. > > It is also used by a number of other IDE backends to provide a way of > getting information about a project without worrying too much about the > details of how the project is organised on the file system. > > There is currently a discussion between various interested parties about > adjusting the way ghc-mod communicates with the IDE, to make it simpler to > provide this support for other environments. > > This should end up with a definition of a protocol that ghc-mod can > expose, which should also allow tools (such as HaRe) to be plugged into it, > so that IDE integration can be handled by the various IDE integrators in a > clean, common way. > > This is all just hand waving at the moment, so if anyone would like to get > involved I am proposing that we revive the "Haskell IDE implementation"[1] > google group/mailing list to host the discussion. > > The new design is/will be captured here [2] > > Regards > Alan > > [1] https://groups.google.com/forum/#!forum/haskell-ide > [2] https://github.com/kazu-yamamoto/ghc-mod/wiki/Library-API-Redesign > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- JP Moresmau http://jpmoresmau.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Oct 14 09:20:24 2015 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 14 Oct 2015 12:20:24 +0300 Subject: [Haskell-cafe] ghc-mod and IDE / plugin integration In-Reply-To: References: Message-ID: Thanks for kicking off this thread Alan. I'm 100% behind the idea of working on unified tooling, and am happy to participate in making that happen. JP: You're right to bring up ide-backend. Let's start a real discussion (as part of what Alan's kicked off here) about what the best future for these projects would be. I don't want to predetermine the outcome of that conversation now, but I can say that anything up to merging ide-backend into ghc-mod and deprecating ide-backend as a separate project would be acceptable to me. Whatever makes the most sense for improved community tooling is what we should do. As for stack-ide, we already have slowed down development on it as a result of the changes to ghc-mod recently. None of us on the project had a chance yet to really analyze the situation and sync up with the ghc-mod team yet (mostly due to some travel), but at least IMO the ideal will be a single tool that supports multiple project structures (cabal, cabal sandbox, stack, etc) and various editor frontends. I don't have much structured thought right now on what the end game of all of this should look like, but I'll be happy to be part of the conversation and help get us to that better tooling future. On Wed, Oct 14, 2015 at 11:19 AM, JP Moresmau wrote: > ide-backend (https://github.com/fpco/ide-backend) provides a JSON layer ( > https://github.com/commercialhaskell/stack-ide). I haven't tried it, > since it requires stack and it's asking me to install the latest GHC 7.10.2 > (sorry, I just wanted to have a look at the API, not reinstall a complete > Haskell stack again), but maybe there are some good ideas there. > But before talking about API, shouldn't we talk about why we have ghc-mod > and ide-backend? Can we merge them, or be clear what are their differences > and when/why we should use one and not the other? We don't have > fragmentation at the compiler level itself (with the dominance of GHC) but > we seem to have some at the "nicer API on top of GHC" level. > Or maybe, should we have something in GHC itself, something like a GHC > service that we could talk to via JSON or something, without having to use > the complex, changing with each release GHC API, and have that part of GHC > instead of having another tool to install? > > My 2 cents, > > JP > > On Tue, Oct 13, 2015 at 9:55 PM, Alan & Kim Zimmerman > wrote: > >> Historically ghc-mod provided (and still does) support for emacs and vim >> as part of its distribution. >> >> It is also used by a number of other IDE backends to provide a way of >> getting information about a project without worrying too much about the >> details of how the project is organised on the file system. >> >> There is currently a discussion between various interested parties about >> adjusting the way ghc-mod communicates with the IDE, to make it simpler to >> provide this support for other environments. >> >> This should end up with a definition of a protocol that ghc-mod can >> expose, which should also allow tools (such as HaRe) to be plugged into it, >> so that IDE integration can be handled by the various IDE integrators in a >> clean, common way. >> >> This is all just hand waving at the moment, so if anyone would like to >> get involved I am proposing that we revive the "Haskell IDE >> implementation"[1] google group/mailing list to host the discussion. >> >> The new design is/will be captured here [2] >> >> Regards >> Alan >> >> [1] https://groups.google.com/forum/#!forum/haskell-ide >> [2] https://github.com/kazu-yamamoto/ghc-mod/wiki/Library-API-Redesign >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Wed Oct 14 09:51:50 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 14 Oct 2015 11:51:50 +0200 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> <561D64AE.8030308@ucdavis.edu> Message-ID: 2015-10-14 10:14 GMT+02:00 David Turner : > [...] It's very hard for either A or B to reason about the correctness of > that last step because it's such a big change. On the other hand, rebasing > B's changes on top of A's looks like this: > > A1 -> A2 -> .... -> An -> B1' -> B2' -> .... -> Bm' > > Then B can go through their rebased changes and use pretty much the same > reasoning as they were using before to check that they're still correct. > And what's even better: If you have a sane set of tests, you can easily find the exact commit where things went wrong in an automated way via 'git bisect'. This is the reason why some companies with large code bases totally ban merge commits and rely on rebasing exclusively. You can even go a step further by e.g. trying to revert the guilty commit and see if things work again without it, again in a totally automated way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Wed Oct 14 11:44:38 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 14 Oct 2015 13:44:38 +0200 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> <561D64AE.8030308@ucdavis.edu> Message-ID: On 14 October 2015 at 11:51, Sven Panne wrote: > > 2015-10-14 10:14 GMT+02:00 David Turner : >> >> [...] It's very hard for either A or B to reason about the correctness of >> that last step because it's such a big change. On the other hand, rebasing >> B's changes on top of A's looks like this: >> >> A1 -> A2 -> .... -> An -> B1' -> B2' -> .... -> Bm' >> >> Then B can go through their rebased changes and use pretty much the same >> reasoning as they were using before to check that they're still correct. > > > And what's even better: If you have a sane set of tests, you can easily find > the exact commit where things went wrong in an automated way via 'git > bisect'. This is the reason why some companies with large code bases totally > ban merge commits and rely on rebasing exclusively. You can even go a step > further by e.g. trying to revert the guilty commit and see if things work > again without it, again in a totally automated way. I'm not sure why you're saying this is impossible with merges; I've done it several times. Git will find the right branch where things went wrong, and then finds the commit on that branch without problems. Erik From svenpanne at gmail.com Wed Oct 14 13:03:09 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 14 Oct 2015 15:03:09 +0200 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> <561D64AE.8030308@ucdavis.edu> Message-ID: 2015-10-14 13:44 GMT+02:00 Erik Hesselink : > I'm not sure why you're saying this is impossible with merges; I've > done it several times. Git will find the right branch where things > went wrong, and then finds the commit on that branch without problems. Well, it might be the case that 'git bisect' alone works, but if you've got lots of tooling sitting on top of your version control (e.g. bots measuring and visualing performance, detecting regressions, etc.), you have a much easier time with a linear history than a DAG-shaped one. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Wed Oct 14 13:15:17 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 14 Oct 2015 15:15:17 +0200 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> <561D64AE.8030308@ucdavis.edu> Message-ID: On 14 October 2015 at 15:03, Sven Panne wrote: > 2015-10-14 13:44 GMT+02:00 Erik Hesselink : >> >> I'm not sure why you're saying this is impossible with merges; I've >> done it several times. Git will find the right branch where things >> went wrong, and then finds the commit on that branch without problems. > > Well, it might be the case that 'git bisect' alone works, but if you've got > lots of tooling sitting on top of your version control (e.g. bots measuring > and visualing performance, detecting regressions, etc.), you have a much > easier time with a linear history than a DAG-shaped one. This is getting a bit off topic, but anyway: I'm not even sure about that. What if your tools finds a regression, and you want to revert it. If it's part of a big rebased branch, this is tricky because the whole feature might depend on it. If it's a merge, though, you can just revert the merge. Erik From ianmbloom at gmail.com Wed Oct 14 13:31:51 2015 From: ianmbloom at gmail.com (Ian Bloom) Date: Wed, 14 Oct 2015 09:31:51 -0400 Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a monad? Message-ID: I've been wrestling with this for a while and I decided eventually to look for help. I've been hoping to design a domain specific embedded language in Haskell that would let me pipe a commutative monad throughout an expression written in the language. Special terms within the language will eventually have access to this monad. I've created a simplified version here to represent the main issues. Here is what I'd like from the language: * To use haskell syntax for substitution and pattern matching rather than implementing this myself. * To be able to express lambdas in my language. * To be able to embed any haskell terms including functions into the language. * I'd like the Haskell type checker to tell me about bad terms. * I'd like to thread a monad through the entire expression. So here is the first implementation that I tried of this (full source here: http://lpaste.net/142959) data Exp m x where Val :: m x -> Exp m x Lam1 :: m (a -> Exp m b) -> Exp m (a -> b) Lam2 :: m (a -> Exp m (b -> c)) -> Exp m (a -> b -> c) a function liftE allows me to lift a haskell term into an expression: liftE x = Val $ return x Application is a function <@> so: (<@>) :: forall m a b. Monad m => Exp m (a -> b) -> Exp m a -> Exp m b (<@>) (Val f) (Val x) = Val $ f `ap` x (<@>) (Lam2 f) (Val x) = Lam1 $ f >>= \f' -> x >>= \x' -> unLam1 $ f' x' (<@>) (Lam1 f) (Val x) = Val $ f >>= \f' -> x >>= \x' -> unVal $ f' x' Seems like it might work! In fact it does typecheck. So the first test expressions I'd like to try are these: mapE :: Monad m => Exp m ((a -> b) -> [a] -> [b]) mapE = Lam2 $ return $ \ f -> Lam1 $ return $ \ xxs -> case xxs of [] -> liftE [] (x:xs) -> liftE (:) <@> liftE (f x) <@> (mapE <@> liftE f <@> liftE xs) testExpression :: Monad m => Exp m [Int] testExpression = mapE <@> liftE (+10) <@> liftE [1,2,3,4] and just to justify doing any of this I'll create a Monad called BindCounter that counts the number of times bind is called: newtype BindCounter a = BC (Int -> (Int, a)) runBC (BC f) = f 0 instance Functor (BindCounter) where fmap f (BC x) = BC $ \t -> let (t', x') = x t in (t', f x') instance Applicative (BindCounter) where pure x = BC (\t -> (t,x)) f <*> x = f >>= \f' -> x >>= \x' -> return $ f' x' instance Monad (BindCounter) where return = pure BC f >>= g = BC $ \old -> let (new, val) = f (old + 1) BC f' = g val in f' new now I can try a test test = let (count, result) = runBC (unVal testExpression) in putStrLn $ "Count: " ++ show count ++ " Result: " ++ show result The result in ghci is: Count: 36 Result: [11,12,13,14] Ok so that's a lot. I was surprised I got this working. You can see from the code that my main gripe with this is I haven't found a way to remove the need to specify the number of embedded lambdas using Lam1 and Lam2 (we could easily add more) and I haven't found a way to apply a Lam to another Lam. I'm also curious if I am reinventing the wheel, I hadn't found a library yet that let's me do something similar. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Wed Oct 14 13:40:39 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 14 Oct 2015 15:40:39 +0200 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> <561D64AE.8030308@ucdavis.edu> Message-ID: 2015-10-14 15:15 GMT+02:00 Erik Hesselink : > This is getting a bit off topic, but anyway: I'm not even sure about > that. What if your tools finds a regression, and you want to revert > it. If it's part of a big rebased branch, this is tricky because the > whole feature might depend on it. If it's a merge, though, you can > just revert the merge. > OK, now we're really off-topic, but anyway: But when you revert the merge (which brought in lots of commits at once), you still have no idea which individual commit caused the regression. Perhaps there isn't even a regression on your branch at all, only after the merge. Been there, done that... :-P When you have a multi-million line project with hundreds of people working on it, your bots can't keep up with the constant stream of commits (so they typically batch things, doing more detailed runs later when there is time, if any), and you really have to rely on some kind of continuos integration, things get really complicated. So I understand the policy of taking one problem out of the way, namely non-linear history. That's at least what I've experienced, but your mileage may vary, of course. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ratzes at gmail.com Wed Oct 14 13:44:40 2015 From: ratzes at gmail.com (Charles Durham) Date: Wed, 14 Oct 2015 09:44:40 -0400 Subject: [Haskell-cafe] A suggestion: On why code merges should influence Haskell design In-Reply-To: <561C07FD.5070304@ucdavis.edu> References: <20151006203900.GT11050@weber> <5615579D.5040900@orlitzky.com> <874mi15uta.fsf@smart-cactus.org> <5616BB8A.1080807@orlitzky.com> <6E4E1EB19BD1B85A5D0958AF410E0E@mail.local> <5617B9AD.90703@ciktel.net> <5617E178.9000506@stilo.com> <5619C4F5.3060800@ucdavis.edu> <561C07FD.5070304@ucdavis.edu> Message-ID: Hmm, I think for Case 2, that there is a case where there is no bug in A or B, but a bug in the merge. If the search strategy changes from s to s', and the function definition changes from f to f', then I can come up with a scenario where s and s' works for f and s works for both f and f', but s' doesn't work for f'. I believe that Case 1 is pretty much the same. On Mon, Oct 12, 2015 at 3:20 PM, Dimitri DeFigueiredo < defigueiredo at ucdavis.edu> wrote: > I think both these examples strengthen my argument! :-) > > There is no problem at all in the second and the first one precisely show > us a situation when we would like to know there is a conflict. > > The guarantee I want is that when merging 2 branches A and B: > *If there are no conflicts*, the merge tool guarantees the merge output > introduces no new bugs *other than those already found in A or B*. > > Note: > 1. we get to define what a conflict is and > 2. we don't care if the bugs were already present in either branch. > > On the first example, I assume both branches A and B will compile and run > before the merge so that we are really only changing the value of the > variable on branch A and the definition of the function on branch B > (otherwise the branches would not compile before the merge). > > Because the definition of the function depends on a *specific* value the > variable, there is no way to avoid declaring a conflict. But notice that in > the more general case where the function puts that value as a parameter > there is no conflict, because if there were a bug it would already be > present in branch B. So, the merge process is not introducing any bugs by > itself. > > This is exactly what happens in the second example. I assume branch A > provides the new definition of f(x) and that in branch B we change the > search strategy in the search function g. However, I assume that g would > take f as a parameter g:: (Integer -> Integer) -> Integer. In this case, if > there were a bug in g in the merged output, then it would already be > present in branch B before the merge. Therefore, there is no conflict at > all here. > > In summary, there is no conflict on the second example and I would like to > know about the conflict due to the global dependency on the first one. > > > Dimitri > > > > On 10/11/15 6:58 PM, Charles Durham wrote: > > 1. If you have a merge take place in two lines right next to each other, > say one variable is declared in one and a function processes that variable > in another, if those two are responsible together for exiting a loop, then > you're going to be solving the Halting Problem to show there are no bugs. > > 2. If you have one function "f(x) = a + bx + cx^2 +..." and another > function that iterates through integers until a solution is found in > integers, then if the internals of either is changed (either the constants > in f, or the search strategy), then you're going to have to be solving > "Hilberts 10th Problem" to understand that there are no bugs introduced, > thought this was interesting as the changes are "further" apart. > > At least for the general case, this should be a problem for all Turing > Complete languages. It might be interesting to think about finding sections > of code that are "Total", and perhaps put certain guarantees on that, but > there still might be weird ways that two lines of code can play with each > other beyond that. > > I hope this isn't overly pedantic, or that I'm not completely off base. > > On Sun, Oct 11, 2015 at 8:10 PM, Jeffrey Brown > wrote: > >> +1 for AST merge. Writing code from text is reasonable, but storing code >> as text is lunacy. >> >> On Sat, Oct 10, 2015 at 11:17 PM, Sean Leather < >> sean.leather at gmail.com> wrote: >> >>> On Sun, Oct 11, 2015 at 4:09 AM, Dimitri DeFigueiredo wrote: >>> >>>> Can we write a "compiler-like" merge tool for Haskell? >>> >>> >>> Merge could be considered to be a combination of diff and patch. And so >>> you might want to merge ASTs, which are typically families of datatypes. >>> Related: Type-Safe Diff for Families of Dataypes: >>> >>> http://www.andres-loeh.de/gdiff-wgp.pdf >>> >>> Regards, >>> Sean >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> >> -- >> Jeffrey Benjamin Brown >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vagif.verdi at gmail.com Wed Oct 14 19:57:53 2015 From: vagif.verdi at gmail.com (Vagif Verdi) Date: Wed, 14 Oct 2015 12:57:53 -0700 (PDT) Subject: [Haskell-cafe] Haskell developer job offer Message-ID: https://home2.eease.adp.com/recruit2/?id=19008792&t=1 Email me if interested. -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Thu Oct 15 11:43:46 2015 From: winterkoninkje at gmail.com (wren romano) Date: Thu, 15 Oct 2015 07:43:46 -0400 Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a monad? In-Reply-To: References: Message-ID: On Wed, Oct 14, 2015 at 9:31 AM, Ian Bloom wrote: > Here is what I'd like from the language: > > * To use haskell syntax for substitution and pattern matching rather than > implementing this myself. > * To be able to express lambdas in my language. > * To be able to embed any haskell terms including functions into the > language. > * I'd like the Haskell type checker to tell me about bad terms. > * I'd like to thread a monad through the entire expression. It's still not clear exactly what you want/need with that last bullet point. So I can try to offer help, but have no idea if this is on the right track... > So here is the first implementation that I tried of this (full source here: > http://lpaste.net/142959) > > data Exp m x where > Val :: m x -> Exp m x > Lam1 :: m (a -> Exp m b) -> Exp m (a -> b) > Lam2 :: m (a -> Exp m (b -> c)) -> Exp m (a -> b -> c) > > a function liftE allows me to lift a haskell term into an expression: > > liftE x = Val $ return x > > Application is a function <@> so: > > (<@>) :: forall m a b. Monad m => Exp m (a -> b) -> Exp m a -> Exp m b > (<@>) (Val f) (Val x) = Val $ f `ap` x > (<@>) (Lam2 f) (Val x) = Lam1 $ f >>= \f' -> x >>= \x' -> unLam1 $ f' x' > (<@>) (Lam1 f) (Val x) = Val $ f >>= \f' -> x >>= \x' -> unVal $ f' x' > >[...] > > Ok so that's a lot. I was surprised I got this working. You can see from the > code that my main gripe with this is I haven't found a way to remove the > need to specify the number of embedded lambdas using Lam1 and Lam2 (we could > easily add more) and I haven't found a way to apply a Lam to another Lam. > I'm also curious if I am reinventing the wheel, I hadn't found a library yet > that let's me do something similar. So, two things to notice. First, the type for Lam2 is just a refinement of the type for Lam1. Thus, Lam2 gives you nothing new in terms of what can be made to typecheck; the only thing it gives you is the ability to make runtime decisions based on whether a particular expression was built with Lam1 or Lam2 (or Val). Second, the apparent need for multiple lambdas stems from the fact that your (<@>) function needs to "count down by one" each time an argument is applied. This hides a big problem in the definition, namely that you're assuming that after the right number of arguments the resulting Exp will be built with Val; which isn't actually guaranteed by the types. After playing around with it for a while, it seems like the crux of the issue comes from not being able to embed m(Exp m a) into Exp m a. So, we can fix that by adding a new constructor: data Exp m x where Val :: m a -> Exp m a Exp :: m (Exp m a) -> Exp m a Lam :: m (a -> Exp m b) -> Exp m (a -> b) Exp f <@> x = Exp ((<@> x) <$> f) f <@> Exp x = Exp ((f <@>) <$> x) Val f <@> Val x = Val (f <*> x) Lam f <@> Val x = Exp (($) <$> f <*> x) -- TODO: Val/Lam and Lam/Lam cases... unVal :: Monad m => Exp m a -> m a unVal (Val v) = v unVal (Exp e) = e >>= unVal This at least works for the given test case with mapE, testExpression, and test? though it doesn't give exactly the same result about the number of binds. But again I'm not sure what you're really after here. (Note that, once we add the Exp constructor, we can redo Val to take a pure argument without losing anything re typeability. Though again, the exact semantics of dubious things like (>>=)-counting won't necessarily be preserved. Still, as a general rule, it makes sense for EDSLs to distinguish between pure values vs impure expressions...) -- Live well, ~wren From oleg at okmij.org Thu Oct 15 12:55:42 2015 From: oleg at okmij.org (Oleg) Date: Thu, 15 Oct 2015 21:55:42 +0900 Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a monad? Message-ID: <20151015125542.GA2012@Magus.sf-private> > Ian Bloom wrote: > I've been hoping to design a domain specific embedded language in > Haskell that would let me pipe a commutative monad throughout an expression > written in the language. Special terms within the language will eventually > have access to this monad. Is there a reason tagless-final approach does not work for you? You can easily thread any monad, even if you don't make any provision for it initially. For example, http://okmij.org/ftp/tagless-final/index.html#call-by-any http://okmij.org/ftp/tagless-final/course/CBAny.hs uses monad to print out traces of the expression and then later to implement lazy evaluation for EDLS (which needs mutable cells). From ianmbloom at gmail.com Thu Oct 15 13:57:06 2015 From: ianmbloom at gmail.com (Ian Bloom) Date: Thu, 15 Oct 2015 09:57:06 -0400 Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a monad? In-Reply-To: References: Message-ID: Hi, Thanks for your reply. I think the Monad that I chose for my example code was not the best. I've been hoping to generalize across all possible monads but the real use case arises because I have an expensive computation that I know will repeat multiple times within the evaluation of a given large expression so in my monad I want to implement a cache. If I query the cache and it has not done the computation it will perform the computation once and then return the result plus a new cache holding the result, if the computation has already been performed it is present in the cache and taken from there. In my definition of Exp there would then be one more value, say Ext that when applied to a parameter can access and modify the cache. In this case the order of evaluation doesn't affect the result of the Monad, I'm not sure if "commutative" is the right way to describe this. There is a lot to think about here but let me try playing around with your code. Thanks, Ian On Thu, Oct 15, 2015 at 7:43 AM, wren romano wrote: > On Wed, Oct 14, 2015 at 9:31 AM, Ian Bloom wrote: > > Here is what I'd like from the language: > > > > * To use haskell syntax for substitution and pattern matching rather > than > > implementing this myself. > > * To be able to express lambdas in my language. > > * To be able to embed any haskell terms including functions into the > > language. > > * I'd like the Haskell type checker to tell me about bad terms. > > * I'd like to thread a monad through the entire expression. > > It's still not clear exactly what you want/need with that last bullet > point. So I can try to offer help, but have no idea if this is on the > right track... > > > > So here is the first implementation that I tried of this (full source > here: > > http://lpaste.net/142959) > > > > data Exp m x where > > Val :: m x -> Exp m x > > Lam1 :: m (a -> Exp m b) -> Exp m (a -> b) > > Lam2 :: m (a -> Exp m (b -> c)) -> Exp m (a -> b -> c) > > > > a function liftE allows me to lift a haskell term into an expression: > > > > liftE x = Val $ return x > > > > Application is a function <@> so: > > > > (<@>) :: forall m a b. Monad m => Exp m (a -> b) -> Exp m a -> Exp m > b > > (<@>) (Val f) (Val x) = Val $ f `ap` x > > (<@>) (Lam2 f) (Val x) = Lam1 $ f >>= \f' -> x >>= \x' -> unLam1 $ > f' x' > > (<@>) (Lam1 f) (Val x) = Val $ f >>= \f' -> x >>= \x' -> unVal $ f' > x' > > > >[...] > > > > Ok so that's a lot. I was surprised I got this working. You can see from > the > > code that my main gripe with this is I haven't found a way to remove the > > need to specify the number of embedded lambdas using Lam1 and Lam2 (we > could > > easily add more) and I haven't found a way to apply a Lam to another Lam. > > I'm also curious if I am reinventing the wheel, I hadn't found a library > yet > > that let's me do something similar. > > So, two things to notice. > > First, the type for Lam2 is just a refinement of the type for Lam1. > Thus, Lam2 gives you nothing new in terms of what can be made to > typecheck; the only thing it gives you is the ability to make runtime > decisions based on whether a particular expression was built with Lam1 > or Lam2 (or Val). > > Second, the apparent need for multiple lambdas stems from the fact > that your (<@>) function needs to "count down by one" each time an > argument is applied. This hides a big problem in the definition, > namely that you're assuming that after the right number of arguments > the resulting Exp will be built with Val; which isn't actually > guaranteed by the types. > > After playing around with it for a while, it seems like the crux of > the issue comes from not being able to embed m(Exp m a) into Exp m a. > So, we can fix that by adding a new constructor: > > data Exp m x where > Val :: m a -> Exp m a > Exp :: m (Exp m a) -> Exp m a > Lam :: m (a -> Exp m b) -> Exp m (a -> b) > > Exp f <@> x = Exp ((<@> x) <$> f) > f <@> Exp x = Exp ((f <@>) <$> x) > Val f <@> Val x = Val (f <*> x) > Lam f <@> Val x = Exp (($) <$> f <*> x) > -- TODO: Val/Lam and Lam/Lam cases... > > unVal :: Monad m => Exp m a -> m a > unVal (Val v) = v > unVal (Exp e) = e >>= unVal > > This at least works for the given test case with mapE, testExpression, > and test? though it doesn't give exactly the same result about the > number of binds. But again I'm not sure what you're really after here. > > (Note that, once we add the Exp constructor, we can redo Val to take a > pure argument without losing anything re typeability. Though again, > the exact semantics of dubious things like (>>=)-counting won't > necessarily be preserved. Still, as a general rule, it makes sense for > EDSLs to distinguish between pure values vs impure expressions...) > > -- > Live well, > ~wren > -- 718.755.5483 http://ianbloom.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianmbloom at gmail.com Thu Oct 15 14:01:24 2015 From: ianmbloom at gmail.com (Ian Bloom) Date: Thu, 15 Oct 2015 10:01:24 -0400 Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a monad? In-Reply-To: <20151015125542.GA2012@Magus.sf-private> References: <20151015125542.GA2012@Magus.sf-private> Message-ID: Thanks for pointing that out, this is my first time encountering tagless-final. The use of the :-> data constructor seems to solve a lot of problems. I'm wondering how to introduce a haskell function as an embedded value in such an EDSL but I think I will try it out. Thanks, Ian On Thu, Oct 15, 2015 at 8:55 AM, Oleg wrote: > > > > Ian Bloom wrote: > > I've been hoping to design a domain specific embedded language in > > Haskell that would let me pipe a commutative monad throughout an > expression > > written in the language. Special terms within the language will > eventually > > have access to this monad. > > > Is there a reason tagless-final approach does not work for you? You > can easily thread any monad, even if you don't make any provision for > it initially. For example, > > http://okmij.org/ftp/tagless-final/index.html#call-by-any > http://okmij.org/ftp/tagless-final/course/CBAny.hs > > uses monad to print out traces of the expression and then later to > implement lazy evaluation for EDLS (which needs mutable cells). > > > -- 718.755.5483 http://ianbloom.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Thu Oct 15 14:33:45 2015 From: capn.freako at gmail.com (David Banas) Date: Thu, 15 Oct 2015 07:33:45 -0700 Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker Dojo. Message-ID: Hi all, I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery to implement the Fast Fourier Transform (FFT). Hope to see you there, -db From amit at amitlevy.com Thu Oct 15 17:16:48 2015 From: amit at amitlevy.com (Amit Aryeh Levy) Date: Thu, 15 Oct 2015 13:16:48 -0400 Subject: [Haskell-cafe] Specializing argument to forM_, mapM_ & foldM_ in base-4.8 Message-ID: <561FDF80.8000507@amitlevy.com> I've been running into a relatively small but frequent annoyance with base >= 4.8 (GHC 7.10). `Control.Monad.foldM_`, `Control.Monad.mapM_` and `Control.Monad.forM_` are generalized traverse over any `Foldable a` rather than just arrays (`[a]`). This is great, except I'm finding that, for a lot of my code that works well in previous versions, I need to specialize the argument to `[a]` now. If other people are encoutering a similar patter, I wonder what are your best practices for doing this: ScopedTypeVariables? Deconstruct the reconstruct the array? ... The most common example is when I deserialize a JSON array with aeson and want to traverse over that array (say, to store the objects to a DB): ``` let objArray = eitherDecode myjson case objArray of Left err -> ... Right (objs :: [MyObjType]) -> forM_ objs $ \obj -> saveToDb obj ``` ?The above fix requires `ScopedTypeVariables` (which is probably OK). Another option is to deconstruct and reconstruct the list: ``` Right (o:objs) -> forM_ (o:objs) $ \obj -> saveToDb obj ``` Does this get optimized away? Penny for your thoughts? Cheers! Amit -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From manny at fpcomplete.com Thu Oct 15 17:40:00 2015 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Thu, 15 Oct 2015 17:40:00 +0000 Subject: [Haskell-cafe] ANN: stack-0.1.6.0 Message-ID: New version released of Stack, a build tool. See README for installation and upgrade instructions. Major changes: - ?stack setup? now supports building and booting GHCJS from source tarball. - On Windows, build directories no longer display ?pretty? information (like x86_64-windows/Cabal-1.22.4.0), but rather a hash of that content. The reason is to avoid the 260 character path limitation on Windows. See #1027 - Rename config files and clarify their purposes #969 - ~/.stack/stack.yaml ? ~/.stack/config.yaml - ~/.stack/global ? ~/.stack/global-project - /etc/stack/config ? /etc/stack/config.yaml - Old locations still supported, with deprecation warnings - New command ?stack eval CODE?, which evaluates to ?stack exec ghc ? -e CODE?. Other enhancements: - No longer install git on Windows #1046 . You can still get this behavior by running the following yourself: stack exec -- pacman -Sy --noconfirm git. - Typing enter during ?file-watch triggers a rebuild #1023 - Use Haddock?s --hyperlinked-source (crosslinked source), if available #1070 - Use Stack-installed GHCs for stack init --solver #1072 - New experimental stack query command #1087 - By default, stack no longer rebuilds a package due to GHC options changes. This behavior can be tweaked with the rebuild-ghc-options setting. #1089 - By default, ghc-options are applied to all local packages, not just targets. This behavior can be tweaked with the apply-ghc-options setting. #1089 - Docker: download or override location of stack executable to re-run in container #974 - Docker: when Docker Engine is remote, don?t run containerized processes as host?s UID/GID #194 - Docker: set-user option to enable/disable running containerized processes as host?s UID/GID #194 - Custom Setup.hs files are now precompiled instead of interpreted. This should be a major performance win for certain edge cases (biggest example: building Cabal itself ) while being either neutral or a minor slowdown for more common cases. - stack test --coverage now also generates a unified coverage report for multiple test-suites / packages. In the unified report, test-suites can contribute to the coverage of other packages. Bug fixes: - Ignore stack-built executables named ghc #1052 - Fix quoting of output failed command line arguments - Mark executable-only packages as installed when copied from cache #1043 - Canonicalize temporary directory paths #1047 - Put code page fix inside the build function itself #1066 - Add explicit-setup-deps option #1110 , and change the default to the old behavior of using any package in the global and snapshot database #1025 - Precompiled cache checks full package IDs on Cabal < 1.22 #1103 - Pass -package-id to ghci #867 - Ignore global packages when copying precompiled packages #1146 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Thu Oct 15 18:27:55 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Thu, 15 Oct 2015 20:27:55 +0200 Subject: [Haskell-cafe] Specializing argument to forM_, mapM_ & foldM_ in base-4.8 In-Reply-To: <561FDF80.8000507@amitlevy.com> References: <561FDF80.8000507@amitlevy.com> Message-ID: If you care about performance you may - I haven't benchmarked - want to use Vector instead of lists here since that's what aeson uses internally. Then it's pretty handy that you can still use forM_. It's possible that the list pattern deconstruction and list construction gets optimized away, my gut says you need -O2 for that to happen. Here's a good explanation on how to dump and read core so you can check for yourself what happens in this case: http://stackoverflow.com/questions/6121146/reading-ghc-core . Either way it's definitiely not less efficient to annotate the type instead. You don't need ScopedTypeVariables here, you can write the type inside an expression instead: `forM (objs :: Type) [...]` HTH, Adam On Thu, Oct 15, 2015 at 7:16 PM, Amit Aryeh Levy wrote: > I've been running into a relatively small but frequent annoyance with > base >= 4.8 (GHC 7.10). `Control.Monad.foldM_`, `Control.Monad.mapM_` > and `Control.Monad.forM_` are generalized traverse over any `Foldable a` > rather than just arrays (`[a]`). > > This is great, except I'm finding that, for a lot of my code that works > well in previous versions, I need to specialize the argument to `[a]` > now. If other people are encoutering a similar patter, I wonder what are > your best practices for doing this: ScopedTypeVariables? Deconstruct the > reconstruct the array? ... > > The most common example is when I deserialize a JSON array with aeson > and want to traverse over that array (say, to store the objects to a DB): > > ``` > let objArray = eitherDecode myjson > case objArray of > Left err -> ... > Right (objs :: [MyObjType]) -> > forM_ objs $ \obj -> saveToDb obj > ``` > > ?The above fix requires `ScopedTypeVariables` (which is probably OK). > Another option is to deconstruct and reconstruct the list: > > ``` > Right (o:objs) -> > forM_ (o:objs) $ \obj -> saveToDb obj > ``` > > Does this get optimized away? > > Penny for your thoughts? > > Cheers! > Amit > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Thu Oct 15 18:29:28 2015 From: capn.freako at gmail.com (David Banas) Date: Thu, 15 Oct 2015 11:29:28 -0700 Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker Dojo. In-Reply-To: References: Message-ID: Yes, you may attend without being a member of the Hacker Dojo. -db On Thu, Oct 15, 2015 at 10:27 AM, Andrew Gibiansky < andrew.gibiansky at gmail.com> wrote: > Can I come if I'm not a member of Hacker Dojo? The website is unclear. > > -- Andrew > > On Thu, Oct 15, 2015 at 7:33 AM, David Banas > wrote: > >> Hi all, >> >> I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker >> Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery >> to implement the Fast Fourier Transform (FFT). >> >> Hope to see you there, >> -db >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kc1956 at gmail.com Thu Oct 15 18:35:24 2015 From: kc1956 at gmail.com (KC) Date: Thu, 15 Oct 2015 11:35:24 -0700 Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker Dojo. In-Reply-To: References: Message-ID: Will slides be posted? -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey On Oct 15, 2015 7:33 AM, "David Banas" wrote: > Hi all, > > I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker > Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery > to implement the Fast Fourier Transform (FFT). > > Hope to see you there, > -db > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Thu Oct 15 19:15:23 2015 From: capn.freako at gmail.com (David Banas) Date: Thu, 15 Oct 2015 12:15:23 -0700 Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker Dojo. In-Reply-To: References: Message-ID: Yes, assuming Meetup has infrastructure in place for doing so. I'll check w/ Tim on that. -db On Thu, Oct 15, 2015 at 11:35 AM, KC wrote: > Will slides be posted? > > -- > -- > > Sent from an expensive device which will be obsolete in a few months! :D > > Casey > > On Oct 15, 2015 7:33 AM, "David Banas" wrote: > >> Hi all, >> >> I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker >> Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery >> to implement the Fast Fourier Transform (FFT). >> >> Hope to see you there, >> -db >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kc1956 at gmail.com Thu Oct 15 19:18:06 2015 From: kc1956 at gmail.com (KC) Date: Thu, 15 Oct 2015 12:18:06 -0700 Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker Dojo. In-Reply-To: References: Message-ID: We in Canada like to learn a thing or three ... :D -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey On Oct 15, 2015 12:15 PM, "David Banas" wrote: > Yes, assuming Meetup has infrastructure in place for doing so. > I'll check w/ Tim on that. > -db > > > On Thu, Oct 15, 2015 at 11:35 AM, KC wrote: > >> Will slides be posted? >> >> -- >> -- >> >> Sent from an expensive device which will be obsolete in a few months! :D >> >> Casey >> >> On Oct 15, 2015 7:33 AM, "David Banas" wrote: >> >>> Hi all, >>> >>> I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker >>> Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery >>> to implement the Fast Fourier Transform (FFT). >>> >>> Hope to see you there, >>> -db >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wren at community.haskell.org Thu Oct 15 19:48:26 2015 From: wren at community.haskell.org (wren romano) Date: Thu, 15 Oct 2015 15:48:26 -0400 Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a monad? In-Reply-To: References: Message-ID: On Thu, Oct 15, 2015 at 9:57 AM, Ian Bloom wrote: > Hi, > Thanks for your reply. I think the Monad that I chose for my example code > was not the best. I've been hoping to generalize across all possible monads > but the real use case arises because I have an expensive computation that I > know will repeat multiple times within the evaluation of a given large > expression so in my monad I want to implement a cache. If I query the cache > and it has not done the computation it will perform the computation once and > then return the result plus a new cache holding the result, if the > computation has already been performed it is present in the cache and taken > from there. In my definition of Exp there would then be one more value, say > Ext that when applied to a parameter can access and modify the cache. In > this case the order of evaluation doesn't affect the result of the Monad, > I'm not sure if "commutative" is the right way to describe this. Yeah, if the order of computations doesn't matter, then the monad is commutative. If you want to distinguish "finished computations", then you should make that distinction in the types; for example: data WHNF m a where Val :: a -> WHNF m a Lam :: (a -> Exp m b) -> WHNF m (a -> b) -- ...other value constructors of your DSL go here... data Exp m a where -- | Do some side effects and then return a value. Exp :: m (WHNF m a) -> Exp m a N.B., this version collapses chains of (the old)Exp data constructor, forcing them to all be bundled up together. That has its ups and downs. On the upside, you know you'll get a WHNF out after running stuff. On the downside, maybe sometimes you'll want to run the first part of the monad stuff just once, and then pause things so you can run more effects repeatedly (i.e., the ability to package up the type m(m(WHNF m a)) so you can run the outer m once, and then the inner m repeatedly). If you need that latter ability, then you should use this instead: data Exp m a where Now :: m (WHNF m a) -> Exp m a Later :: m (Exp m a) -> Exp m a -- Live well, ~wren From amit at amitlevy.com Thu Oct 15 20:17:24 2015 From: amit at amitlevy.com (Amit Aryeh Levy) Date: Thu, 15 Oct 2015 16:17:24 -0400 Subject: [Haskell-cafe] Specializing argument to forM_, mapM_ & foldM_ in base-4.8 In-Reply-To: References: <561FDF80.8000507@amitlevy.com> Message-ID: <562009D4.4020807@amitlevy.com> Thanks Adam! Vector does make more sense (i'll continue to use lists in this thread just for simplicity, since I don't think it matters for the higher level problem). `forM_ (objs :: Type) ....` seems like exactly the right solution in the simple case. However, it doesn't seem to work if I try to write a more general function. For example: ``` class ToRow r saveToDb :: FromJSON r, ToRow r => ByteString -> (tr -> IO ()) -> IO () saveToDb json processRow = case eitherDecode json of Left err => return () -- for simplicity Right rows => forM_ (rows :: [r]) processRow ``` GHC complains about two things: 1. eitherDecode can't determine which `FromJSON` instance to use 2. "Couldn't match expected type [r1] with actual type a0" in `rows :: [r]`. I think the issue is that GHC is not relating `rows :: [r]` to `FromJSON r` in the function type. Falling back to either ScopedTypeVariables or explicit contruction/deconstruction of the list works: ``` class ToRow r saveToDb :: FromJSON r, ToRow r => ByteString -> (tr -> IO ()) -> IO () saveToDb json processRow = case eitherDecode json of Left err => return () -- for simplicity Right (rows :: [r]) => forM_ rows processRow ``` Thoughts? Thanks! Amit P.S. Thanks to Felipe for politely reminding me that these are lists we are dealing with, not arrays! On 10/15/2015 02:27 PM, Adam Bergmark wrote: > If you care about performance you may - I haven't benchmarked - want to use > Vector instead of lists here since that's what aeson uses internally. Then > it's pretty handy that you can still use forM_. > > It's possible that the list pattern deconstruction and list construction > gets optimized away, my gut says you need -O2 for that to happen. Here's a > good explanation on how to dump and read core so you can check for yourself > what happens in this case: > http://stackoverflow.com/questions/6121146/reading-ghc-core . Either way > it's definitiely not less efficient to annotate the type instead. You don't > need ScopedTypeVariables here, you can write the type inside an expression > instead: `forM (objs :: Type) [...]` > > HTH, > Adam > > > On Thu, Oct 15, 2015 at 7:16 PM, Amit Aryeh Levy wrote: > >> I've been running into a relatively small but frequent annoyance with >> base >= 4.8 (GHC 7.10). `Control.Monad.foldM_`, `Control.Monad.mapM_` >> and `Control.Monad.forM_` are generalized traverse over any `Foldable a` >> rather than just arrays (`[a]`). >> >> This is great, except I'm finding that, for a lot of my code that works >> well in previous versions, I need to specialize the argument to `[a]` >> now. If other people are encoutering a similar patter, I wonder what are >> your best practices for doing this: ScopedTypeVariables? Deconstruct the >> reconstruct the array? ... >> >> The most common example is when I deserialize a JSON array with aeson >> and want to traverse over that array (say, to store the objects to a DB): >> >> ``` >> let objArray = eitherDecode myjson >> case objArray of >> Left err -> ... >> Right (objs :: [MyObjType]) -> >> forM_ objs $ \obj -> saveToDb obj >> ``` >> >> ?The above fix requires `ScopedTypeVariables` (which is probably OK). >> Another option is to deconstruct and reconstruct the list: >> >> ``` >> Right (o:objs) -> >> forM_ (o:objs) $ \obj -> saveToDb obj >> ``` >> >> Does this get optimized away? >> >> Penny for your thoughts? >> >> Cheers! >> Amit >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From adam at bergmark.nl Thu Oct 15 20:44:14 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Thu, 15 Oct 2015 22:44:14 +0200 Subject: [Haskell-cafe] Specializing argument to forM_, mapM_ & foldM_ in base-4.8 In-Reply-To: <562009D4.4020807@amitlevy.com> References: <561FDF80.8000507@amitlevy.com> <562009D4.4020807@amitlevy.com> Message-ID: You are correct that GHC sees two different `r`'s here. I don't think you can get around using ScopedTypeVariables (which I wouldn't care about). The difference in annotating the expression is that you need an (explicit) forall. I actually don't know why the pattern type annotation doesn't need this... saveToDb :: forall r. (FromJSON r, ToRow r) => LazyByteString -> (r -> IO ()) -> IO () saveToDb json processRow = case eitherDecode json of Left _err -> return () -- for simplicity Right rows -> forM_ (rows :: [r]) processRow On Thu, Oct 15, 2015 at 10:17 PM, Amit Aryeh Levy wrote: > Thanks Adam! > > Vector does make more sense (i'll continue to use lists in this thread > just for simplicity, since I don't think it matters for the higher level > problem). > > `forM_ (objs :: Type) ....` seems like exactly the right solution in the > simple case. However, it doesn't seem to work if I try to write a more > general function. For example: > > ``` > class ToRow r > > saveToDb :: FromJSON r, ToRow r => ByteString -> (tr -> IO ()) -> IO () > saveToDb json processRow = > case eitherDecode json of > Left err => return () -- for simplicity > Right rows => forM_ (rows :: [r]) processRow > ``` > > GHC complains about two things: > > 1. eitherDecode can't determine which `FromJSON` instance to use > 2. "Couldn't match expected type [r1] with actual type a0" in `rows > :: [r]`. > > I think the issue is that GHC is not relating `rows :: [r]` to `FromJSON > r` in the function type. > > Falling back to either ScopedTypeVariables or explicit > contruction/deconstruction of the list works: > > ``` > class ToRow r > > saveToDb :: FromJSON r, ToRow r => ByteString -> (tr -> IO ()) -> IO () > saveToDb json processRow = > case eitherDecode json of > Left err => return () -- for simplicity > Right (rows :: [r]) => forM_ rows processRow > ``` > > Thoughts? > > Thanks! > Amit > > P.S. > Thanks to Felipe for politely reminding me that these are lists we are > dealing with, not arrays! > > On 10/15/2015 02:27 PM, Adam Bergmark wrote: > > If you care about performance you may - I haven't benchmarked - want to > use > > Vector instead of lists here since that's what aeson uses internally. > Then > > it's pretty handy that you can still use forM_. > > > > It's possible that the list pattern deconstruction and list construction > > gets optimized away, my gut says you need -O2 for that to happen. Here's > a > > good explanation on how to dump and read core so you can check for > yourself > > what happens in this case: > > http://stackoverflow.com/questions/6121146/reading-ghc-core . Either way > > it's definitiely not less efficient to annotate the type instead. You > don't > > need ScopedTypeVariables here, you can write the type inside an > expression > > instead: `forM (objs :: Type) [...]` > > > > HTH, > > Adam > > > > > > On Thu, Oct 15, 2015 at 7:16 PM, Amit Aryeh Levy > wrote: > > > >> I've been running into a relatively small but frequent annoyance with > >> base >= 4.8 (GHC 7.10). `Control.Monad.foldM_`, `Control.Monad.mapM_` > >> and `Control.Monad.forM_` are generalized traverse over any `Foldable a` > >> rather than just arrays (`[a]`). > >> > >> This is great, except I'm finding that, for a lot of my code that works > >> well in previous versions, I need to specialize the argument to `[a]` > >> now. If other people are encoutering a similar patter, I wonder what are > >> your best practices for doing this: ScopedTypeVariables? Deconstruct the > >> reconstruct the array? ... > >> > >> The most common example is when I deserialize a JSON array with aeson > >> and want to traverse over that array (say, to store the objects to a > DB): > >> > >> ``` > >> let objArray = eitherDecode myjson > >> case objArray of > >> Left err -> ... > >> Right (objs :: [MyObjType]) -> > >> forM_ objs $ \obj -> saveToDb obj > >> ``` > >> > >> ?The above fix requires `ScopedTypeVariables` (which is probably OK). > >> Another option is to deconstruct and reconstruct the list: > >> > >> ``` > >> Right (o:objs) -> > >> forM_ (o:objs) $ \obj -> saveToDb obj > >> ``` > >> > >> Does this get optimized away? > >> > >> Penny for your thoughts? > >> > >> Cheers! > >> Amit > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Thu Oct 15 21:00:35 2015 From: mgsloan at gmail.com (Michael Sloan) Date: Thu, 15 Oct 2015 14:00:35 -0700 Subject: [Haskell-cafe] Specializing argument to forM_, mapM_ & foldM_ in base-4.8 In-Reply-To: <562009D4.4020807@amitlevy.com> References: <561FDF80.8000507@amitlevy.com> <562009D4.4020807@amitlevy.com> Message-ID: Hi Amit! I was initially a little confused by having both a `tr` type variable and a `r` type variable. Pretty sure that's a typo and they're intended to be the same. Otherwise you'd need to pass in something like `Proxy r` so that the usage of saveToDb constrains all the type variables. ClassyPrelude has a good solution to this problem, where you want to constrain the type of the container but not explicitly describe its contents. Check out this section: https://hackage.haskell.org/package/classy-prelude-0.12.4/docs/ClassyPrelude.html#g:27 In this case, you'd use "asList": asList :: [a] -> [a] asList = id And then use this like so: `forM_ (asList rows) processRow` Alternatively, I think this will work if you enable PartialTypeSignatures (new in 7.10): `forM_ (rows :: [_]) processRow` -Michael On Thu, Oct 15, 2015 at 1:17 PM, Amit Aryeh Levy wrote: > Thanks Adam! > > Vector does make more sense (i'll continue to use lists in this thread > just for simplicity, since I don't think it matters for the higher level > problem). > > `forM_ (objs :: Type) ....` seems like exactly the right solution in the > simple case. However, it doesn't seem to work if I try to write a more > general function. For example: > > ``` > class ToRow r > > saveToDb :: FromJSON r, ToRow r => ByteString -> (tr -> IO ()) -> IO () > saveToDb json processRow = > case eitherDecode json of > Left err => return () -- for simplicity > Right rows => forM_ (rows :: [r]) processRow > ``` > > GHC complains about two things: > > 1. eitherDecode can't determine which `FromJSON` instance to use > 2. "Couldn't match expected type [r1] with actual type a0" in `rows > :: [r]`. > > I think the issue is that GHC is not relating `rows :: [r]` to `FromJSON > r` in the function type. > > Falling back to either ScopedTypeVariables or explicit > contruction/deconstruction of the list works: > > ``` > class ToRow r > > saveToDb :: FromJSON r, ToRow r => ByteString -> (tr -> IO ()) -> IO () > saveToDb json processRow = > case eitherDecode json of > Left err => return () -- for simplicity > Right (rows :: [r]) => forM_ rows processRow > ``` > > Thoughts? > > Thanks! > Amit > > P.S. > Thanks to Felipe for politely reminding me that these are lists we are > dealing with, not arrays! > > On 10/15/2015 02:27 PM, Adam Bergmark wrote: > > If you care about performance you may - I haven't benchmarked - want to > use > > Vector instead of lists here since that's what aeson uses internally. > Then > > it's pretty handy that you can still use forM_. > > > > It's possible that the list pattern deconstruction and list construction > > gets optimized away, my gut says you need -O2 for that to happen. Here's > a > > good explanation on how to dump and read core so you can check for > yourself > > what happens in this case: > > http://stackoverflow.com/questions/6121146/reading-ghc-core . Either way > > it's definitiely not less efficient to annotate the type instead. You > don't > > need ScopedTypeVariables here, you can write the type inside an > expression > > instead: `forM (objs :: Type) [...]` > > > > HTH, > > Adam > > > > > > On Thu, Oct 15, 2015 at 7:16 PM, Amit Aryeh Levy > wrote: > > > >> I've been running into a relatively small but frequent annoyance with > >> base >= 4.8 (GHC 7.10). `Control.Monad.foldM_`, `Control.Monad.mapM_` > >> and `Control.Monad.forM_` are generalized traverse over any `Foldable a` > >> rather than just arrays (`[a]`). > >> > >> This is great, except I'm finding that, for a lot of my code that works > >> well in previous versions, I need to specialize the argument to `[a]` > >> now. If other people are encoutering a similar patter, I wonder what are > >> your best practices for doing this: ScopedTypeVariables? Deconstruct the > >> reconstruct the array? ... > >> > >> The most common example is when I deserialize a JSON array with aeson > >> and want to traverse over that array (say, to store the objects to a > DB): > >> > >> ``` > >> let objArray = eitherDecode myjson > >> case objArray of > >> Left err -> ... > >> Right (objs :: [MyObjType]) -> > >> forM_ objs $ \obj -> saveToDb obj > >> ``` > >> > >> ?The above fix requires `ScopedTypeVariables` (which is probably OK). > >> Another option is to deconstruct and reconstruct the list: > >> > >> ``` > >> Right (o:objs) -> > >> forM_ (o:objs) $ \obj -> saveToDb obj > >> ``` > >> > >> Does this get optimized away? > >> > >> Penny for your thoughts? > >> > >> Cheers! > >> Amit > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > >> > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit at amitlevy.com Thu Oct 15 21:17:09 2015 From: amit at amitlevy.com (Amit Aryeh Levy) Date: Thu, 15 Oct 2015 17:17:09 -0400 Subject: [Haskell-cafe] Specializing argument to forM_, mapM_ & foldM_ in base-4.8 In-Reply-To: References: <561FDF80.8000507@amitlevy.com> <562009D4.4020807@amitlevy.com> Message-ID: <562017D5.2050005@amitlevy.com> Hey Michael! On 10/15/2015 05:00 PM, Michael Sloan wrote: > Hi Amit! > > I was initially a little confused by having both a `tr` type variable and a > `r` type variable. Pretty sure that's a typo and they're intended to be > the same. Otherwise you'd need to pass in something like `Proxy r` so that > the usage of saveToDb constrains all the type variables. Yes, that was a typo... sorry about that... > > ClassyPrelude has a good solution to this problem, where you want to > constrain the type of the container but not explicitly describe its > contents. Check out this section: > https://hackage.haskell.org/package/classy-prelude-0.12.4/docs/ClassyPrelude.html#g:27 > > In this case, you'd use "asList": > > asList :: [a] -> [a] > asList = id > > And then use this like so: `forM_ (asList rows) processRow` Oh awesome! > > Alternatively, I think this will work if you enable PartialTypeSignatures > (new in 7.10): `forM_ (rows :: [_]) processRow` Also cool, although a new extension won't be backwards compatable, which is unfortunate for such simple code. But good to learn about it anyway! > > -Michael > > On Thu, Oct 15, 2015 at 1:17 PM, Amit Aryeh Levy wrote: > >> Thanks Adam! >> >> Vector does make more sense (i'll continue to use lists in this thread >> just for simplicity, since I don't think it matters for the higher level >> problem). >> >> `forM_ (objs :: Type) ....` seems like exactly the right solution in the >> simple case. However, it doesn't seem to work if I try to write a more >> general function. For example: >> >> ``` >> class ToRow r >> >> saveToDb :: FromJSON r, ToRow r => ByteString -> (tr -> IO ()) -> IO () >> saveToDb json processRow = >> case eitherDecode json of >> Left err => return () -- for simplicity >> Right rows => forM_ (rows :: [r]) processRow >> ``` >> >> GHC complains about two things: >> >> 1. eitherDecode can't determine which `FromJSON` instance to use >> 2. "Couldn't match expected type [r1] with actual type a0" in `rows >> :: [r]`. >> >> I think the issue is that GHC is not relating `rows :: [r]` to `FromJSON >> r` in the function type. >> >> Falling back to either ScopedTypeVariables or explicit >> contruction/deconstruction of the list works: >> >> ``` >> class ToRow r >> >> saveToDb :: FromJSON r, ToRow r => ByteString -> (tr -> IO ()) -> IO () >> saveToDb json processRow = >> case eitherDecode json of >> Left err => return () -- for simplicity >> Right (rows :: [r]) => forM_ rows processRow >> ``` >> >> Thoughts? >> >> Thanks! >> Amit >> >> P.S. >> Thanks to Felipe for politely reminding me that these are lists we are >> dealing with, not arrays! >> >> On 10/15/2015 02:27 PM, Adam Bergmark wrote: >>> If you care about performance you may - I haven't benchmarked - want to >> use >>> Vector instead of lists here since that's what aeson uses internally. >> Then >>> it's pretty handy that you can still use forM_. >>> >>> It's possible that the list pattern deconstruction and list construction >>> gets optimized away, my gut says you need -O2 for that to happen. Here's >> a >>> good explanation on how to dump and read core so you can check for >> yourself >>> what happens in this case: >>> http://stackoverflow.com/questions/6121146/reading-ghc-core . Either way >>> it's definitiely not less efficient to annotate the type instead. You >> don't >>> need ScopedTypeVariables here, you can write the type inside an >> expression >>> instead: `forM (objs :: Type) [...]` >>> >>> HTH, >>> Adam >>> >>> >>> On Thu, Oct 15, 2015 at 7:16 PM, Amit Aryeh Levy >> wrote: >>>> I've been running into a relatively small but frequent annoyance with >>>> base >= 4.8 (GHC 7.10). `Control.Monad.foldM_`, `Control.Monad.mapM_` >>>> and `Control.Monad.forM_` are generalized traverse over any `Foldable a` >>>> rather than just arrays (`[a]`). >>>> >>>> This is great, except I'm finding that, for a lot of my code that works >>>> well in previous versions, I need to specialize the argument to `[a]` >>>> now. If other people are encoutering a similar patter, I wonder what are >>>> your best practices for doing this: ScopedTypeVariables? Deconstruct the >>>> reconstruct the array? ... >>>> >>>> The most common example is when I deserialize a JSON array with aeson >>>> and want to traverse over that array (say, to store the objects to a >> DB): >>>> ``` >>>> let objArray = eitherDecode myjson >>>> case objArray of >>>> Left err -> ... >>>> Right (objs :: [MyObjType]) -> >>>> forM_ objs $ \obj -> saveToDb obj >>>> ``` >>>> >>>> ?The above fix requires `ScopedTypeVariables` (which is probably OK). >>>> Another option is to deconstruct and reconstruct the list: >>>> >>>> ``` >>>> Right (o:objs) -> >>>> forM_ (o:objs) $ \obj -> saveToDb obj >>>> ``` >>>> >>>> Does this get optimized away? >>>> >>>> Penny for your thoughts? >>>> >>>> Cheers! >>>> Amit >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From capn.freako at gmail.com Fri Oct 16 03:44:42 2015 From: capn.freako at gmail.com (David Banas) Date: Thu, 15 Oct 2015 20:44:42 -0700 Subject: [Haskell-cafe] Talk at tonight's Haskell Meetup at the Hacker Dojo. In-Reply-To: References: Message-ID: Slides are posted: https://github.com/capn-freako/treeviz (?FFT_via_Circat.pdf?) -db On Oct 15, 2015, at 12:18 PM, KC wrote: > We in Canada like to learn a thing or three ... :D > > -- > -- > > Sent from an expensive device which will be obsolete in a few months! :D > > Casey > > > On Oct 15, 2015 12:15 PM, "David Banas" wrote: > Yes, assuming Meetup has infrastructure in place for doing so. > I'll check w/ Tim on that. > -db > > > On Thu, Oct 15, 2015 at 11:35 AM, KC wrote: > Will slides be posted? > > -- > -- > > Sent from an expensive device which will be obsolete in a few months! :D > > Casey > > > On Oct 15, 2015 7:33 AM, "David Banas" wrote: > Hi all, > > I plan to give a short talk, at tonight?s Haskell Meetup at the Hacker Dojo in Mountain View, CA, on using Conal?s Circat and Lambda-CCC machinery to implement the Fast Fourier Transform (FFT). > > Hope to see you there, > -db > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.drautzburg at web.de Fri Oct 16 07:32:19 2015 From: martin.drautzburg at web.de (martin) Date: Fri, 16 Oct 2015 09:32:19 +0200 Subject: [Haskell-cafe] How to specialize a type Message-ID: <5620A803.7040403@web.de> Hello all, Suppose I have a type "Process" which stands either for a Train or a moving Belt. In both cases there is a place of departure and a place of arrival. However the other parameters which describe a Process differ. A Train has departure and arrival times, but a Belt has a speed. I tried the following: type PlaceDep = Int type PlaceArr = Int data Process = Train PlaceDep PlaceArr TP | MovingBelt PlaceDep PlaceArr BP deriving (Eq, Show) data TP = TP Int deriving (Eq, Show) data BP = BP Int deriving (Eq, Show) prc1 = Train 10 11 (TP 1) prc2 = MovingBelt 12 13 (BP 2) What I don't like about this is that the fact that all Processes have PlaceDep and PlaceArr appears somewhat "coincidental". This in contrast, captures the common parts more clearly: type PlaceDep = Int type PlaceArr = Int data ProcessParams = DepartureTime Int | Speed Int deriving (Eq, Show) data Process = Process PlaceDep PlaceArr ProcessParams deriving (Eq, Show) prc1 = Process 10 11 (DepartureTime 1) prc2 = Process 12 13 (Speed 2) Is this the classic way of specializing a type or are there better options See also: http://stackoverflow.com/questions/33156656/subclassing-a-type-in-haskell/33156888?noredirect=1#comment54137571_33156888 From mwm at mired.org Fri Oct 16 14:21:46 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 16 Oct 2015 14:21:46 +0000 Subject: [Haskell-cafe] Building 32-bit binaries on a 64-bit system? Message-ID: I've got someone who wants to run one of my haskell apps on a 32-bit Windows 10 box. I've pretty much moved to 64-bit everywhere, so don't have such a system to build on. Is it possible to get stack/cabal/ghc to build a 32-bit Windows binary on a 64-bit Windows box? Google found a bunch of things about building 64 bit applications, and the ghc manual doesn't seem to have such an option. So do I need to get a 32-bit system for this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Fri Oct 16 14:24:02 2015 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 16 Oct 2015 14:24:02 +0000 Subject: [Haskell-cafe] Building 32-bit binaries on a 64-bit system? In-Reply-To: References: Message-ID: Stack has a command line argument --arch, mostly intended for the Windows case. Try stack --install-ghc --arch i386 build, it should do what you want. On Fri, Oct 16, 2015, 5:22 PM Mike Meyer wrote: > I've got someone who wants to run one of my haskell apps on a 32-bit > Windows 10 box. I've pretty much moved to 64-bit everywhere, so don't have > such a system to build on. > > Is it possible to get stack/cabal/ghc to build a 32-bit Windows binary on > a 64-bit Windows box? Google found a bunch of things about building 64 bit > applications, and the ghc manual doesn't seem to have such an option. So do > I need to get a 32-bit system for this? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomberek at gmail.com Fri Oct 16 18:58:47 2015 From: tomberek at gmail.com (Thomas Bereknyei) Date: Fri, 16 Oct 2015 14:58:47 -0400 Subject: [Haskell-cafe] Future of FPComplete Haskell Center (IDE) Message-ID: FPComplete is deprecating Haskell Center and removing support for their hosted IDE at the end of the year. I enjoy using the IDE in many situations and would like to have a similar capability available to the community. I know several people have expressed interest in helping maintain a version that can go on. Michael Snoyman has stated that there are some issues with the existing codebase and that there are many things that can/should be improved. There are some limitations due to NDA, but I believe FPComplete would be willing to hand over much of the codebase. I intend this thread to bring together those people interested in helping with this effort in any way. Personally, I would be willing to provide limited hosting and some development support. My goals would be to upgrade support to 8.x GHC, latest Stackage - LTS and create a path for people to self-host the IDE. -Tom Bereknyei -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomn at beautifuldestinations.com Fri Oct 16 20:46:38 2015 From: tomn at beautifuldestinations.com (Tom Nielsen) Date: Fri, 16 Oct 2015 21:46:38 +0100 Subject: [Haskell-cafe] Three open positions at Beautiful Destinations Message-ID: The Data Science team at Beautiful Destinations is looking for three full-time developers and researchers with strong quantitative and programming skills. Beautiful Destinations ( http://www.beautifuldestinations.com/) is the world's largest travel influencer with a highly engaged audience of over 7 million followers across Instagram, Facebook and Snapchat. Beautiful Destinations distributes beautiful travel photography to its followers and helps clients to grow their social media channels. Our in-house photographers use drones and still photography to create content for our own accounts and our clients. The data science team has three aims: to predict and enhance the engagement of photographs on specific accounts; to measure influence on social media; and to determine the factors that contribute to the growth of social media accounts. Our internal API and core infrastructure are written in Haskell (using PostgreSQL), our Bayesian statistical time-series models use Stan ( http://mc-stan.org/) as well as some statistical models in Haskell. For image processing we use convolutional neural networks (in Python) and SIFT (C++/CUDA/Haskell). We are open to people bringing their preferred tools and maintain a polyglot environment. We are looking for developers who can fill the gap between data science and software engineering. We are at this stage only looking for full-time employees who can work in our London office. We welcome recent graduates and applicants with non-traditional backgrounds who show strong programming skills and capacity for independent learning. Please email contact at beautifuldestinations.com with any questions or with a CV if you are interested in this opportunity. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Fri Oct 16 22:30:44 2015 From: danburton.email at gmail.com (Dan Burton) Date: Fri, 16 Oct 2015 16:30:44 -0600 Subject: [Haskell-cafe] Future of FPComplete Haskell Center (IDE) In-Reply-To: References: Message-ID: I would ultimately like to see ghcjs running entirely in the browser, converting hs projects to js that can be run right there in the browser. That way nobody would need to host the build service. I imagine we're still quite a long way from accomplishing that. On Friday, October 16, 2015, Thomas Bereknyei wrote: > FPComplete is deprecating Haskell Center and removing support for their > hosted IDE at the end of the year. I enjoy using the IDE in many situations > and would like to have a similar capability available to the community. I > know several people have expressed interest in helping maintain a version > that can go on. > > Michael Snoyman has stated that there are some issues with the existing > codebase and that there are many things that can/should be improved. There > are some limitations due to NDA, but I believe FPComplete would be willing > to hand over much of the codebase. > > I intend this thread to bring together those people interested in helping > with this effort in any way. Personally, I would be willing to provide > limited hosting and some development support. My goals would be to upgrade > support to 8.x GHC, latest Stackage - LTS and create a path for people to > self-host the IDE. > > -Tom Bereknyei > -- -- Dan Burton -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben.astud at gmail.com Sat Oct 17 06:08:44 2015 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Sat, 17 Oct 2015 03:08:44 -0300 Subject: [Haskell-cafe] How to specialize a type In-Reply-To: <5620A803.7040403@web.de> References: <5620A803.7040403@web.de> Message-ID: <5621E5EC.2000803@gmail.com> Hi. You stack-overflow had good answers, I don't think I will shed new light on this. But still I will give it a try. On 16/10/15 04:32, martin wrote: > Hello all, > > Suppose I have a type "Process" which stands either for a Train or a > moving Belt. In both cases there is a place of departure and a place of > arrival. However the other parameters which describe a Process differ. > A Train has departure and arrival times, but a Belt has a speed. > > I tried the following: > > > type PlaceDep = Int > type PlaceArr = Int > > data Process = Train PlaceDep PlaceArr TP > | MovingBelt PlaceDep PlaceArr BP deriving (Eq, Show) > > data TP = TP Int deriving (Eq, Show) > data BP = BP Int deriving (Eq, Show) You could use a newtype here. This is the intended use case of them as you want a semantically different type but an underlying same representation (and possible some instances of such representation). Something like this newtype TP = TP Int deriving (Eq, Show) newtype BP = BP Int deriving (Eq, Show) > prc1 = Train 10 11 (TP 1) > prc2 = MovingBelt 12 13 (BP 2) > > > What I don't like about this is that the fact that all Processes have > PlaceDep and PlaceArr appears somewhat "coincidental". > > This in contrast, captures the common parts more clearly: > > type PlaceDep = Int > type PlaceArr = Int > > data ProcessParams = DepartureTime Int | Speed Int > deriving (Eq, Show) > > data Process = Process PlaceDep PlaceArr ProcessParams > deriving (Eq, Show) > > prc1 = Process 10 11 (DepartureTime 1) > prc2 = Process 12 13 (Speed 2) This just seems a trade-off if you want to know with what are you dealing just matching the outer constructor or more of the problem won't care about it. Not really a dichotomy worth caring about much anyways > Is this the classic way of specializing a type or are there better options I would just stick to sum types (the first approach) but I don't know the whole context of the problem. BTW "specializing a type" has a concrete meaning in haskell. It grabs a polymorphic function and gives it a more concrete type. An usual example is id :: a -> a id x = x id2 :: Char -> Char id2 c = id c which hopefully is clear on what I am going about From martin.drautzburg at web.de Sat Oct 17 10:40:46 2015 From: martin.drautzburg at web.de (martin) Date: Sat, 17 Oct 2015 12:40:46 +0200 Subject: [Haskell-cafe] How to specialize a type In-Reply-To: <5621E5EC.2000803@gmail.com> References: <5620A803.7040403@web.de> <5621E5EC.2000803@gmail.com> Message-ID: <562225AE.5090406@web.de> Am 10/17/2015 um 08:08 AM schrieb Ruben Astudillo: >> data Process = Train PlaceDep PlaceArr TP >> | MovingBelt PlaceDep PlaceArr BP deriving (Eq, Show) >> >> data TP = TP Int deriving (Eq, Show) >> data BP = BP Int deriving (Eq, Show) > > You could use a newtype here. Point taken >> What I don't like about this is that the fact that all Processes have >> PlaceDep and PlaceArr appears somewhat "coincidental". >> >> This in contrast, captures the common parts more clearly: >> >> type PlaceDep = Int >> type PlaceArr = Int >> >> data ProcessParams = DepartureTime Int | Speed Int >> deriving (Eq, Show) >> >> data Process = Process PlaceDep PlaceArr ProcessParams >> deriving (Eq, Show) >> >> prc1 = Process 10 11 (DepartureTime 1) >> prc2 = Process 12 13 (Speed 2) > > This just seems a trade-off if you want to know with what are you dealing > just matching the outer constructor or more of the problem won't care > about it. Not really a dichotomy worth caring about much anyways I'll have to think about this. Wouldn't this be a problem when writing functions which operate on a Process of any type? Like e.g. changeDeparture :: PlaceDep -> Process -> Process I would have to pattern match against all the constructors, wouldn't I? If I don't have just two Processes types, but 20 of them, wouldn't that become messy? In the second approach I only have to match Process and I can be certain there is a PlaceDep to be altered. From oleg at okmij.org Sat Oct 17 11:14:21 2015 From: oleg at okmij.org (Oleg) Date: Sat, 17 Oct 2015 20:14:21 +0900 Subject: [Haskell-cafe] Trying to write an Embedded DSL that threads a monad? In-Reply-To: Message-ID: <20151017111421.GA2086@Magus.sf-private> > Thanks for pointing that out, this is my first time encountering > tagless-final. The use of the :-> data constructor seems to solve a lot of > problems. It truth the :-> constructor does not bring anything new. When we write Symantics defining the EDSL as class Symantics repr where lam :: (repr a -> repr b) -> repr (a->b) then the first and the second occurrences of '->' refer to Haskell functions. However, the last occurrence of '->', in repr (a->b), refers to a function of the EDSL -- to the object function rather than the meta-language function. It is convenient to use the same operator '->' for both, but we should understand these are different entities. The constructor :-> just makes the distinction clear. This is similar to the idiomatic Haskell definition like newtype Foo a = Foo (a -> String) where the two occurrences of Foo refer to different things: one is a type constructor and the other is a data constructor. Whereas the meaning of Haskell's '->' is fixed, the meaning of the object language '->' is up to the interpreter. It could be a function, it could be a monadic function, it could be anything that takes two type arguments (and uses them in some way, or throws them away). > I'm wondering how to introduce a haskell function as an embedded > value in such an EDSL but I think I will try it out. First of all, lam above already showed how to turn a Haskell function, of a particular type (repr a -> repr b), into the EDSL function. One can `embed' any Haskell function, by adding to Semantics the method lift :: (a -> b) -> repr (a -> b) for example. But your interpreters may need to implement it! It may be simpler to restrict the class of functions you want to embed. Thus, you will define methods of Semantics plus :: repr (Int -> Int -> Int) minus :: repr (Int -> Int -> Int) etc. Since one can add more methods at any time, we do not need to imagine right upfront all the functions we may wish to embed. We can add more as the need arises. Finally, if all your are interested is counting operations (and perhaps writing some logs), you don't need any monads. Tagless-Final tutorials (and the JFP paper) demonstrated many interpreters that do counting (the size of the term, the depth of the term, etc). If you wish to count reductions, you will define the variation on the R interpreter as shown below. Whether RCount is a monad or not, I don't even care. There is nothing there that requires it. {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE NoMonomorphismRestriction #-} module Count where class Symantics repr where int :: Int -> repr Int plus :: repr (Int -> Int -> Int) lam :: (repr a -> repr b) -> repr (a -> b) app :: repr (a->b) -> (repr a -> repr b) infixl 1 `app` -- meta-circular interpreter with counting type Count = Int data RCount a = RCount (TC a) Count type family TC a where TC (a -> b) = RCount a -> RCount b TC a = a instance Symantics RCount where int x = RCount x 0 plus = RCount (\ (RCount x cx) -> RCount (\ (RCount y cy) -> RCount (x+y) (cx+cy)) 0) 0 lam f = RCount f 0 app (RCount f cf) x = let (RCount v cv) = f x in RCount v (cf+cv+1) test1 = lam (\x -> plus `app` x `app` (plus `app` x `app` int 1)) `app` (int 3) test1R = let (RCount x c) = test1 in (x,c) -- (7, 5) -- There are indeed 5 occurrences of app in test1 test2 = lam (\x -> plus `app` x `app` (plus `app` x `app` int 1)) `app` (plus `app` (int 3) `app` (int 4)) test2R = let (RCount x c) = test2 in (x,c) -- (15, 9) -- our semantics is CBName! From mwm at mired.org Sat Oct 17 12:29:22 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 17 Oct 2015 12:29:22 +0000 Subject: [Haskell-cafe] Building 32-bit binaries on a 64-bit system? In-Reply-To: References: Message-ID: Thanks, the worked like a charm! Any chance this can be used for cross-compiling from a Unix desktop to embedded arm? On Fri, Oct 16, 2015, 09:24 Michael Snoyman wrote: > Stack has a command line argument --arch, mostly intended for the Windows > case. Try stack --install-ghc --arch i386 build, it should do what you want. > > On Fri, Oct 16, 2015, 5:22 PM Mike Meyer wrote: > >> I've got someone who wants to run one of my haskell apps on a 32-bit >> Windows 10 box. I've pretty much moved to 64-bit everywhere, so don't have >> such a system to build on. >> >> Is it possible to get stack/cabal/ghc to build a 32-bit Windows binary on >> a 64-bit Windows box? Google found a bunch of things about building 64 bit >> applications, and the ghc manual doesn't seem to have such an option. So do >> I need to get a 32-bit system for this? >> > _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Sat Oct 17 14:04:43 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat, 17 Oct 2015 17:04:43 +0300 Subject: [Haskell-cafe] Building 32-bit binaries on a 64-bit system? In-Reply-To: References: Message-ID: <5622557B.20007@ro-che.info> On 10/17/2015 03:29 PM, Mike Meyer wrote: > Thanks, the worked like a charm! Any chance this can be used for > cross-compiling from a Unix desktop to embedded arm? Not as easy as that. This solution relies on the fact that you can run i386 binaries on x86-64, which is obviously not true for arm. See https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling for how to build a cross-compiler. > On Fri, Oct 16, 2015, 09:24 Michael Snoyman > wrote: > > Stack has a command line argument --arch, mostly intended for the > Windows case. Try stack --install-ghc --arch i386 build, it should > do what you want. > > > On Fri, Oct 16, 2015, 5:22 PM Mike Meyer > wrote: > > I've got someone who wants to run one of my haskell apps on a > 32-bit Windows 10 box. I've pretty much moved to 64-bit > everywhere, so don't have such a system to build on. > > Is it possible to get stack/cabal/ghc to build a 32-bit Windows > binary on a 64-bit Windows box? Google found a bunch of things > about building 64 bit applications, and the ghc manual doesn't > seem to have such an option. So do I need to get a 32-bit system > for this? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tomas.carnecky at gmail.com Sat Oct 17 16:11:22 2015 From: tomas.carnecky at gmail.com (Tomas Carnecky) Date: Sat, 17 Oct 2015 16:11:22 +0000 Subject: [Haskell-cafe] STM and garbage collector Message-ID: If a thread is blocking indefinitely in an STM transaction (reading from a queue to which nobody else has a reference and thus can not write into), is the runtime smart enough to GC the thread? Or do I have to kill the thread manually? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanablack at amok.cc Sat Oct 17 16:19:17 2015 From: lanablack at amok.cc (Lana Black) Date: Sat, 17 Oct 2015 16:19:17 +0000 Subject: [Haskell-cafe] Building 32-bit binaries on a 64-bit system? In-Reply-To: <5622557B.20007@ro-che.info> References: <5622557B.20007@ro-che.info> Message-ID: <20151017161917.26263640.3861.576@amok.cc> One can run arm binaries on x86_64 using qemu user emulation and binfmt on linux. ? Original Message ? From: Roman Cheplyaka Sent: Saturday, October 17, 2015 2:04 PM To: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Building 32-bit binaries on a 64-bit system? On 10/17/2015 03:29 PM, Mike Meyer wrote: > Thanks, the worked like a charm! Any chance this can be used for > cross-compiling from a Unix desktop to embedded arm? Not as easy as that. This solution relies on the fact that you can run i386 binaries on x86-64, which is obviously not true for arm. See https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling for how to build a cross-compiler. > On Fri, Oct 16, 2015, 09:24 Michael Snoyman > wrote: > > Stack has a command line argument --arch, mostly intended for the > Windows case. Try stack --install-ghc --arch i386 build, it should > do what you want. > > > On Fri, Oct 16, 2015, 5:22 PM Mike Meyer > wrote: > > I've got someone who wants to run one of my haskell apps on a > 32-bit Windows 10 box. I've pretty much moved to 64-bit > everywhere, so don't have such a system to build on. > > Is it possible to get stack/cabal/ghc to build a 32-bit Windows > binary on a 64-bit Windows box? Google found a bunch of things > about building 64 bit applications, and the ghc manual doesn't > seem to have such an option. So do I need to get a 32-bit system > for this? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From ruben.astud at gmail.com Sat Oct 17 16:28:06 2015 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Sat, 17 Oct 2015 13:28:06 -0300 Subject: [Haskell-cafe] How to specialize a type In-Reply-To: <562225AE.5090406@web.de> References: <5620A803.7040403@web.de> <5621E5EC.2000803@gmail.com> <562225AE.5090406@web.de> Message-ID: <56227716.2060504@gmail.com> On 17/10/15 07:40, martin wrote: > Am 10/17/2015 um 08:08 AM schrieb Ruben Astudillo: > >> This just seems a trade-off if you want to know with what are you dealing >> just matching the outer constructor or more of the problem won't care >> about it. Not really a dichotomy worth caring about much anyways > > I'll have to think about this. Wouldn't this be a problem when writing > functions which operate on a Process of any type? Like e.g. > > changeDeparture :: PlaceDep -> Process -> Process > > I would have to pattern match against all the constructors, wouldn't I? > If I don't have just two Processes types, but 20 of them, wouldn't that > become messy? > > In the second approach I only have to match Process and I can be > certain there is a PlaceDep to be altered. That is the tradeoff between caring more if they are a belt/train or you don't except in some functions which can pay the price of pattern matching on inner constructors. If you have many functions as changeDeparture I would go with the approach you say, but otherwise I would go with the first just because seems clearer to me. This is a question of "what you problem requires more" than a "always use this option" thing. What I can tell you is what other options you have at your disposal so you can consider them. A common option is to provide on the module the data type is defined the only functions that operate directly on the constructors such that every other operation can be implemented as composition of such functions. The classical example is FIFOs where pop :: FIFO a -> Maybe a peek :: FIFO a -> Maybe a push :: a -> FIFO a -> FIFO a Would be the only functions allowed to pattern match on the constructors for them you are sure they don't leak the underlying implementation (you want abstraction) and they give you the semantics of the FIFO. This way you can omit the constructors from the exports of the module and get function that operate of all the sum branches without explicit pattern matching. There is other more fine alternative in GHC called ViewPatterns[1] & PatternSynonyms[2]. The first does something like what Data.Sequence does with their view and ViewL datatype. The second is probably more interesting to your use case. It provides an alternative "pattern" which you can see as an alternate constructor for both branches of your data. So in your example you could write if you go with your last alternative (I hope I get this right). pattern Train a b (TP c) = Process a b (DepartureTime c) pattern Belt a b (BP c) = Process a b (Speed c) Which let you use Train/Belt as constructor in the functions you want on top of the usual Process constructor which you probably want to use more commonly. [1]: https://ghc.haskell.org/trac/ghc/wiki/ViewPatterns [2]: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms From electreg at list.ru Sun Oct 18 02:37:45 2015 From: electreg at list.ru (=?UTF-8?B?QWxleGV5IEVnb3Jvdg==?=) Date: Sun, 18 Oct 2015 05:37:45 +0300 Subject: [Haskell-cafe] =?utf-8?q?make_an_PrimMonad-wrapped_FFI_call?= Message-ID: <1445135865.92692945@f237.i.mail.ru> Hello haskellers, I'm writing FFI bindings to C library which uses some allocations across functions call, for example: int *alloc_buf(void); void free_buf(int *); So I need to use newForeignPtr to make sure buffer will be free'd when all pointers to it get collected. But what if I want to do this in PrimMonad (say, ST) and not IO (returned by newForeignPtr)? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Sun Oct 18 03:23:28 2015 From: mgsloan at gmail.com (Michael Sloan) Date: Sat, 17 Oct 2015 20:23:28 -0700 Subject: [Haskell-cafe] STM and garbage collector In-Reply-To: References: Message-ID: In this case, the GC will indeed find that no one has a reference to the thread. However, instead of garbage collecting the thread, the BlockedIndefinitely exception is thrown to it. So, it resumes execution of the thread with that exception. This also applies to threads blocked on MVars. -Michael On Sat, Oct 17, 2015 at 9:11 AM, Tomas Carnecky wrote: > If a thread is blocking indefinitely in an STM transaction (reading from a > queue to which nobody else has a reference and thus can not write into), is > the runtime smart enough to GC the thread? Or do I have to kill the thread > manually? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.carnecky at gmail.com Sun Oct 18 09:45:52 2015 From: tomas.carnecky at gmail.com (Tomas Carnecky) Date: Sun, 18 Oct 2015 09:45:52 +0000 Subject: [Haskell-cafe] STM and garbage collector In-Reply-To: References: Message-ID: Who throws the exception? Documentation of `throwTo` sais that the calling thread is blocked until the exception is delivered. If the target thread has async exceptions masked then the exception is never delivered. Does that also mean a blocked thread which has async exceptions masked is, essentially, a resource leak? On Sun, Oct 18, 2015 at 5:23 AM Michael Sloan wrote: > In this case, the GC will indeed find that no one has a reference to the > thread. However, instead of garbage collecting the thread, the > BlockedIndefinitely exception is thrown to it. So, it resumes execution of > the thread with that exception. > > This also applies to threads blocked on MVars. > > -Michael > > On Sat, Oct 17, 2015 at 9:11 AM, Tomas Carnecky > wrote: > >> If a thread is blocking indefinitely in an STM transaction (reading from >> a queue to which nobody else has a reference and thus can not write into), >> is the runtime smart enough to GC the thread? Or do I have to kill the >> thread manually? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Sun Oct 18 10:42:57 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 18 Oct 2015 13:42:57 +0300 Subject: [Haskell-cafe] STM and garbage collector In-Reply-To: References: Message-ID: <562377B1.5020003@ro-che.info> On 10/18/2015 12:45 PM, Tomas Carnecky wrote: > Who throws the exception? The RTS. > Documentation of `throwTo` sais that the > calling thread is blocked until the exception is delivered. If the > target thread has async exceptions masked then the exception is never > delivered. First, to attempt to cause that block, you'd have to use uninterruptibleMask, because the ordinary mask still lets the exceptions through when the thread is blocked. Second, in the case of BlockedIndefinitelyOnSTM and similar conditions, the RTS doesn't go through throwTo, but raises the exception directly, so even uninterruptibleMask won't hold it. See resurrectThreads in rts/Schedule.c. > Does that also mean a blocked thread which has async exceptions masked > is, essentially, a resource leak? > > On Sun, Oct 18, 2015 at 5:23 AM Michael Sloan > wrote: > > In this case, the GC will indeed find that no one has a reference to > the thread. However, instead of garbage collecting the thread, the > BlockedIndefinitely exception is thrown to it. So, it resumes > execution of the thread with that exception. > > This also applies to threads blocked on MVars. > > -Michael > > On Sat, Oct 17, 2015 at 9:11 AM, Tomas Carnecky > > wrote: > > If a thread is blocking indefinitely in an STM transaction > (reading from a queue to which nobody else has a reference and > thus can not write into), is the runtime smart enough to GC the > thread? Or do I have to kill the thread manually? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From srodal at gmail.com Sun Oct 18 14:40:19 2015 From: srodal at gmail.com (=?UTF-8?Q?Samuel_R=C3=B8dal?=) Date: Sun, 18 Oct 2015 21:40:19 +0700 Subject: [Haskell-cafe] MonadFix wiki confusion Message-ID: Hello, the MonadFix wiki at https://wiki.haskell.org/MonadFix has a statement that I feel is a bit misleading. In section "2.2 Lazy algorithm interleaved with effects", it claims that making the BTree data structure strict doesn't cause endless recursion. Well, that's true, but that's just because rep_x_sum returns a tuple containing the BTree and the summed values of the current subtree, and the tuple is lazily constructed - postponing the construction of the tree value. So highlighting the fact that the function still works when the BTree structure is made strict is kind of a red herring. Maybe the confusion could be avoided by removing the part about making BTree strict, or adding a note about the tuple still ensuring lazy construction? -- Samuel From mwm at mired.org Sun Oct 18 16:00:10 2015 From: mwm at mired.org (Mike Meyer) Date: Sun, 18 Oct 2015 16:00:10 +0000 Subject: [Haskell-cafe] Cross-compiling for arm? In-Reply-To: <5622557B.20007@ro-che.info> References: <5622557B.20007@ro-che.info> Message-ID: On Sat, Oct 17, 2015 at 9:04 AM Roman Cheplyaka wrote: > On 10/17/2015 03:29 PM, Mike Meyer wrote: > > Thanks, the worked like a charm! Any chance this can be used for > > cross-compiling from a Unix desktop to embedded arm? > > Not as easy as that. This solution relies on the fact that you can run > i386 binaries on x86-64, which is obviously not true for arm. > Yeah, I sort of expected that. But i'd be nice if it works. > See https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling for > how to build a cross-compiler. > Doesn't work for me for building embedded code. The target arm-none-eabi fails to configure because gcc doesn't work, because _exit doesn't exist. Which is indeed the case. I don't see any way to turn that off. Is this not supported by ghc? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Oct 18 18:49:58 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 18 Oct 2015 20:49:58 +0200 (CEST) Subject: [Haskell-cafe] How to avoid CPP (Was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> Message-ID: On Mon, 5 Oct 2015, Gregory Collins wrote: > Um, no, it usually isn't anything like that. Here's a sampling of some of the things I've used CPP for in the past few > years: > * After GHC 7.4, when using a newtype in FFI imports you need to import the constructor, i.e. "import > Foreign.C.Types(CInt(..))" --- afaik CPP is the only way to shut up warnings everywhere I import them qualified and then define type CInt = CTypes.CInt sometimes. > * defaultTimeLocale moved from System.Locale to Data.Time.Format in time-1.5 (no compat package for this, afaik) I was advised to always import time-1.5. > * one of many various changes to Typeable in the GHC 7.* series (deriving works better now, mkTyCon vs mkTyCon3, etc) I have not used that. Like I have not used the ever changing Template Haskell stuff. > * Do I have to hide "catch" from Prelude, or not? It got moved, and "hiding" gives an error if the symbol you're trying > to hide is missing. Time to break out the CPP (and curse myself for not just using the qualified import in the first > place) I think System.IO.Error.catchIOError maintains the old behaviour. > * Do I get monoid functions from Prelude or from Data.Monoid? Same w/ Applicative, Foldable, Word. I don't know where > anything is supposed to live anymore, or which sequence of imports will shut up spurious warnings on all four versions > of GHC I support, so the lowest-friction fix is: break out the #ifdef spackle I always import them from the most specific module. Where GHC-7.10 Prelude causes conflicts I even started to import more basic Prelude stuff from modules like Data.Bool, Data.Eq and friends. Horrible, but works without CPP. > * ==# and friends return Int# instead of Bool after GHC 7.8.1 I did not use it. I have also warned that the change might not be a good idea since LLVM knows that its 'i1' type can only have the values 0 and 1 and it does not know that for 'i32' or 'i64'. > * To use functions like "tryReadMVar", "unsafeShiftR", and "atomicModifyIORef'" that are in recent base versions but not > older ones (this is a place where CPP use is actually justified) I have not used them so far. I have solved more complicated cases with conditional Hs-Source-Dirs: http://wiki.haskell.org/Cabal/Developer-FAQ#Adapt_to_different_systems_without_CPP It's cumbersome but so far I managed most transitions without CPP. (Nonetheless, MRP would require the complicated Hs-Source-Dirs solution for far too many packages.) From erantapaa at gmail.com Mon Oct 19 04:50:14 2015 From: erantapaa at gmail.com (Erik Rantapaa) Date: Sun, 18 Oct 2015 21:50:14 -0700 (PDT) Subject: [Haskell-cafe] hoogte db for the ghc api? Message-ID: Hi all, Is there a hoogle database for modules which come with GHC? - i.e. the modules on this page: http://downloads.haskell.org/~ghc/7.10.2/docs/html/libraries/ghc-7.10.2/index.html The text files would be preferable to a .hoo file, but I'll take either. Thanks! ER -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.raga at gmail.com Mon Oct 19 05:21:20 2015 From: alexey.raga at gmail.com (Alexey Raga) Date: Mon, 19 Oct 2015 05:21:20 +0000 Subject: [Haskell-cafe] Cross-compiling for arm? In-Reply-To: References: <5622557B.20007@ro-che.info> Message-ID: I was able to build a docker container for an ARM cross-compiler, if you find it helpful please have a look here: https://github.com/AlexeyRaga/ghc-docker-cross-arm Cheers On Mon, Oct 19, 2015 at 3:00 AM Mike Meyer wrote: > On Sat, Oct 17, 2015 at 9:04 AM Roman Cheplyaka wrote: > >> On 10/17/2015 03:29 PM, Mike Meyer wrote: >> > Thanks, the worked like a charm! Any chance this can be used for >> > cross-compiling from a Unix desktop to embedded arm? >> >> Not as easy as that. This solution relies on the fact that you can run >> i386 binaries on x86-64, which is obviously not true for arm. >> > > Yeah, I sort of expected that. But i'd be nice if it works. > > >> See https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling for >> how to build a cross-compiler. >> > > Doesn't work for me for building embedded code. The target arm-none-eabi > fails to configure because gcc doesn't work, because _exit doesn't exist. > Which is indeed the case. I don't see any way to turn that off. > > Is this not supported by ghc? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atze at uu.nl Mon Oct 19 07:52:30 2015 From: atze at uu.nl (Atze Dijkstra) Date: Mon, 19 Oct 2015 09:52:30 +0200 Subject: [Haskell-cafe] [NL-FP 2016] Announcement: Dutch Functional Programming Day 2016 Message-ID: [My apologies for multiple received copies of the same message] Dear all, The next Dutch Functional Programming day (NL-FP 2016) will be held on Friday, January 8, 2016 at the Utrecht University, The Netherlands. You are invited to participate and to give a presentation. At the end of the day we will have a joint dinner. On the web page http://foswiki.cs.uu.nl/foswiki/NlFpDay2016/WebHome for the day you?ll find preliminary information which will be further filled in due time. Registration is by letting me know via email (with a subject header that begins with [NL-FP 2016]) whether you want to (1) participate, (2) join dinner, (3) give a presentation (please include title + abstract), also see the webpage for additional details. If you intend to participate, please let me know as soon as possible because we like to know how many people we can expect. Hope to meet you all in Utrecht at the next FP Day! Best regards, - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 .... | Email: atze at uu.nl ............... / |___\ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Mon Oct 19 09:08:47 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 19 Oct 2015 10:08:47 +0100 Subject: [Haskell-cafe] hoogte db for the ghc api? In-Reply-To: References: Message-ID: You can add the +ghc flag in the hoogle search and it will search these modules as well. https://www.haskell.org/hoogle/?hoogle=mkFastString+%2Bghc Matt On Mon, Oct 19, 2015 at 5:50 AM, Erik Rantapaa wrote: > Hi all, > > Is there a hoogle database for modules which come with GHC? - i.e. the > modules on this page: > > http://downloads.haskell.org/~ghc/7.10.2/docs/html/libraries/ghc-7.10.2/index.html > > The text files would be preferable to a .hoo file, but I'll take either. > > Thanks! > ER > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From agocorona at gmail.com Mon Oct 19 10:31:58 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Mon, 19 Oct 2015 12:31:58 +0200 Subject: [Haskell-cafe] Future of FPComplete Haskell Center (IDE) In-Reply-To: References: Message-ID: Hi Thomas, I will collaborate on that since definitively a cloud development environment has not been appreciated as much as it deserve since all of us are accustomed to the desktop single user programming with "punctuated" collaboration. But I`m sure that the young developers will be more willing to develop collaboratively in a more fluent way with their tablets and maybe their phones using a web space. For context: https://www.reddit.com/r/haskell/comments/3oi3iw/cloud_development_enviroment/ 2015-10-16 20:58 GMT+02:00 Thomas Bereknyei : > FPComplete is deprecating Haskell Center and removing support for their > hosted IDE at the end of the year. I enjoy using the IDE in many situations > and would like to have a similar capability available to the community. I > know several people have expressed interest in helping maintain a version > that can go on. > > Michael Snoyman has stated that there are some issues with the existing > codebase and that there are many things that can/should be improved. There > are some limitations due to NDA, but I believe FPComplete would be willing > to hand over much of the codebase. > > I intend this thread to bring together those people interested in helping > with this effort in any way. Personally, I would be willing to provide > limited hosting and some development support. My goals would be to upgrade > support to 8.x GHC, latest Stackage - LTS and create a path for people to > self-host the IDE. > > -Tom Bereknyei > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kane at kane.cx Mon Oct 19 16:47:41 2015 From: kane at kane.cx (David Kraeutmann) Date: Mon, 19 Oct 2015 18:47:41 +0200 Subject: [Haskell-cafe] Displaying specializations in :info or separately? Message-ID: <56251EAD.4030101@kane.cx> Hi, I'm working on a GHC feature [1] that allows users to view specializations of functions like in (name subject to change) ---- > :binfo find find :: Foldable t => (a -> Bool) -> t a -> Maybe a Specialisations: t ~ [] => find :: (a -> Bool) -> [a] -> Maybe a > :binfo first first :: Arrow a => a b c -> a (b, d) (c, d) Specialisations: a ~ (->) => first :: (b -> c) -> (b, d) -> (c, d) ---- Now there are two things left to decide on: * What command should the specializations be visible under? We can either put it under :info or make a special command :sinfo or :binfo that displays only the expression's type and specialisations like in the example above? * What specializations do we want to display? goldfire suggested using the default list, which has the added benefit of being customizable by e.g. instructors, so adding a default Maybe (in conjunction with [2]) gives the desired behavior and not too many specializations. Thanks for your time! David ---- Links: [1] : https://ghc.haskell.org/trac/ghc/ticket/10972 [2] : https://ghc.haskell.org/trac/ghc/ticket/10971 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4291 bytes Desc: S/MIME Cryptographic Signature URL: From eir at cis.upenn.edu Mon Oct 19 19:10:39 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 19 Oct 2015 15:10:39 -0400 Subject: [Haskell-cafe] Displaying specializations in :info or separately? In-Reply-To: <56251EAD.4030101@kane.cx> References: <56251EAD.4030101@kane.cx> Message-ID: I would avoid the `(t ~ []) =>` prefix -- it might be confusing to the newcomers this feature is meant to serve. How about With t := []: find :: (a -> Bool) -> [a] -> Maybe a ? Richard On Oct 19, 2015, at 12:47 PM, David Kraeutmann wrote: > Hi, > > I'm working on a GHC feature [1] that allows users to view > specializations of functions like in (name subject to change) > > ---- >> :binfo find > find :: Foldable t => (a -> Bool) -> t a -> Maybe a > Specialisations: > t ~ [] => find :: (a -> Bool) -> [a] -> Maybe a > >> :binfo first > first :: Arrow a => a b c -> a (b, d) (c, d) > Specialisations: > a ~ (->) => first :: (b -> c) -> (b, d) -> (c, d) > ---- > > Now there are two things left to decide on: > * What command should the specializations be visible under? We can > either put it under :info or make a special command :sinfo or :binfo > that displays only the expression's type and specialisations like in the > example above? > > * What specializations do we want to display? goldfire suggested using > the default list, which has the added benefit of being customizable by > e.g. instructors, so adding a default Maybe (in conjunction with [2]) > gives the desired behavior and not too many specializations. > > > Thanks for your time! > David > > > ---- > Links: > [1] : https://ghc.haskell.org/trac/ghc/ticket/10972 > [2] : https://ghc.haskell.org/trac/ghc/ticket/10971 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From dburke.gw at gmail.com Mon Oct 19 19:32:31 2015 From: dburke.gw at gmail.com (Doug Burke) Date: Mon, 19 Oct 2015 19:32:31 +0000 Subject: [Haskell-cafe] Displaying specializations in :info or separately? In-Reply-To: References: <56251EAD.4030101@kane.cx> Message-ID: Or When t is []: find :: (a -> Bool) -> [a] -> Maybe a if this really is for the newcomer! Doug On Mon, Oct 19, 2015 at 3:11 PM Richard Eisenberg wrote: > I would avoid the `(t ~ []) =>` prefix -- it might be confusing to the > newcomers this feature is meant to serve. How about > > With t := []: find :: (a -> Bool) -> [a] -> Maybe a > > ? > > Richard > > On Oct 19, 2015, at 12:47 PM, David Kraeutmann wrote: > > > Hi, > > > > I'm working on a GHC feature [1] that allows users to view > > specializations of functions like in (name subject to change) > > > > ---- > >> :binfo find > > find :: Foldable t => (a -> Bool) -> t a -> Maybe a > > Specialisations: > > t ~ [] => find :: (a -> Bool) -> [a] -> Maybe a > > > >> :binfo first > > first :: Arrow a => a b c -> a (b, d) (c, d) > > Specialisations: > > a ~ (->) => first :: (b -> c) -> (b, d) -> (c, d) > > ---- > > > > Now there are two things left to decide on: > > * What command should the specializations be visible under? We can > > either put it under :info or make a special command :sinfo or :binfo > > that displays only the expression's type and specialisations like in the > > example above? > > > > * What specializations do we want to display? goldfire suggested using > > the default list, which has the added benefit of being customizable by > > e.g. instructors, so adding a default Maybe (in conjunction with [2]) > > gives the desired behavior and not too many specializations. > > > > > > Thanks for your time! > > David > > > > > > ---- > > Links: > > [1] : https://ghc.haskell.org/trac/ghc/ticket/10972 > > [2] : https://ghc.haskell.org/trac/ghc/ticket/10971 > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Mon Oct 19 19:39:04 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Mon, 19 Oct 2015 12:39:04 -0700 Subject: [Haskell-cafe] Global fixity (our status quo) vs. local fixity Message-ID: In Haskell, fixity is global. There are ten levels. You can't stick something between two levels, and you can't subvert the order of the levels. If you want something that binds before >>= but after the logical operators && and ||, you're out of luck -- unless you're willing to define synonyms for && and || that bind faster. (Tidal, a music DSL written in Haskell (it's on Hackage), exemplifies that problem with its |+| operator.) Conceptually, by contrast, fixity is local. The arithmetic operators (* + - / and **), for instance, have a certain fixity defined relative to each other, and that order does not, I believe, in the mind of most users extend beyond arithmetic. Does anybody else think it would be nice if a library's author had only to decide its operators' precedence relative to each other, and could let users decide for themselves how fast its operators should bind relative to operators from another library? -- Jeffrey Benjamin Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Mon Oct 19 19:50:46 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Mon, 19 Oct 2015 21:50:46 +0200 Subject: [Haskell-cafe] Global fixity (our status quo) vs. local fixity In-Reply-To: References: Message-ID: Indeed, this is fortunately not a new idea and there are already implementations! http://www.cse.chalmers.se/~nad/publications/danielsson-norell-mixfix.pdf Cheers, Adam On Mon, Oct 19, 2015 at 9:39 PM, Jeffrey Brown wrote: > In Haskell, fixity is global. There are ten levels. You can't stick > something between two levels, and you can't subvert the order of the > levels. If you want something that binds before >>= but after the logical > operators && and ||, you're out of luck -- unless you're willing to define > synonyms for && and || that bind faster. (Tidal, a music DSL written in > Haskell (it's on Hackage), exemplifies that problem with its |+| operator.) > > Conceptually, by contrast, fixity is local. The arithmetic operators (* + > - / and **), for instance, have a certain fixity defined relative to each > other, and that order does not, I believe, in the mind of most users extend > beyond arithmetic. > > Does anybody else think it would be nice if a library's author had only to > decide its operators' precedence relative to each other, and could let > users decide for themselves how fast its operators should bind relative to > operators from another library? > > -- > Jeffrey Benjamin Brown > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Mon Oct 19 19:55:07 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Mon, 19 Oct 2015 21:55:07 +0200 Subject: [Haskell-cafe] Displaying specializations in :info or separately? In-Reply-To: References: <56251EAD.4030101@kane.cx> Message-ID: Nice work David! I say put it under :info. This feature is very useful for beginners and we can't expect them to know about some other info command, what it does, and how it would help them. I too would probably not remember to use this if it's hidden somewhere else. Cheers, Adam On Mon, Oct 19, 2015 at 9:32 PM, Doug Burke wrote: > Or > > When t is []: find :: (a -> Bool) -> [a] -> Maybe a > > if this really is for the newcomer! > > Doug > > On Mon, Oct 19, 2015 at 3:11 PM Richard Eisenberg > wrote: > >> I would avoid the `(t ~ []) =>` prefix -- it might be confusing to the >> newcomers this feature is meant to serve. How about >> >> With t := []: find :: (a -> Bool) -> [a] -> Maybe a >> >> ? >> >> Richard >> >> On Oct 19, 2015, at 12:47 PM, David Kraeutmann wrote: >> >> > Hi, >> > >> > I'm working on a GHC feature [1] that allows users to view >> > specializations of functions like in (name subject to change) >> > >> > ---- >> >> :binfo find >> > find :: Foldable t => (a -> Bool) -> t a -> Maybe a >> > Specialisations: >> > t ~ [] => find :: (a -> Bool) -> [a] -> Maybe a >> > >> >> :binfo first >> > first :: Arrow a => a b c -> a (b, d) (c, d) >> > Specialisations: >> > a ~ (->) => first :: (b -> c) -> (b, d) -> (c, d) >> > ---- >> > >> > Now there are two things left to decide on: >> > * What command should the specializations be visible under? We can >> > either put it under :info or make a special command :sinfo or :binfo >> > that displays only the expression's type and specialisations like in the >> > example above? >> > >> > * What specializations do we want to display? goldfire suggested using >> > the default list, which has the added benefit of being customizable by >> > e.g. instructors, so adding a default Maybe (in conjunction with [2]) >> > gives the desired behavior and not too many specializations. >> > >> > >> > Thanks for your time! >> > David >> > >> > >> > ---- >> > Links: >> > [1] : https://ghc.haskell.org/trac/ghc/ticket/10972 >> > [2] : https://ghc.haskell.org/trac/ghc/ticket/10971 >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Mon Oct 19 20:01:16 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Mon, 19 Oct 2015 22:01:16 +0200 Subject: [Haskell-cafe] Global fixity (our status quo) vs. local fixity In-Reply-To: References: Message-ID: <20151019200116.GB11479@casa.casa> On Mon, Oct 19, 2015 at 12:39:04PM -0700, Jeffrey Brown wrote: > Does anybody else think it would be nice if a library's author had only to > decide its operators' precedence relative to each other, and could let > users decide for themselves how fast its operators should bind relative to > operators from another library? It is true that fixity is ordinal, not cardinal, but I guess letting the user decide for themselves how to blend operators from different libraries could lead to a fragmentation where I will find difficult to read/interpret your code and viceversa. Can you make an example where the 10 levels of precedence (plus function application) wasn't enough for you/other devs? From ndmitchell at gmail.com Mon Oct 19 20:42:04 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon, 19 Oct 2015 21:42:04 +0100 Subject: [Haskell-cafe] hoogte db for the ghc api? In-Reply-To: References: Message-ID: You can find the .txt file at http://downloads.haskell.org/~ghc/7.10.2/docs/html/libraries/ghc-7.10.2/ghc.txt. It used to be available only on Hoogle 4, as Matt indicates, but I've just made it so it works with Hoogle 5 too (better text search, more regularly updated, no meaningful type search yet, not on Hackage). You can try at: http://hoogle.haskell.org/?hoogle=mkFastString&scope=package%3Aghc Thanks, Neil On Mon, Oct 19, 2015 at 10:08 AM, Matthew Pickering wrote: > You can add the +ghc flag in the hoogle search and it will search > these modules as well. > > https://www.haskell.org/hoogle/?hoogle=mkFastString+%2Bghc > > Matt > > On Mon, Oct 19, 2015 at 5:50 AM, Erik Rantapaa wrote: >> Hi all, >> >> Is there a hoogle database for modules which come with GHC? - i.e. the >> modules on this page: >> >> http://downloads.haskell.org/~ghc/7.10.2/docs/html/libraries/ghc-7.10.2/index.html >> >> The text files would be preferable to a .hoo file, but I'll take either. >> >> Thanks! >> ER >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From jeffbrown.the at gmail.com Mon Oct 19 20:49:31 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Mon, 19 Oct 2015 13:49:31 -0700 Subject: [Haskell-cafe] Global fixity (our status quo) vs. local fixity In-Reply-To: <20151019200116.GB11479@casa.casa> References: <20151019200116.GB11479@casa.casa> Message-ID: Adam: Sweet! Are there implementations in Haskell? Francesco: here is the problem that spurred me to write this email: Tidal uses a |+| operator to conjoin what it calls OscPatterns. For instance, you can write: d1 $ sound "bd sn" |+| speed "3" |+| pan "1" to tell the sampler named d1, "play the bd (bass drum) sample at phase 0 and the sn (snare drum) sample at pahse 1/2. Speed both up by a factor of 3, and pan both to the right speaker". (Phase takes values in the interval [0,1); upon reaching 1, a new cycle begins at 0.) Tidal offers functions for changing patterns. For instance, to slow down by a factor of 2 the frequency at which samples are triggered (that's how often a sample is played, not its playback speed), you can write this: d1 $ (slow 2 $ sound "bd sn") |+| speed "3" |+| pan "1" Every instruction issued to d1 is a chain of |+|-separated OscPatterns. I often want to thread OscPatterns through functions before conjoining them. I therefore would like to be able to explain to Tidal that in whatever it finds to the right of a statement beginning with "d1 $", it should bind |+| after $. Then I would not need so many parentheses. On Mon, Oct 19, 2015 at 1:01 PM, Francesco Ariis wrote: > On Mon, Oct 19, 2015 at 12:39:04PM -0700, Jeffrey Brown wrote: > > Does anybody else think it would be nice if a library's author had only > to > > decide its operators' precedence relative to each other, and could let > > users decide for themselves how fast its operators should bind relative > to > > operators from another library? > > It is true that fixity is ordinal, not cardinal, but I guess letting the > user decide for themselves how to blend operators from different libraries > could lead to a fragmentation where I will find difficult to > read/interpret your code and viceversa. > > Can you make an example where the 10 levels of precedence (plus function > application) wasn't enough for you/other devs? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Jeffrey Benjamin Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Tue Oct 20 00:03:15 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 20 Oct 2015 02:03:15 +0200 Subject: [Haskell-cafe] Global fixity (our status quo) vs. local fixity In-Reply-To: References: <20151019200116.GB11479@casa.casa> Message-ID: On Mon, Oct 19, 2015 at 10:49 PM, Jeffrey Brown wrote: > Adam: Sweet! Are there implementations in Haskell? > > I don't know. A colleague implemented it in purescript (I believe) for a toy language of his. > Francesco: here is the problem that spurred me to write this email: > > Tidal uses a |+| operator to conjoin what it calls OscPatterns. For > instance, you can write: > > d1 $ sound "bd sn" |+| speed "3" |+| pan "1" > > to tell the sampler named d1, "play the bd (bass drum) sample at phase 0 > and the sn (snare drum) sample at pahse 1/2. Speed both up by a factor of > 3, and pan both to the right speaker". (Phase takes values in the interval > [0,1); upon reaching 1, a new cycle begins at 0.) > > Tidal offers functions for changing patterns. For instance, to slow down > by a factor of 2 the frequency at which samples are triggered (that's how > often a sample is played, not its playback speed), you can write this: > > d1 $ (slow 2 $ sound "bd sn") |+| speed "3" |+| pan "1" > > Every instruction issued to d1 is a chain of |+|-separated OscPatterns. I > often want to thread OscPatterns through functions before conjoining them. > I therefore would like to be able to explain to Tidal that in whatever it > finds to the right of a statement beginning with "d1 $", it should bind |+| > after $. Then I would not need so many parentheses. > > On Mon, Oct 19, 2015 at 1:01 PM, Francesco Ariis wrote: > >> On Mon, Oct 19, 2015 at 12:39:04PM -0700, Jeffrey Brown wrote: >> > Does anybody else think it would be nice if a library's author had only >> to >> > decide its operators' precedence relative to each other, and could let >> > users decide for themselves how fast its operators should bind relative >> to >> > operators from another library? >> >> It is true that fixity is ordinal, not cardinal, but I guess letting the >> user decide for themselves how to blend operators from different libraries >> could lead to a fragmentation where I will find difficult to >> read/interpret your code and viceversa. >> >> Can you make an example where the 10 levels of precedence (plus function >> application) wasn't enough for you/other devs? >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > -- > Jeffrey Benjamin Brown > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkoster at gmail.com Tue Oct 20 00:41:19 2015 From: tkoster at gmail.com (Thomas Koster) Date: Tue, 20 Oct 2015 11:41:19 +1100 Subject: [Haskell-cafe] A GC'd heap using weak pointers In-Reply-To: References: Message-ID: On 6 October 2015 at 21:25, Thomas Koster wrote: > I am implementing a simple, interpreted language that needs a garbage- > collected heap for storage. Like most discussions on memory management, > I use the term "heap" by analogy - the actual data structure is not > necessarily a true heap. > > My Heap type is basically a map of "addresses" (Int) to values. Values > may themselves contain addresses, perhaps recursively to each other > (like letrec). The extra field in Heap stores the next unused address, > used to allocate fresh slots, as you can see in "heapAlloc". > >> type Address = Int >> data Value = ...things with Addresses... >> data Heap = Heap !Address (Map Address Value) >> >> heapAlloc :: Heap -> (Address, Heap) >> heapAlloc (Heap nextFreeAddr binds) = >> (nextFreeAddr, Heap (succ nextFreeAddr) binds) > > There is also a stack of roots and an expression under evaluation. > >> type Stack = [...things with Addresses...] >> data Expr = ...things with Addresses... > > The function I need to write is: > >> heapGC :: [Address] -> Heap -> Heap >> heapGC roots heap = ...collect unreachable values from heap... > > Rather than re-invent this particularly complex wheel, I am wondering > if I could use GHC weak pointers and have the GHC runtime collect values > in my heap for me. Something like this: > >> type Address = Int >> data Reference = Reference Address >> data Value = ...things with References... >> data Heap = Heap !Address (Map Address (Weak Value)) >> >> heapAlloc :: Heap -> (Reference, Heap) >> heapAlloc (Heap nextFreeAddr binds) = >> (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds) >> >> heapStore :: Reference -> Value -> Heap -> IO Heap >> heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do >> weakVal <- mkWeak ref val Nothing >> return $ Heap nextFreeAddr (Map.insert addr weakVal binds) > > Note the new type, Reference. This replaces Address everywhere except > in the heap's internal structure, which continues to use Address. > Reference values are opaque, unique and obtained from the heap using > heapAlloc. > > The idea is that only two things should cause Values to stay alive: > 1. reachable holders of Reference (by GHC's definition of "reachable"), > 2. ordinary Haskell closures arising from stepping the interpreter. > "Being in the Heap" should not be enough to keep a Value alive. Then, > my heapGC function should only have to prune dead addresses from the > map. For those who were following this, the technique described above (using System.Mem.Weak to emulate a Heap) does appear to work correctly. You do have to periodically prune the dead pointers from it, of course. However, after a brainwave while in the shower, I realized I could remove the Heap emulation from my interpreter completely and use the Haskell heap directly with IORefs. What used to be "Address" in the old graph is now "IORef Value". Where let/letrec expressions in my interpreted language previously stored fresh closures in the emulated "Heap", they now create fresh closures using "newIORef", and substitute an "IORef Value" for the free variable just bound. It's always nice when you can solve a problem by deleting code! -- Thomas Koster From nicola.gigante at gmail.com Tue Oct 20 10:19:17 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Tue, 20 Oct 2015 12:19:17 +0200 Subject: [Haskell-cafe] Problems with Stack on Gentoo Linux Message-ID: Hi all I?m sorry if this is not the right list to ask, I was unsure. I?m having problems compiling a project with stack on a Gentoo machine. I only have shell access to the machine, so I don?t have too much info about it, but the admin assured me that everything is up to date. I?ve upgraded to the latest stack, but the problem was also present with 0.1.4. While doing stack build on my project with resolver lts 3.10 I get the following strange error: ---------------------------------------------------------------------------------------------- -- While building package transformers-base-0.4.4 using: /home/gigabytes/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/ build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/gigabytes/gigabytes.it/.stack-work/logs/transformers-base-0.4.4.log Configuring transformers-base-0.4.4... Building transformers-base-0.4.4... Preprocessing library transformers-base-0.4.4... [1 of 1] Compiling Control.Monad.Base ( src/Control/Monad/Base.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Control/Monad/Base.o ) src/Control/Monad/Base.hs:22:1: Warning: The import of `Data.Monoid' is redundant except perhaps to import instances from `Data.Monoid' To import instances alone, use: import Data.Monoid() src/Control/Monad/Base.hs:24:1: Warning: The import of `Control.Applicative' is redundant except perhaps to import instances from `Control.Applicative' To import instances alone, use: import Control.Applicative() .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/src/Control/Monad/Base.dump-hi: commitBuffer: invalid argument (invalid character) ---------------------------------------------------------------------------------------------- Note that the warnings are not stopping the compile process themselves, but they somehow trigger the last error which kills the compiler. Stack is using the system-installed GHC here, which is version 7.10.2 (of course, otherwise stack wouldn?t have selected it). Maybe the system-wide compiler wasn?t installed properly (I doubt it, since the admin told me he uses a Gentoo package manager which is written in haskell and everything works well). So I?ve tried installing a stack-local GHC version, but I get a sanity check error: ---------------------------------------------------------------------------------------------- The GHC located at /home/gigabytes/.stack/programs/x86_64-linux/ghc-7.10.2/bin/ghc failed to compile a sanity check. Please see: https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upgrade.md for more information. Exception was: Running /home/gigabytes/.stack/programs/x86_64-linux/ghc-7.10.2/bin/ghc /tmp/stack-sanity-check22752/Main.hs -no-user-package-db exited with ExitFailure 1 [1 of 1] Compiling Main ( /tmp/stack-sanity-check22752/Main.hs, /tmp/stack-sanity-check22752/Main.o ) Linking /tmp/stack-sanity-check22752/Main ... /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/stack-sanity-check22752/Main.o: relocation R_X86_64_32S against `stg_bh_upd_frame_info' can not be used when making a shared object; recompile with -fPIC /tmp/stack-sanity-check22752/Main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status ---------------------------------------------------------------------------------------------- So to recap: - The system-wide ghc crashes compiling transformers-base-0.4.4 - The stack-local ghc does not pass a sanity check On an OS X machine, the project compiles and work very well with the same stack and ghc versions and the same LTS, so I suppose this has to do with Gentoo. Any ideas? Thank you, Nicola From michael at snoyman.com Tue Oct 20 10:30:05 2015 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 20 Oct 2015 13:30:05 +0300 Subject: [Haskell-cafe] Problems with Stack on Gentoo Linux In-Reply-To: References: Message-ID: Please see this issue on the Stack issue tracker: https://github.com/commercialhaskell/stack/issues/793 The summary is: * `export LANG=en_US.UTF-8` or equivalent * The next GHC release is already patched so that this won't be necessary On Tue, Oct 20, 2015 at 1:19 PM, Nicola Gigante wrote: > Hi all > > I?m sorry if this is not the right list to ask, I was unsure. > > I?m having problems compiling a project with stack on a Gentoo machine. > I only have shell access to the machine, so I don?t have too much info > about it, > but the admin assured me that everything is up to date. > > I?ve upgraded to the latest stack, but the problem was also present with > 0.1.4. > While doing stack build on my project with resolver lts 3.10 I get the > following > strange error: > > > ---------------------------------------------------------------------------------------------- > -- While building package transformers-base-0.4.4 using: > > /home/gigabytes/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 > --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/ build > --ghc-options " -ddump-hi -ddump-to-file" > Process exited with code: ExitFailure 1 > Logs have been written to: /home/gigabytes/ > gigabytes.it/.stack-work/logs/transformers-base-0.4.4.log > > Configuring transformers-base-0.4.4... > Building transformers-base-0.4.4... > Preprocessing library transformers-base-0.4.4... > [1 of 1] Compiling Control.Monad.Base ( src/Control/Monad/Base.hs, > .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Control/Monad/Base.o ) > > src/Control/Monad/Base.hs:22:1: Warning: > The import of `Data.Monoid' is redundant > except perhaps to import instances from `Data.Monoid' > To import instances alone, use: import Data.Monoid() > > src/Control/Monad/Base.hs:24:1: Warning: > The import of `Control.Applicative' is redundant > except perhaps to import instances from `Control.Applicative' > To import instances alone, use: import Control.Applicative() > > .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/src/Control/Monad/Base.dump-hi: > commitBuffer: invalid argument (invalid character) > > ---------------------------------------------------------------------------------------------- > > > Note that the warnings are not stopping the compile process themselves, > but they somehow trigger the last error which kills the compiler. > > Stack is using the system-installed GHC here, which is version 7.10.2 (of > course, otherwise stack wouldn?t have selected it). > Maybe the system-wide compiler wasn?t installed properly (I doubt it, > since the admin told me > he uses a Gentoo package manager which is written in haskell and > everything works well). > So I?ve tried installing a stack-local GHC version, but I get a sanity > check error: > > > ---------------------------------------------------------------------------------------------- > The GHC located at > /home/gigabytes/.stack/programs/x86_64-linux/ghc-7.10.2/bin/ghc failed to > compile a sanity check. Please see: > > > https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upgrade.md > > for more information. Exception was: > Running /home/gigabytes/.stack/programs/x86_64-linux/ghc-7.10.2/bin/ghc > /tmp/stack-sanity-check22752/Main.hs -no-user-package-db exited with > ExitFailure 1 > [1 of 1] Compiling Main ( > /tmp/stack-sanity-check22752/Main.hs, /tmp/stack-sanity-check22752/Main.o ) > Linking /tmp/stack-sanity-check22752/Main ... > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: > /tmp/stack-sanity-check22752/Main.o: relocation R_X86_64_32S against > `stg_bh_upd_frame_info' can not be used when making a shared object; > recompile with -fPIC > /tmp/stack-sanity-check22752/Main.o: error adding symbols: Bad value > collect2: error: ld returned 1 exit status > > ---------------------------------------------------------------------------------------------- > > > So to recap: > - The system-wide ghc crashes compiling transformers-base-0.4.4 > - The stack-local ghc does not pass a sanity check > > > On an OS X machine, the project compiles and work very well with the same > stack and ghc versions and the same LTS, so I suppose this has to do with > Gentoo. > > Any ideas? > > Thank you, > Nicola > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Tue Oct 20 12:55:23 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Tue, 20 Oct 2015 08:55:23 -0400 Subject: [Haskell-cafe] Problems with Stack on Gentoo Linux In-Reply-To: References: Message-ID: <562639BB.2000600@orlitzky.com> On 10/20/2015 06:30 AM, Michael Snoyman wrote: > Please see this issue on the Stack issue tracker: > > https://github.com/commercialhaskell/stack/issues/793 > > The summary is: > > * `export LANG=en_US.UTF-8` or equivalent > * The next GHC release is already patched so that this won't be necessary > The LANG variable is set by your locale choice on Gentoo. If the admin is willing to mess with it, # eselect locale list should output something like, Available targets for the LANG variable: [1] C [2] en_US [3] en_US.iso88591 [4] en_US.utf8 * [5] POSIX [ ] (free form) and then # eselect locale set 4 Setting LANG to en_US.utf8 ... Run ". /etc/profile" to update the variable in your shell. will set it globally. From rendel at informatik.uni-tuebingen.de Tue Oct 20 13:21:24 2015 From: rendel at informatik.uni-tuebingen.de (Tillmann Rendel) Date: Tue, 20 Oct 2015 15:21:24 +0200 Subject: [Haskell-cafe] Displaying specializations in :info or separately? In-Reply-To: <56251EAD.4030101@kane.cx> References: <56251EAD.4030101@kane.cx> Message-ID: <56263FD4.5000502@informatik.uni-tuebingen.de> Hi, David Kraeutmann wrote: > I'm working on a GHC feature [1] that allows users to view > specializations of functions like in (name subject to change) > > ---- >> :binfo find > find :: Foldable t => (a -> Bool) -> t a -> Maybe a > Specialisations: > t ~ [] => find :: (a -> Bool) -> [a] -> Maybe a > >> :binfo first > first :: Arrow a => a b c -> a (b, d) (c, d) > Specialisations: > a ~ (->) => first :: (b -> c) -> (b, d) -> (c, d) > ---- Looks very helpful. Three ideas: (1) I think this would be easier to read if the specialized type signature would come first. Maybe like this: find :: Foldable t => (a -> Bool) -> t a -> Maybe a Specializations: find :: (a -> Bool) -> [a] -> Maybe a -- if f ~ [] find :: (a -> Bool) -> Either b a -> Maybe a -- if f ~ Either b (2) Can this be made to work for expressions, too? $ :type-so-that-i-get-it find even find even :: (Foldable t, Integral a) => t a -> Maybe a Specializations: find even :: [Integer] -> Maybe Integer -- if t ~ [], a ~ Integer (3) Could the specializations also be shown in haddock documentation? Tillmann From nicola.gigante at gmail.com Tue Oct 20 14:34:57 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Tue, 20 Oct 2015 16:34:57 +0200 Subject: [Haskell-cafe] Problems with Stack on Gentoo Linux In-Reply-To: References: Message-ID: <2CD65A1C-BA3F-463B-A85E-C38BC1DDC690@gmail.com> > Il giorno 20 ott 2015, alle ore 12:30, Michael Snoyman ha scritto: > > Please see this issue on the Stack issue tracker: > > https://github.com/commercialhaskell/stack/issues/793 > > The summary is: > > * `export LANG=en_US.UTF-8` or equivalent > * The next GHC release is already patched so that this won't be necessary Thank you all, you saved my day! Greetings, Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.kulagin at gmail.com Tue Oct 20 14:48:53 2015 From: dmitry.kulagin at gmail.com (Dmitry Kulagin) Date: Tue, 20 Oct 2015 17:48:53 +0300 Subject: [Haskell-cafe] Job opportunities at Kaspersky Lab (Moscow) Message-ID: Here at Kaspersky Lab, we are developing a secure platform&framework. We have two job opportunities right now. Both opportunities assume good command of Haskell, since we use Haskell extensively. These are full time positions, available at our Moscow (Russia) office. If you are interested, please apply on the corporate site or send your CV to me directly at dmitry.kulagin at kaspersky.com Descriptions: Software Engineer: Responsibilities: * Development of core of the security system * Tools development (such as compilers/DSL) Skills/experience: * Strong experience developing with Haskell * C/C++ development experience * Good knowledge of basic algorithms and data structures * Compilers/DSLs development experience (desirable) * System programming experience (desirable) * Understanding of OS internals (desirable) * Experience in development of embedded and/or real-time applications (desirable) URL: * http://www.kaspersky.ru/job?vac=283264 Researcher (formal methods/computer security): Responsibilities: * Development of approaches to express and verify security and safety properties of systems Skills/experience: * Masters degree in CS or equivalent. PhD in CS (or related field) is desirable * Strong interest in computer security * Experience in formal verification * Good writing and presentation skills * Haskell programming experience is highly desirable * C-programming experience (desirable) * Prolog programming experience (desirable) URL: * http://www.kaspersky.ru/job?vac=283263 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Tue Oct 20 15:11:30 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 20 Oct 2015 11:11:30 -0400 Subject: [Haskell-cafe] Displaying specializations in :info or separately? In-Reply-To: <56263FD4.5000502@informatik.uni-tuebingen.de> References: <56251EAD.4030101@kane.cx> <56263FD4.5000502@informatik.uni-tuebingen.de> Message-ID: <23A50BBB-FBE5-407A-89D6-1F6D8846AC0A@cis.upenn.edu> On Oct 20, 2015, at 9:21 AM, Tillmann Rendel wrote: > Looks very helpful. Three ideas: > > > (1) I think this would be easier to read if the specialized type signature would come first. Maybe like this: > > find :: Foldable t => (a -> Bool) -> t a -> Maybe a > > Specializations: > > find :: (a -> Bool) -> [a] -> Maybe a -- if f ~ [] > find :: (a -> Bool) -> Either b a -> Maybe a -- if f ~ Either b Yes -- I like this more, too. > > > (2) Can this be made to work for expressions, too? > > $ :type-so-that-i-get-it find even > find even :: (Foldable t, Integral a) => t a -> Maybe a > > Specializations: > > find even :: [Integer] -> Maybe Integer -- if t ~ [], a ~ Integer I like this, too. And this example also brings up the possibility of a combinatorial number of specializations that could be printed. We'd want to limit it, I think. > > > (3) Could the specializations also be shown in haddock documentation? Yes yes yes please please please. Richard > > Tillmann > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From shumovichy at gmail.com Tue Oct 20 15:16:30 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Tue, 20 Oct 2015 18:16:30 +0300 Subject: [Haskell-cafe] Job opportunities at Kaspersky Lab (Moscow) In-Reply-To: References: Message-ID: <1445354190.10322.6.camel@gmail.com> On Tue, 2015-10-20 at 17:48 +0300, Dmitry Kulagin wrote: > URL: > ????* http://www.kaspersky.ru/job?vac=283264 > Bug report: it is redirecting me to?http://www.kaspersky.by/job?vac=283 264?where I get: > ?????? 404: ???????? ?? ??????? The option to view Russian version of the site doesn't work, it is still redirecting me to the local one. Thanks, Yuras. From aditya.siram at gmail.com Tue Oct 20 17:29:11 2015 From: aditya.siram at gmail.com (aditya siram) Date: Tue, 20 Oct 2015 12:29:11 -0500 Subject: [Haskell-cafe] Callstack Implicit Param for Unsafe Prelude Functions Message-ID: Since the latest base now has a way of getting generating stack traces via the `CallStack` implicit param, is there any reason not to add that param to the error messages of unsafe functions in the Prelude ( and even commonly used modules like Data.Maybe/Data.List)? The type signature will change but for most users it should be a drop-in replacement and a great aid to debugging. Thanks! -deech -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Tue Oct 20 17:52:41 2015 From: eric at seidel.io (Eric Seidel) Date: Tue, 20 Oct 2015 10:52:41 -0700 Subject: [Haskell-cafe] Callstack Implicit Param for Unsafe Prelude Functions In-Reply-To: References: Message-ID: <1445363561.1898977.415506433.18A6A692@webmail.messagingengine.com> We discussed this back when I implemented the implicit call-stacks, and decided to be conservative in their use in `base`. There are two reasons behind the decision: 1. There's a runtime cost to using implicit call-stacks, namely an extra parameter to each function that uses them (just like regular implicit parameters). 2. They can clutter otherwise simple type signatures. Compare, e.g., head :: [a] -> a vs head :: (?callStack :: CallStack) => [a] -> a Adding the implicit call-stack more than doubles the length of the type signature! This might seem like a silly complaint, but I think there's a real cognitive overhead there, especially when you consider that Prelude will be one of the first modules that novices might read the haddocks for. GHC HEAD now uses implicit call-stacks for functions that always diverge (ie error and undefined), but we decided to draw the line there. Of course, there are plenty of other functions where a call-stack would make sense, especially partial functions. So I've collected some of the more common ones in a supplementary package: https://hackage.haskell.org/package/located-base I envision this as a package that you pull in for development, but perhaps leave out of "production" builds, using some CPP magic. And I'll happily accept PRs for other functions! Eric On Tue, Oct 20, 2015, at 10:29, aditya siram wrote: > Since the latest base now has a way of getting generating stack traces > via > the `CallStack` implicit param, is there any reason not to add that param > to the error messages of unsafe functions in the Prelude ( and even > commonly used modules like Data.Maybe/Data.List)? > > The type signature will change but for most users it should be a drop-in > replacement and a great aid to debugging. > > Thanks! > -deech > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From marcin.jan.mrotek at gmail.com Tue Oct 20 19:23:55 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Tue, 20 Oct 2015 21:23:55 +0200 Subject: [Haskell-cafe] Callstack Implicit Param for Unsafe Prelude Functions In-Reply-To: <1445363561.1898977.415506433.18A6A692@webmail.messagingengine.com> References: <1445363561.1898977.415506433.18A6A692@webmail.messagingengine.com> Message-ID: > > Adding the implicit call-stack more than doubles the length of the type > signature! This might seem like a silly complaint, but I think there's a > real cognitive overhead there, especially when you consider that Prelude > will be one of the first modules that novices might read the haddocks > for. Well, scaring beginners away from partial functions may be not that bad of an idea ;) Best regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Wed Oct 21 00:39:57 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Tue, 20 Oct 2015 20:39:57 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <5626DEDD.8040202@apeiron.net> I am also a -1, and I share Bryan's concerns. What worries me most is that we have started to see very valuable members of our community publicly state that they are reducing their community involvement. While technical disagreement has something to do with their decisions, I suspect that it is the /process/ by which these decisions have been made that is pushing them away. Whatever our individual stances on AMP/FTP/MRP, I hope we can all agree that any process that has this effect needs a hard look. I consider myself a member of the Haskell community, but like Henrik and Graham, I have not actively followed the libraries list. I was take by surprise by AMP. When FTP appeared, I didn't speak up because I felt the outcome was inevitable. I should have spoken up nonetheless; I am speaking up now. In effect, only those who actively follow the libraries list have had a voice in these decisions. Maybe that is what the community wants. I hope not. How then can people like me (and Henrik and Graham) have a say without committing to actively following the libraries list? We have a method to solve this: elected representatives. Right now the Core Libraries Committee elects its own members; perhaps it is time for that to change. Let me throw out a few straw man proposals. Proposal 1: Move to community election of the members of the Core Libraries Committee. Yes, I know this would have its own issues. Proposal 2: After a suitable period of discussion on the libraries list, the Core Libraries Committee will summarize the arguments for and against a proposal and post it, along with a (justified) preliminary decision, to a low-traffic, announce-only email list. After another suitable period of discussion, they will issue a final decision. What is a suitable period of time? Perhaps that depends on the properties of the proposal, such as whether it breaks backwards compatibility. Proposal 3: A decision regarding any proposal that significantly affects backwards compatibility is within the purview of the Haskell Prime Committee, not the Core Libraries Committee. Now I am not saying I feel strongly that all (or any) of these proposals should be enacted (in fleshed out form), but I do think they are all worth discussing. Cheers, Geoff On 10/05/2015 10:59 AM, Bryan O'Sullivan wrote: > I would like to suggest that the bar for breaking all existing libraries, books, papers, and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge. > > This proposal falls far short of both bars, to the extent that I am astonished and disappointed it is being seriously discussed ? and to general approval, no less ? on a date other than April 1. Surely some design flaws have consequences so small that they are not worth fixing. > > I'll survive if it goes through, obviously, but it will commit me to a bunch of pointless make-work and compatibility ifdefs. I've previously expressed my sense that cross-version compatibility is a big tax on library maintainers. This proposal does not give me confidence that this cost is being taken seriously. > > Thanks, > Bryan. > >> On Oct 5, 2015, at 7:32 AM, Gershom B wrote: >> >>> On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote: >>> Hello all. I write this to be a little provocative, but ? >>> >>> It?s really interesting to have this discussion, which pulls in all sorts of well-made >>> points about orthogonality, teaching, the evolution of the language and so on, but it >>> simply goes to show that the process of evolving Haskell is profoundly broken. >>> >>> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes >>> that would have a profound impact on systems that are commercially and potentially safety >>> critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility >>> of the Haskell community to its users and, indirectly, to its future. >> Hi Simon. I do in fact think this is provocative :-P >> >> I want to object here to your characterization of what has been going on as ?simply throwing in changes?. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period. >> >> I also want to object to the idea that these changes would have ?a profound impact on systems?. As it stands, and I think this is an important criteria in any change, when ?phase 2? goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior. >> >> Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind? >> >> ?Gershom >> >> P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns. From Henrik.Nilsson at nottingham.ac.uk Wed Oct 21 08:24:34 2015 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Wed, 21 Oct 2015 09:24:34 +0100 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5626DEDD.8040202@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> Message-ID: <56274BC2.20507@nottingham.ac.uk> Hi all, Geoffrey Mainland wrote; > What worries me most is that we have started to see very valuable > members of our community publicly state that they are reducing their > community involvement. That worries me too. A lot. To quote myself from an earlier e-mail in this thread: > Therefore, please let us defer further discussion and > ultimate decision on MRP to the resurrected > HaskellPrime committee, which is where it properly > belongs. Otherwise, the Haskell community itself might > be one of the things that MRP breaks. Geoffrey further wrote: > Proposal 3: A decision regarding any proposal that significantly > affects backwards compatibility is within the purview of the Haskell > Prime Committee, not the Core Libraries Committee. I thus definitely support this, at least for anything related to the libraries covered by the Haskell report. Indeed, I strongly suspect that many people who did not actively follow the libraries discussions did so because they simply did not think that changes to the central libraries as defined in the Haskell report, at least not breaking changes, were in the remit of the libraries committee, and were happy to leave discussions on any other libraries to the users of those libraries. And as a consequence they were taken by surprise by AMP etc. So before breaking anything more, that being code, research papers, books, what people have learned, or even the community itself, it is time to very carefully think about what the appropriate processes should be for going forward. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From Lennart.Augustsson at sc.com Wed Oct 21 08:28:11 2015 From: Lennart.Augustsson at sc.com (Augustsson, Lennart) Date: Wed, 21 Oct 2015 08:28:11 +0000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <56274BC2.20507@nottingham.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> Message-ID: <22B950C955F8AB4196E72698FBD00002D02A2259@UKWPISXMB01B.zone1.scb.net> I'd say, of course, libraries covered by the Haskell report are not in the remit of the libraries committee. -----Original Message----- From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Henrik Nilsson Sent: 21 October 2015 09:25 To: Geoffrey Mainland; Bryan O'Sullivan; Gershom B Cc: Henrik.Nilsson at nottingham.ac.uk; haskell-prime at haskell.org List; Graham Hutton; Haskell Libraries; haskell cafe Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` Hi all, Geoffrey Mainland wrote; > What worries me most is that we have started to see very valuable > members of our community publicly state that they are reducing their > community involvement. That worries me too. A lot. To quote myself from an earlier e-mail in this thread: > Therefore, please let us defer further discussion and > ultimate decision on MRP to the resurrected > HaskellPrime committee, which is where it properly > belongs. Otherwise, the Haskell community itself might > be one of the things that MRP breaks. Geoffrey further wrote: > Proposal 3: A decision regarding any proposal that significantly > affects backwards compatibility is within the purview of the Haskell > Prime Committee, not the Core Libraries Committee. I thus definitely support this, at least for anything related to the libraries covered by the Haskell report. Indeed, I strongly suspect that many people who did not actively follow the libraries discussions did so because they simply did not think that changes to the central libraries as defined in the Haskell report, at least not breaking changes, were in the remit of the libraries committee, and were happy to leave discussions on any other libraries to the users of those libraries. And as a consequence they were taken by surprise by AMP etc. So before breaking anything more, that being code, research papers, books, what people have learned, or even the community itself, it is time to very carefully think about what the appropriate processes should be for going forward. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same. Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products. From hvriedel at gmail.com Wed Oct 21 11:55:32 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 21 Oct 2015 13:55:32 +0200 Subject: [Haskell-cafe] Committee M.O. Change Proposals (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <5626DEDD.8040202@apeiron.net> (Geoffrey Mainland's message of "Tue, 20 Oct 2015 20:39:57 -0400") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> Message-ID: <87pp088mh7.fsf_-_@gmail.com> Hello, On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: [...] > In effect, only those who actively follow the libraries list have had a > voice in these decisions. Maybe that is what the community wants. I hope > not. How then can people like me (and Henrik and Graham) have a say > without committing to actively following the libraries list? > > We have a method to solve this: elected representatives. Right now the > Core Libraries Committee elects its own members; perhaps it is time for > that to change. [...] > Proposal 1: Move to community election of the members of the Core > Libraries Committee. Yes, I know this would have its own issues. How exactly do public elections of representatives address the problem that some people feel left out? Have you considered nominating yourself or somebody else you have confidence in for the core libraries committee? You'd still have to find somebody to represent your interests, regardless of whether the committee is self-elected or direct-elected. Here's some food for thought regarding language design by voting or its indirect form via a directly elected language committee: Back in February there was a large-scale survey which resulted (see [2] for more details) in a rather unequivocal 4:1 majority *for* going through with the otherwise controversial FTP implementation. If the community elections would result in a similar spirit, you'd could easily end up with a similarly 4:1 pro-change biased committee. Would you consider that a well balanced committee formation? > Proposal 2: After a suitable period of discussion on the libraries list, > the Core Libraries Committee will summarize the arguments for and > against a proposal and post it, along with a (justified) preliminary > decision, to a low-traffic, announce-only email list. After another > suitable period of discussion, they will issue a final decision. What is > a suitable period of time? Perhaps that depends on the properties of the > proposal, such as whether it breaks backwards compatibility. That generally sounds like a good compromise, if this actually helps reaching the otherwise unreachable parts of the community and have their voices heard. > Proposal 3: A decision regarding any proposal that significantly affects > backwards compatibility is within the purview of the Haskell Prime > Committee, not the Core Libraries Committee. I don't see how that would change much. The prior Haskell Prime Committee has been traditionally self-elected as well. So it's just the label of the committee you'd swap out. In the recent call of nominations[1] for Haskell Prime, the stated area of work for the new nominations was to take care of the *language* part, because that's what we are lacking the workforce for. Since its creation for the very purpose of watching over the core libraries, the core-libraries-committee has been almost exclusively busy with evaluating and deciding about changes to the `base` library and overseeing their implementation. Transferring this huge workload to the new Haskell Prime committee members who have already their hands full with revising the language part would IMO just achieve to reduce the effectiveness of the upcoming Haskell Prime committee, and therefore increase the risk of failure in producing an adequate new Haskell Report revision. Regards, H.V.Riedel [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html From mwm at mired.org Wed Oct 21 12:19:46 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 21 Oct 2015 12:19:46 +0000 Subject: [Haskell-cafe] Committee M.O. Change Proposals (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <87pp088mh7.fsf_-_@gmail.com> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com> Message-ID: On Wed, Oct 21, 2015 at 6:56 AM Herbert Valerio Riedel wrote: > > Proposal 1: Move to community election of the members of the Core > > Libraries Committee. Yes, I know this would have its own issues. > How exactly do public elections of representatives address the problem > that some people feel left out? The issue of people feeling left out is addressed by the second part of his proposal, a low-volume (presumably announcements only) list where changes that are being seriously considered can be announced, along with pointers to the discussion areas. That way, the overhead of getting notices is near zero, and everyone can then decide whether to invest time in the > Back in February there was a large-scale survey which resulted (see [2] > for more details) in a rather unequivocal 4:1 majority *for* going > through with the otherwise controversial FTP implementation. If the > community elections would result in a similar spirit, you'd could easily > end up with a similarly 4:1 pro-change biased committee. Would you > consider that a well balanced committee formation? This shows two areas of confusion. The first is that the point of representation isn't to be well-balanced, or fair, or any such thing. it's to be representative of the community. Or at least, of some aspect of the community. Whether or not this is a problem and how to fix it are hard political problems that I doubt we're going to solve. The second is that the composition of the committee matters beyond the aspect they are supposed to represent. For instance, if the process doesn't leave final decisions in the hands of the committee, but in a general vote (just a for instance, not a proposal) then the balance or fairness of the committee is irrelevant, so long as the community trusts them to administer the process properly. In other words, we need to figure out exactly what the job of the committee is going to be before we start worrying about what kind of composition it should have. As for the issue of libraries vs. language, I think the same process should apply to both, though it might be administered by different groups in order to spread the workload around. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Wed Oct 21 12:31:18 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Wed, 21 Oct 2015 08:31:18 -0400 Subject: [Haskell-cafe] Committee M.O. Change Proposals In-Reply-To: <87pp088mh7.fsf_-_@gmail.com> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com> Message-ID: <56278596.9070005@apeiron.net> On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...] > >> In effect, only those who actively follow the libraries list have had a >> voice in these decisions. Maybe that is what the community wants. I hope >> not. How then can people like me (and Henrik and Graham) have a say >> without committing to actively following the libraries list? >> >> We have a method to solve this: elected representatives. Right now the >> Core Libraries Committee elects its own members; perhaps it is time for >> that to change. > > [...] > >> Proposal 1: Move to community election of the members of the Core >> Libraries Committee. Yes, I know this would have its own issues. > > How exactly do public elections of representatives address the problem > that some people feel left out? Have you considered nominating yourself > or somebody else you have confidence in for the core libraries > committee? You'd still have to find somebody to represent your > interests, regardless of whether the committee is self-elected or > direct-elected. > > Here's some food for thought regarding language design by voting or its > indirect form via a directly elected language committee: > > Back in February there was a large-scale survey which resulted (see [2] > for more details) in a rather unequivocal 4:1 majority *for* going > through with the otherwise controversial FTP implementation. If the > community elections would result in a similar spirit, you'd could easily > end up with a similarly 4:1 pro-change biased committee. Would you > consider that a well balanced committee formation? Thanks, all good points. It is quite possible that direct elections would produce the exact same committee. I wouldn't see that as a negative outcome at all! At least that committee would have been put in place by direct election; I would see that as strengthening their mandate. I am very much aware of the February survey. I wonder if Proposal 2, had it been in place at the time, would have increased participation in the survey. The recent kerfuffle has caught the attention of many people who don't normally follow the libraries list. Proposal 1 is an attempt to give them a voice. Yes, they would still need to find a candidate to represent their interests. If we moved to direct elections, I would consider running. However, my preference is that Proposal 3 go through in some form, in which case my main concern would be the Haskell Prime committee, and unfortunately nominations for that committee have already closed. >> Proposal 2: After a suitable period of discussion on the libraries list, >> the Core Libraries Committee will summarize the arguments for and >> against a proposal and post it, along with a (justified) preliminary >> decision, to a low-traffic, announce-only email list. After another >> suitable period of discussion, they will issue a final decision. What is >> a suitable period of time? Perhaps that depends on the properties of the >> proposal, such as whether it breaks backwards compatibility. > > That generally sounds like a good compromise, if this actually helps > reaching the otherwise unreachable parts of the community and have their > voices heard. My hope is that a low-volume mailing list would indeed reach a wider audience. >> Proposal 3: A decision regarding any proposal that significantly affects >> backwards compatibility is within the purview of the Haskell Prime >> Committee, not the Core Libraries Committee. > > I don't see how that would change much. The prior Haskell Prime > Committee has been traditionally self-elected as well. So it's just the > label of the committee you'd swap out. > > In the recent call of nominations[1] for Haskell Prime, the stated area > of work for the new nominations was to take care of the *language* part, > because that's what we are lacking the workforce for. > > Since its creation for the very purpose of watching over the core > libraries, the core-libraries-committee has been almost exclusively busy > with evaluating and deciding about changes to the `base` library and > overseeing their implementation. Transferring this huge workload to the > new Haskell Prime committee members who have already their hands full > with revising the language part would IMO just achieve to reduce the > effectiveness of the upcoming Haskell Prime committee, and therefore > increase the risk of failure in producing an adequate new Haskell Report > revision. My understanding is that much of the work of the core libraries committee does not "significantly affect backwards compatibility," at least not to the extent that MRP does. If this is the case, the bulk of their workload would not be transferred to the new Haskell Prime committee. Is my understanding incorrect? The intent of Proposal 3 was to transfer only a small fraction of the issues that come before the core libraries committee to the Haskell Prime committee. In any case, we would certainly need to clarify what "significantly affects backwards compatibility" means. Perhaps we should consider direct elections for the Haskell Prime committee as well as changing their mandate to include some subset of the changes proposed to libraries covered by the Haskell Report. My understanding of the current state of affairs is that the Haskell Prime committee is charged with producing a new report, but the core libraries committee is in charge of the library part of that report. Is that correct? Cheers, Geoff > Regards, > H.V.Riedel > > [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html From mainland at apeiron.net Wed Oct 21 13:27:22 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Wed, 21 Oct 2015 09:27:22 -0400 Subject: [Haskell-cafe] Committee M.O. Change Proposals In-Reply-To: <87pp088mh7.fsf_-_@gmail.com> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com> Message-ID: <562792BA.9000908@apeiron.net> Apologies for the previous mailer-mangled "draft"... On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...] > >> In effect, only those who actively follow the libraries list have had a >> voice in these decisions. Maybe that is what the community wants. I hope >> not. How then can people like me (and Henrik and Graham) have a say >> without committing to actively following the libraries list? >> >> We have a method to solve this: elected representatives. Right now the >> Core Libraries Committee elects its own members; perhaps it is time for >> that to change. > [...] > >> Proposal 1: Move to community election of the members of the Core >> Libraries Committee. Yes, I know this would have its own issues. > How exactly do public elections of representatives address the problem > that some people feel left out? Have you considered nominating yourself > or somebody else you have confidence in for the core libraries > committee? You'd still have to find somebody to represent your > interests, regardless of whether the committee is self-elected or > direct-elected. > > Here's some food for thought regarding language design by voting or its > indirect form via a directly elected language committee: > > Back in February there was a large-scale survey which resulted (see [2] > for more details) in a rather unequivocal 4:1 majority *for* going > through with the otherwise controversial FTP implementation. If the > community elections would result in a similar spirit, you'd could easily > end up with a similarly 4:1 pro-change biased committee. Would you > consider that a well balanced committee formation? Thanks, all good points. It is quite possible that direct elections would produce the exact same committee. I wouldn't see that as a negative outcome at all! At least that committee would have been put in place by direct election; I would see that as strengthening their mandate. I am very much aware of the February survey. I wonder if Proposal 2, had it been in place at the time, would have increased participation in the survey. The recent kerfuffle has caught the attention of many people who don't normally follow the libraries list. Proposal 1 is an attempt to give them a voice. Yes, they would still need to find a candidate to represent their interests. If we moved to direct elections, I would consider running. However, my preference is that Proposal 3 go through in some form, in which case my main concern would be the Haskell Prime committee, and unfortunately nominations for that committee have already closed. >> Proposal 2: After a suitable period of discussion on the libraries list, >> the Core Libraries Committee will summarize the arguments for and >> against a proposal and post it, along with a (justified) preliminary >> decision, to a low-traffic, announce-only email list. After another >> suitable period of discussion, they will issue a final decision. What is >> a suitable period of time? Perhaps that depends on the properties of the >> proposal, such as whether it breaks backwards compatibility. > That generally sounds like a good compromise, if this actually helps > reaching the otherwise unreachable parts of the community and have their > voices heard. My hope is that a low-volume mailing list would indeed reach a wider audience. >> Proposal 3: A decision regarding any proposal that significantly affects >> backwards compatibility is within the purview of the Haskell Prime >> Committee, not the Core Libraries Committee. > I don't see how that would change much. The prior Haskell Prime > Committee has been traditionally self-elected as well. So it's just the > label of the committee you'd swap out. > > In the recent call of nominations[1] for Haskell Prime, the stated area > of work for the new nominations was to take care of the *language* part, > because that's what we are lacking the workforce for. > > Since its creation for the very purpose of watching over the core > libraries, the core-libraries-committee has been almost exclusively busy > with evaluating and deciding about changes to the `base` library and > overseeing their implementation. Transferring this huge workload to the > new Haskell Prime committee members who have already their hands full > with revising the language part would IMO just achieve to reduce the > effectiveness of the upcoming Haskell Prime committee, and therefore > increase the risk of failure in producing an adequate new Haskell Report > revision. My understanding is that much of the work of the core libraries committee does not "significantly affect backwards compatibility," at least not to the extent that MRP does. If this is the case, the bulk of their workload would not be transferred to the new Haskell Prime committee. Is my understanding incorrect? The intent of Proposal 3 was to transfer only a small fraction of the issues that come before the core libraries committee to the Haskell Prime committee. In any case, we would certainly need to clarify what "significantly affects backwards compatibility" means. Perhaps we should consider direct elections for the Haskell Prime committee as well as changing their mandate to include some subset of the changes proposed to libraries covered by the Haskell Report. My understanding of the current state of affairs is that the Haskell Prime committee is charged with producing a new report, but the core libraries committee is in charge of the library part of that report. Is that correct? Cheers, Geoff > Regards, > H.V.Riedel > > [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html > From eir at cis.upenn.edu Wed Oct 21 18:02:28 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 21 Oct 2015 14:02:28 -0400 Subject: [Haskell-cafe] In two weeks: Hac Phi in Philadelphia, Nov 6-8 In-Reply-To: <0AF7A0FF-3237-41C3-8C19-11CE58E32862@cis.upenn.edu> References: <0AF7A0FF-3237-41C3-8C19-11CE58E32862@cis.upenn.edu> Message-ID: <84B11CB9-31B9-48F8-9B33-096AC9D09D11@cis.upenn.edu> Hi caf?, Hac Phi, a yearly weekend of Haskell in Philadelphia, will take place **in two weeks** on Nov. 6-8, hosted at the University of Pennsylvania. Hac Phi is a gathering of hackers and Haskell enthusiasts. Come bring a project you're working on or offer to help someone else on a project of theirs. Come give a talk if you've got something to share. Come to learn something new. This is a free event, generously sponsored by the University of Pennsylvania, Jane Street, and S&P Capital IQ. Please join our merry crew. Registration closes next Friday, October 30. And, if your company likes this sort of thing, we are looking for one more sponsor. Please email me directly if you may be able to help. Thanks! All the details are on the wiki page: https://wiki.haskell.org/Hac_Phi I hope to see you there! Richard From alois.cochard at gmail.com Wed Oct 21 18:48:31 2015 From: alois.cochard at gmail.com (Alois Cochard) Date: Wed, 21 Oct 2015 20:48:31 +0200 Subject: [Haskell-cafe] [ANN] codex 0.4 Message-ID: Hello Caf?, I have released a new version of `codex`[1] (a ctags file generator for cabal/stack projects and their dependencies). This release include some fixes but more important it *include support for `stack`* projects. As `stack` is multi-platform and so is `codex`, it should work seamlessly on any OS but I have only done testing on unix. Cheers [1] https://github.com/ aloiscochard/ codex -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Oct 21 19:54:17 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 21 Oct 2015 15:54:17 -0400 Subject: [Haskell-cafe] Committee M.O. Change Proposals In-Reply-To: <56278596.9070005@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com> <56278596.9070005@apeiron.net> Message-ID: The committee was formed from a pool of suggestions supplied to SPJ that represented a fairly wide cross-section of the community. Simon initially offered both myself and Johan Tibell the role of co-chairs. Johan ultimately declined. In the end, putting perhaps too simple a spin on it, the initial committee was selected: Michael Snoyman for commercial interest, Mark Lentczner representing the needs of the Platform and implementation concerns, Brent Yorgey on the theory side, Doug Beardsley representing practitioners, Joachim Breitner had expressed interest in working on split base, which at the time was a much more active concern, Dan Doel represented a decent balance of theory and practice. Since then we had two slots open up on the committee, and precisely two self-nominations to fill them, which rather simplified the selection process. Brent and Doug rotated out and Eric Mertens and Luite Stegeman rotated in. Technically, yes, we are self-selected going forward, based on the precedent of the haskell.org committee and haskell-prime committees, but you'll note this hasn't actually been a factor yet as there hasn't been any decision point reached where that has affected a membership decision. -Edward On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland wrote: > On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: > > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > > [...] > > >> In effect, only those who actively follow the libraries list have > had a >> voice in these decisions. Maybe that is what the community > wants. I hope >> not. How then can people like me (and Henrik and > Graham) have a say >> without committing to actively following the > libraries list? >> >> We have a method to solve this: elected > representatives. Right now the >> Core Libraries Committee elects its > own members; perhaps it is time for >> that to change. > > [...] > >> > Proposal 1: Move to community election of the members of the Core >> > Libraries Committee. Yes, I know this would have its own issues. > > How > exactly do public elections of representatives address the problem > > that some people feel left out? Have you considered nominating yourself > > or somebody else you have confidence in for the core libraries > > committee? You'd still have to find somebody to represent your > > interests, regardless of whether the committee is self-elected or > > direct-elected. > > Here's some food for thought regarding language > design by voting or its > indirect form via a directly elected language > committee: > > Back in February there was a large-scale survey which > resulted (see [2] > for more details) in a rather unequivocal 4:1 > majority *for* going > through with the otherwise controversial FTP > implementation. If the > community elections would result in a similar > spirit, you'd could easily > end up with a similarly 4:1 pro-change > biased committee. Would you > consider that a well balanced committee > formation? > > Thanks, all good points. > > It is quite possible that direct elections would produce the exact same > committee. I wouldn't see that as a negative outcome at all! At least > that committee would have been put in place by direct election; I would > see that as strengthening their mandate. > > I am very much aware of the February survey. I wonder if Proposal 2, had > it been in place at the time, would have increased participation in the > survey. > > The recent kerfuffle has caught the attention of many people who don't > normally follow the libraries list. Proposal 1 is an attempt to give > them a voice. Yes, they would still need to find a candidate to > represent their interests. If we moved to direct elections, I would > consider running. However, my preference is that Proposal 3 go through > in some form, in which case my main concern would be the Haskell Prime > committee, and unfortunately nominations for that committee have already > closed. > > >> Proposal 2: After a suitable period of discussion on the libraries > list, >> the Core Libraries Committee will summarize the arguments for and > >> > against a proposal and post it, along with a (justified) preliminary >> > decision, to a low-traffic, announce-only email list. After another >> > suitable period of discussion, they will issue a final decision. What is > >> a suitable period of time? Perhaps that depends on the properties of > the >> proposal, such as whether it breaks backwards compatibility. > > > That generally sounds like a good compromise, if this actually helps > > reaching the otherwise unreachable parts of the community and have their > > voices heard. > > My hope is that a low-volume mailing list would indeed reach a wider > audience. > > >> Proposal 3: A decision regarding any proposal that significantly > affects >> backwards compatibility is within the purview of the Haskell > Prime > >> Committee, not the Core Libraries Committee. > > I don't see how that > would change much. The prior Haskell Prime > Committee has been > traditionally self-elected as well. So it's just the > label of the > committee you'd swap out. > > In the recent call of nominations[1] for > Haskell Prime, the stated area > of work for the new nominations was to > take care of the *language* part, > because that's what we are lacking > the workforce for. > > Since its creation for the very purpose of > watching over the core > libraries, the core-libraries-committee has > been almost exclusively busy > with evaluating and deciding about > changes to the `base` library and > overseeing their implementation. > Transferring this huge workload to the > new Haskell Prime committee > members who have already their hands full > with revising the language > part would IMO just achieve to reduce the > effectiveness of the > upcoming Haskell Prime committee, and therefore > increase the risk of > failure in producing an adequate new Haskell Report > revision. > > My understanding is that much of the work of the core libraries > committee does not "significantly affect backwards compatibility," at > least not to the extent that MRP does. If this is the case, the bulk of > their workload would not be transferred to the new Haskell Prime > committee. Is my understanding incorrect? > > The intent of Proposal 3 was to transfer only a small fraction of the > issues that come before the core libraries committee to the Haskell > Prime committee. In any case, we would certainly need to clarify what > "significantly affects backwards compatibility" means. > > Perhaps we should consider direct elections for the Haskell Prime > committee as well as changing their mandate to include some subset of > the changes proposed to libraries covered by the Haskell Report. My > understanding of the current state of affairs is that the Haskell Prime > committee is charged with producing a new report, but the core libraries > committee is in charge of the library part of that report. Is that > correct? > > Cheers, > Geoff > > > Regards, > H.V.Riedel > > [1]: > https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > > [2]: > https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Wed Oct 21 20:04:04 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Wed, 21 Oct 2015 16:04:04 -0400 Subject: [Haskell-cafe] Committee M.O. Change Proposals In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com> <56278596.9070005@apeiron.net> Message-ID: <5627EFB4.8020800@apeiron.net> Thanks for the background, Edward. I don't mean to question the composition of the committee, only to start a discussion about how the community might handle the selection process going forward. I apologize if I was not clear about that. As I said below, if a direct vote resulted in the same committee we would have had under the current system, I would consider that a success! We may also see a larger nomination pool in the future :) Cheers, Geoff On 10/21/2015 03:54 PM, Edward Kmett wrote: > The committee was formed from a pool of suggestions supplied to SPJ > that represented a fairly wide cross-section of the community. > > Simon initially offered both myself and Johan Tibell the role of > co-chairs. Johan ultimately declined. > > In the end, putting perhaps too simple a spin on it, the initial > committee was selected: Michael Snoyman for commercial interest, Mark > Lentczner representing the needs of the Platform and implementation > concerns, Brent Yorgey on the theory side, Doug Beardsley representing > practitioners, Joachim Breitner had expressed interest in working on > split base, which at the time was a much more active concern, Dan Doel > represented a decent balance of theory and practice. > > Since then we had two slots open up on the committee, and precisely > two self-nominations to fill them, which rather simplified the > selection process. Brent and Doug rotated out and Eric Mertens and > Luite Stegeman rotated in. > > Technically, yes, we are self-selected going forward, based on the > precedent of the haskell.org committee and > haskell-prime committees, but you'll note this hasn't actually been a > factor yet as there hasn't been any decision point reached where that > has affected a membership decision. > > -Edward > > On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland > > wrote: > > On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: > > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland > wrote: > > [...] > > >> In effect, only those who actively follow the libraries list have > had a >> voice in these decisions. Maybe that is what the community > wants. I hope >> not. How then can people like me (and Henrik and > Graham) have a say >> without committing to actively following the > libraries list? >> >> We have a method to solve this: elected > representatives. Right now the >> Core Libraries Committee elects its > own members; perhaps it is time for >> that to change. > > [...] > >> > Proposal 1: Move to community election of the members of the Core >> > Libraries Committee. Yes, I know this would have its own issues. > > > How > exactly do public elections of representatives address the problem > > that some people feel left out? Have you considered nominating > yourself > > or somebody else you have confidence in for the core libraries > > committee? You'd still have to find somebody to represent your > > interests, regardless of whether the committee is self-elected or > > direct-elected. > > Here's some food for thought regarding language > design by voting or its > indirect form via a directly elected > language > committee: > > Back in February there was a large-scale survey which > resulted (see [2] > for more details) in a rather unequivocal 4:1 > majority *for* going > through with the otherwise controversial FTP > implementation. If the > community elections would result in a similar > spirit, you'd could easily > end up with a similarly 4:1 pro-change > biased committee. Would you > consider that a well balanced committee > formation? > > Thanks, all good points. > > It is quite possible that direct elections would produce the exact > same > committee. I wouldn't see that as a negative outcome at all! At least > that committee would have been put in place by direct election; I > would > see that as strengthening their mandate. > > I am very much aware of the February survey. I wonder if Proposal > 2, had > it been in place at the time, would have increased participation > in the > survey. > > The recent kerfuffle has caught the attention of many people who don't > normally follow the libraries list. Proposal 1 is an attempt to give > them a voice. Yes, they would still need to find a candidate to > represent their interests. If we moved to direct elections, I would > consider running. However, my preference is that Proposal 3 go through > in some form, in which case my main concern would be the Haskell Prime > committee, and unfortunately nominations for that committee have > already > closed. > > >> Proposal 2: After a suitable period of discussion on the > libraries list, >> the Core Libraries Committee will summarize the > arguments for and >> > against a proposal and post it, along with a (justified) > preliminary >> > decision, to a low-traffic, announce-only email list. After another >> > suitable period of discussion, they will issue a final decision. > What is > >> a suitable period of time? Perhaps that depends on the > properties of > the >> proposal, such as whether it breaks backwards > compatibility. > > > That generally sounds like a good compromise, if this actually helps > > reaching the otherwise unreachable parts of the community and have > their > > voices heard. > > My hope is that a low-volume mailing list would indeed reach a wider > audience. > > >> Proposal 3: A decision regarding any proposal that > significantly affects >> backwards compatibility is within the > purview of the Haskell Prime > >> Committee, not the Core Libraries Committee. > > I don't see > how that > would change much. The prior Haskell Prime > Committee has been > traditionally self-elected as well. So it's just the > label of the > committee you'd swap out. > > In the recent call of nominations[1] for > Haskell Prime, the stated area > of work for the new nominations > was to > take care of the *language* part, > because that's what we are lacking > the workforce for. > > Since its creation for the very purpose of > watching over the core > libraries, the core-libraries-committee has > been almost exclusively busy > with evaluating and deciding about > changes to the `base` library and > overseeing their implementation. > Transferring this huge workload to the > new Haskell Prime committee > members who have already their hands full > with revising the language > part would IMO just achieve to reduce the > effectiveness of the > upcoming Haskell Prime committee, and therefore > increase the risk of > failure in producing an adequate new Haskell Report > revision. > > My understanding is that much of the work of the core libraries > committee does not "significantly affect backwards compatibility," at > least not to the extent that MRP does. If this is the case, the > bulk of > their workload would not be transferred to the new Haskell Prime > committee. Is my understanding incorrect? > > The intent of Proposal 3 was to transfer only a small fraction of the > issues that come before the core libraries committee to the Haskell > Prime committee. In any case, we would certainly need to clarify what > "significantly affects backwards compatibility" means. > > Perhaps we should consider direct elections for the Haskell Prime > committee as well as changing their mandate to include some subset of > the changes proposed to libraries covered by the Haskell Report. My > understanding of the current state of affairs is that the Haskell > Prime > committee is charged with producing a new report, but the core > libraries > committee is in charge of the library part of that report. Is that > correct? > > Cheers, > Geoff > > > Regards, > H.V.Riedel > > [1]: > https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > > [2]: > https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html > > From defigueiredo at ucdavis.edu Wed Oct 21 23:42:29 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Wed, 21 Oct 2015 17:42:29 -0600 Subject: [Haskell-cafe] how to create a pipes producer from websockets? Message-ID: <562822E5.2040802@ucdavis.edu> Hello All, I am trying to use both the websockets library and the pipes library. They seem like a natural fit. However, I wanted to use the websockets library to build a pipes 'Producer' and that does not seem possible without some heavy lifting. The websockets library does not give me a connection I can read from and write to. Instead, I need to supply an IO action (called a clientApp). And execute it using something like: --runClient :: String -- ^ Host -- -> Int -- ^ Port -- -> String -- ^ Path -- -> ClientApp a -- ^ Client application -- type ClientApp a = Connection -> IO a -- -> IO a main :: IO () main = withSocketsDo $ runClient "echo.websocket.org" 80 "/" app The problem happens when you couple this restriction with the requirement that ClientApps have type 'Connection -> IO a'. Pipes producers are Monad transformer stacks. For example, I would like to build something like: messageProducer :: Producer' WebsocketMessage IO () But this does not run in the IO monad and at the same time I cannot get a 'Connection' object unless I use runClient. So, it seems I have a catch22 situation. Or have I overlooked something? I'd rather not have to do "un-lifting" on the monad transformer stack. Has anyone done this before? Any suggestions on how to go about it? Thanks, Dimitri -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuzzeb at gmail.com Thu Oct 22 00:10:32 2015 From: wuzzeb at gmail.com (John Lenz) Date: Wed, 21 Oct 2015 19:10:32 -0500 Subject: [Haskell-cafe] how to create a pipes producer from websockets? In-Reply-To: <562822E5.2040802@ucdavis.edu> References: <562822E5.2040802@ucdavis.edu> Message-ID: The yesod-websockets library has a conduit api on top of websockets which I use, so I have conduits processing messages. Conduit and pipes work similarly, so I suspect the technique from yesod-websockets will work fine for pipes, just look at the yesod-websockets source code: https://hackage.haskell.org/package/yesod-websockets-0.2.3/docs/Yesod-WebSockets.html On Wed, Oct 21, 2015 at 6:42 PM, Dimitri DeFigueiredo < defigueiredo at ucdavis.edu> wrote: > Hello All, > > I am trying to use both the websockets library and the pipes library. They > seem like a natural fit. However, I wanted to use the websockets library to > build a pipes 'Producer' and that does not seem possible without some heavy > lifting. > > The websockets library does not give me a connection I can read from and > write to. Instead, I need to supply an IO action (called a clientApp). And > execute it using something like: > > --runClient :: String -- ^ Host > -- -> Int -- ^ Port > -- -> String -- ^ Path > -- -> ClientApp a -- ^ Client application -- type ClientApp a = > Connection -> IO a > -- -> IO a > > main :: IO () > main = withSocketsDo $ runClient "echo.websocket.org" 80 "/" app > > The problem happens when you couple this restriction with the requirement > that ClientApps have type 'Connection -> IO a'. Pipes producers are Monad > transformer stacks. For example, I would like to build something like: > messageProducer :: Producer' WebsocketMessage IO () > > But this does not run in the IO monad and at the same time I cannot get a > 'Connection' object unless I use runClient. > > So, it seems I have a catch22 situation. Or have I overlooked something? > I'd rather not have to do "un-lifting" on the monad transformer stack. > > Has anyone done this before? Any suggestions on how to go about it? > > > Thanks, > > > Dimitri > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erkokl at gmail.com Thu Oct 22 04:48:29 2015 From: erkokl at gmail.com (Levent Erkok) Date: Wed, 21 Oct 2015 21:48:29 -0700 Subject: [Haskell-cafe] MonadFix wiki confusion In-Reply-To: References: Message-ID: Hi Samuel: You are correct that the lazy construction of the tuple is crucial in tying-the-monadic-knot. However, the point about making the BTree constructors strict is still interesting, as it pertains to delayed use of recursive values, rather than how they are represented/stored. The situation is really no different than a regular recursive let-expression in a non-monadic context. Of course, it would still be fine to update the text to make that point clear like you suggested, should you be so inclined! -Levent. On Sun, Oct 18, 2015 at 7:40 AM, Samuel R?dal wrote: > Hello, > > the MonadFix wiki at https://wiki.haskell.org/MonadFix has a statement > that I feel is a bit misleading. > > In section "2.2 Lazy algorithm interleaved with effects", it claims > that making the BTree data structure strict doesn't cause endless > recursion. > > Well, that's true, but that's just because rep_x_sum returns a tuple > containing the BTree and the summed values of the current subtree, and > the tuple is lazily constructed - postponing the construction of the > tree value. So highlighting the fact that the function still works > when the BTree structure is made strict is kind of a red herring. > > Maybe the confusion could be avoided by removing the part about making > BTree strict, or adding a note about the tuple still ensuring lazy > construction? > > -- > Samuel > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alllex.semin at gmail.com Thu Oct 22 12:47:53 2015 From: alllex.semin at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHQtdC80LjQvQ==?=) Date: Thu, 22 Oct 2015 15:47:53 +0300 Subject: [Haskell-cafe] New STM Data Structures Collection Message-ID: Hi everyone! I want to present a couple of STM data structures which were implemented by me and Ryan Yates this summer (during GSOC 2015). I decided to create only a candidate package [1]. I would be glad if anyone can take a look and/or comment on topic. Since Hackage does not provide the easy way to `cabal install` candidate packages I have written a script [2] which should do all the work for you. It create a directory in /tmp and initialized sandbox along with cloning the library from github [3]. After that it will download Haskell program with an example of data structure usage. ?Thank you for your attention. [1] https://hackage.haskell.org/package/stm-data-collection-0.1.0.0/candidate [2] https://gist.github.com/Alllex/445f3d74e872fe032596 [3] ?https://github.com/Alllex/stm-data-collection -- Regards, Alex Semin -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Thu Oct 22 14:03:05 2015 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Thu, 22 Oct 2015 14:03:05 +0000 (UTC) Subject: [Haskell-cafe] New STM Data Structures Collection References: Message-ID: ??????? ????? gmail.com> writes: > I want to present a couple of STM data structures ... Nice. It'd be good to see source code and measurements for an "actual" use case (say, Dijkstra's algorithm, using your PQ API and implementation) - J.W. From felipe.lessa at gmail.com Thu Oct 22 17:42:47 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 22 Oct 2015 15:42:47 -0200 Subject: [Haskell-cafe] New STM Data Structures Collection In-Reply-To: References: Message-ID: <56292017.9010903@gmail.com> A suggestion after looking at the API docs: Usually modules called "Internal" are not meant to be used by the user of the library unless they really know what they're doing. However, the description of the package says that I should choose the implementation that suits my needs, so these aren't "Internal" modules after all. Also, they don't export anything that I would qualify as internal, such as data type constructors and helper functions. I'd suggest either renaming the "Internal" portion of the hierarchy to something else (such as "Impl") or dropping it completely (i.e., leaving the implementation modules on the same level as the "Class" modules). Everything else looks quite good! An advanced request would be having benchmarks showing which implementation is best for which use cases, esp. for [ALPRST]*SLPQ, but that's non-trivial. Cheers, :) -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From alllex.semin at gmail.com Thu Oct 22 18:05:47 2015 From: alllex.semin at gmail.com (Alex Semin) Date: Thu, 22 Oct 2015 21:05:47 +0300 Subject: [Haskell-cafe] New STM Data Structures Collection In-Reply-To: <56292017.9010903@gmail.com> References: <56292017.9010903@gmail.com> Message-ID: <5629257B.6060608@gmail.com> Thanks! That's a reasonable suggestion. Actually the "Internal" module name was left there because we decided to export all implementation at the last moment. We've spent quite a lot of time working on benchmarks. Now you can find those which was ran on my laptop right in the github repo [1]. Although this kind of setting (I mean 4 capabilities) may not be the desired environment for STM-based algorithms. I believe we'll provide plots for machines with more capabilities in due course. Probably I had to include link to benchmarks into haddock package documentation. [1] https://github.com/Alllex/stm-data-collection/blob/master/charts/charts.pdf Thanks for your reply. On 22.10.2015 20:42, Felipe Lessa wrote: > A suggestion after looking at the API docs: > > Usually modules called "Internal" are not meant to be used by the user > of the library unless they really know what they're doing. However, the > description of the package says that I should choose the implementation > that suits my needs, so these aren't "Internal" modules after all. > Also, they don't export anything that I would qualify as internal, such > as data type constructors and helper functions. > > I'd suggest either renaming the "Internal" portion of the hierarchy to > something else (such as "Impl") or dropping it completely (i.e., leaving > the implementation modules on the same level as the "Class" modules). > > Everything else looks quite good! An advanced request would be having > benchmarks showing which implementation is best for which use cases, > esp. for [ALPRST]*SLPQ, but that's non-trivial. > > Cheers, :) > From alan.zimm at gmail.com Thu Oct 22 19:06:14 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 22 Oct 2015 21:06:14 +0200 Subject: [Haskell-cafe] [ANN] haskell-ide project Message-ID: The ongoing effort to save us as a community from separately implementing the same functionality over and over around IDEs[1] has found a home in the haskell-ide project on github [2]. This mail serves as a call to collaborate for all parties interested in this space. It is still at a very early stage, but the intent is to pool resources so that we can have really good support for IDEs that can extend through the entire tool chain from changes to GHC to better support tooling through the build environment and community information management. This should mean that people who are familiar with a particular part of the chain can focus their efforts there, knowing that the other parts will be covered too. This is a deliberately broad and vague scope, the reality is likely to be much more limited initially, but the sooner we can get started the sooner we will have something concrete to criticise and improve. For those wishing to get involved the following resources currently exist * the haskell-ide mailing list [3] * the github project page [1] * The #haskell-ide channel on IRC Freenode. This is not aimed at some small inner circle of people, anyone who wants to will be added to the project on github, adress your request to me or @hvr. Regards Alan [1] IDE is a loose term for anything that enables a user to interact with the code. [2] https://github.com/haskell/haskell-ide [3] https://groups.google.com/forum/#!forum/haskell-ide -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Thu Oct 22 20:14:22 2015 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu, 22 Oct 2015 16:14:22 -0400 Subject: [Haskell-cafe] MonadFix wiki confusion In-Reply-To: References: Message-ID: <5629439E.6070000@vex.net> On 2015-10-18 10:40 AM, Samuel R?dal wrote: > the MonadFix wiki at https://wiki.haskell.org/MonadFix has a statement > that I feel is a bit misleading. > > In section "2.2 Lazy algorithm interleaved with effects", it claims > that making the BTree data structure strict doesn't cause endless > recursion. > > Well, that's true, but that's just because rep_x_sum returns a tuple > containing the BTree and the summed values of the current subtree, and > the tuple is lazily constructed - postponing the construction of the > tree value. So highlighting the fact that the function still works > when the BTree structure is made strict is kind of a red herring. This shows a wrong concept. When you write this kind of code: return (x+y, a+b) the tuple is not constructed lazily. The tuple is constructed here and now. To be sure, the sub-value x+y is constructed lazily, but then you would say "x+y is constructed lazily", not "the tuple is constructed lazily". Similarly for a+b. And to say both at once, you would say "the tuple content is constructed lazily", not "the tuple is constructed lazily". The tuple itself --- a machine word standing for the data constructor (,), followed by a pointer to the thunk for x+y, followed by a pointer to the thunk for a+b --- is constructed here and now. Furthermore, if the code goes like this: return (B n x y, a+b) then not only the tuple, but also the B n x y ("the tree value"), are constructed here and now. Again, to be sure, this code is lazy on n, on x, and on y. But the tree value --- a machine word standing for the data constructor B, followed by a pointer to n, followed by a pointer to x, followed by a pointer to y --- is constructed here and now. * * * Guess what, neither can you fall back to "the content of the tuple, and/or the content of the tree value, is constructed lazily". Because it is readily refuted by an experiment. And it should be natural to think up this experiment because every time you conjecture "this works because the code is lazy on xxx" the first instinct should be "so let me run an experiment in which I force evaluatation of xxx ASAP to test the conjecture". So here it goes: {-# LANGUAGE RecursiveDo #-} import Control.Exception (evaluate) data BTree = Z | B Int BTree BTree deriving Show repsum t = do rec (u,s) <- rep_x_sum t s putStrLn "" return u rep_x_sum Z _ = return (Z, 0) rep_x_sum (B i l r) s = do putStr "(" (l',sl) <- rep_x_sum l s putStr (show i) (r',sr) <- rep_x_sum r s putStr ")" evaluate l' evaluate r' tree <- evaluate (B s l' r') sum <- evaluate (i + sl + sr) tuple <- evaluate (tree, sum) return tuple main = repsum (B 4 (B 3 Z Z) (B 5 Z (B 1 Z Z))) >>= print This experiment hastens evaluation of the tuple content and most of the tree content; for good measure, evaluate the tuple and the tree, too, whether it is redundant or not. Run this experiment. See it doesn't hang. Use this observation to refute many, many hypotheses. The only content left unevaluated is s. Laziness in s is the only laziness needed. But then I already wrote that in the article, didn't I? "The laziness needed is just in the rep_x_sum algorithm: it does not evaluate s." -------------- next part -------------- An HTML attachment was scrubbed... URL: From diaz.carrete at gmail.com Thu Oct 22 20:54:28 2015 From: diaz.carrete at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz?=) Date: Thu, 22 Oct 2015 13:54:28 -0700 (PDT) Subject: [Haskell-cafe] how to create a pipes producer from websockets? In-Reply-To: <562822E5.2040802@ucdavis.edu> References: <562822E5.2040802@ucdavis.edu> Message-ID: <3a0b79ff-0bcb-4c6e-920b-d31a8a4074df@googlegroups.com> One option is to use pipes-concurrency . Create a mailbox, and pass to *runClient *a callback that reads from the Connection and writes to the mailbox . Build a *Producer *from the other end of the mailbox and consume it in another thread. Coordinate the threads with something like concurrently from the async package. On Thursday, October 22, 2015 at 1:42:37 AM UTC+2, Dimitri DeFigueiredo wrote: > > Hello All, > > I am trying to use both the websockets library and the pipes library. They > seem like a natural fit. However, I wanted to use the websockets library to > build a pipes 'Producer' and that does not seem possible without some heavy > lifting. > > The websockets library does not give me a connection I can read from and > write to. Instead, I need to supply an IO action (called a clientApp). And > execute it using something like: > > --runClient :: String -- ^ Host > -- -> Int -- ^ Port > -- -> String -- ^ Path > -- -> ClientApp a -- ^ Client application -- type ClientApp a = > Connection -> IO a > -- -> IO a > > main :: IO () > main = withSocketsDo $ runClient "echo.websocket.org" 80 "/" app > > The problem happens when you couple this restriction with the requirement > that ClientApps have type 'Connection -> IO a'. Pipes producers are Monad > transformer stacks. For example, I would like to build something like: > messageProducer :: Producer' WebsocketMessage IO () > > But this does not run in the IO monad and at the same time I cannot get a > 'Connection' object unless I use runClient. > > So, it seems I have a catch22 situation. Or have I overlooked something? > I'd rather not have to do "un-lifting" on the monad transformer stack. > > Has anyone done this before? Any suggestions on how to go about it? > > > Thanks, > > > Dimitri > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Fri Oct 23 00:27:06 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 23 Oct 2015 13:27:06 +1300 Subject: [Haskell-cafe] New STM Data Structures Collection In-Reply-To: References: Message-ID: I'm really puzzled by the interface. class Bag b where new :: STM (b v) -- no problem here add :: b v -> v -> STM () -- no problem here isEmpty :: b v -> STM Bool -- no real problem except the pervasive one that whatever -- you learn about the state of a concurrent object must -- always be treated as out of date when you use it take :: b v -> STM v -- what is supposed to happen if the bag is empty? I was expecting an operation like maybeTake :: b v -> STM (Maybe v) From fryguybob at gmail.com Fri Oct 23 02:21:20 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Thu, 22 Oct 2015 22:21:20 -0400 Subject: [Haskell-cafe] New STM Data Structures Collection In-Reply-To: References: Message-ID: Hi Richard, The isEmpty is not out of date as STM will detect if it is and restart the transaction. The take operation will block if the bag is empty. If this isn't clear in the documentation we should make it clearer. You can write a maybeTake using orElse: maybeTake b = (Just <$> take b) `orElse` return Nothing Ryan On Thu, Oct 22, 2015 at 8:27 PM, Richard A. O'Keefe wrote: > I'm really puzzled by the interface. > > class Bag b > where > new :: STM (b v) > -- no problem here > add :: b v -> v -> STM () > -- no problem here > isEmpty :: b v -> STM Bool > -- no real problem except the pervasive one that whatever > -- you learn about the state of a concurrent object must > -- always be treated as out of date when you use it > take :: b v -> STM v > -- what is supposed to happen if the bag is empty? > > I was expecting an operation like > > maybeTake :: b v -> STM (Maybe v) > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srodal at gmail.com Fri Oct 23 03:29:52 2015 From: srodal at gmail.com (=?UTF-8?Q?Samuel_R=C3=B8dal?=) Date: Fri, 23 Oct 2015 10:29:52 +0700 Subject: [Haskell-cafe] MonadFix wiki confusion In-Reply-To: <5629439E.6070000@vex.net> References: <5629439E.6070000@vex.net> Message-ID: On Fri, Oct 23, 2015 at 3:14 AM, Albert Y. C. Lai wrote: > This shows a wrong concept. > > When you write this kind of code: > > return (x+y, a+b) > > the tuple is not constructed lazily. The tuple is constructed here and now. > > To be sure, the sub-value x+y is constructed lazily, but then you would say > "x+y is constructed lazily", not "the tuple is constructed lazily". > Similarly for a+b. And to say both at once, you would say "the tuple content > is constructed lazily", not "the tuple is constructed lazily". > > The tuple itself --- a machine word standing for the data constructor (,), > followed by a pointer to the thunk for x+y, followed by a pointer to the > thunk for a+b --- is constructed here and now. I see now that calling the tuple "lazily constructed" is incorrect. I assume it would be better to call it a lazy pair? In contrast to this implementation of "strict pairs": https://hackage.haskell.org/package/strict-0.3.2/docs/Data-Strict-Tuple.html > Furthermore, if the code goes like this: > > return (B n x y, a+b) > > then not only the tuple, but also the B n x y ("the tree value"), are > constructed here and now. Are you sure about that? By exchanging return $ (B s l' r', i + sl + sr) with let tree = B s l' r' return $ tree `seq` (tree, i + sl + sr) and having the tree data structure be strict as you suggested in the article: data BTree = Z | B !Int !BTree !BTree deriving Show I experience the hang. Maybe I'm just confused about the use of the word "constructed". > Again, to be sure, this code is lazy on n, on x, and on y. But the tree > value --- a machine word standing for the data constructor B, followed by a > pointer to n, followed by a pointer to x, followed by a pointer to y --- is > constructed here and now. > > * * * > > Guess what, neither can you fall back to "the content of the tuple, and/or > the content of the tree value, is constructed lazily". Because it is readily > refuted by an experiment. > > And it should be natural to think up this experiment because every time you > conjecture "this works because the code is lazy on xxx" the first instinct > should be "so let me run an experiment in which I force evaluatation of xxx > ASAP to test the conjecture". Yep, I also ran some experiments, which is how I found that forcing evaluation of the strict tree caused the overall evaluation to hang. > So here it goes: > > {-# LANGUAGE RecursiveDo #-} > > import Control.Exception (evaluate) > > data BTree = Z | B Int BTree BTree deriving Show > > repsum t = do > rec (u,s) <- rep_x_sum t s > putStrLn "" > return u > > rep_x_sum Z _ = return (Z, 0) > rep_x_sum (B i l r) s = do > putStr "(" > (l',sl) <- rep_x_sum l s > putStr (show i) > (r',sr) <- rep_x_sum r s > putStr ")" > evaluate l' > evaluate r' > tree <- evaluate (B s l' r') > sum <- evaluate (i + sl + sr) > tuple <- evaluate (tree, sum) > return tuple > > main = repsum (B 4 (B 3 Z Z) (B 5 Z (B 1 Z Z))) > >>= print > > > This experiment hastens evaluation of the tuple content and most of the tree > content; for good measure, evaluate the tuple and the tree, too, whether it > is redundant or not. > > Run this experiment. See it doesn't hang. Use this observation to refute > many, many hypotheses. > > The only content left unevaluated is s. Laziness in s is the only laziness > needed. But then I already wrote that in the article, didn't I? > > "The laziness needed is just in the rep_x_sum algorithm: it does not > evaluate s." But in your new example the tree data structure is no longer strict. I agree that the only laziness that's needed is to not evaluate s, and making the tree strict in the original code doesn't cause that as the tuple is still lazy. I just thought the article could be a bit more explicit about that to avoid confusion. -- Samuel From lambda.fairy at gmail.com Fri Oct 23 03:33:53 2015 From: lambda.fairy at gmail.com (Chris Wong) Date: Fri, 23 Oct 2015 16:33:53 +1300 Subject: [Haskell-cafe] New STM Data Structures Collection In-Reply-To: References: Message-ID: > The isEmpty is not out of date as STM will detect if it is and restart the > transaction. The take operation will block if the bag is empty. If this > isn't clear in the documentation we should make it clearer. You can write a > maybeTake using orElse: > > maybeTake b = (Just <$> take b) `orElse` return Nothing Note that this can also be written as maybeTake = optional . take where optional comes from Control.Applicative. -- Chris Wong (https://lambda.xyz) "I fear that Haskell is doomed to succeed." -- Tony Hoare From hjgtuyl at chello.nl Fri Oct 23 10:23:19 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Fri, 23 Oct 2015 12:23:19 +0200 Subject: [Haskell-cafe] [ANN] haskell-ide project In-Reply-To: References: Message-ID: On Thu, 22 Oct 2015 21:06:14 +0200, Alan & Kim Zimmerman wrote: > The ongoing effort to save us as a community from separately implementing > the > same functionality over and over around IDEs[1] has found a home in the > haskell-ide > project on github [2]. There is also a HaskellWiki page: https://wiki.haskell.org/IDEs Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From ratzes at gmail.com Fri Oct 23 14:26:08 2015 From: ratzes at gmail.com (Charles Durham) Date: Fri, 23 Oct 2015 10:26:08 -0400 Subject: [Haskell-cafe] 'Associative' order of calling Message-ID: Is there a name for a fold that promises to call a function such that only an associative function will always return the same result. Or in other words, it has the property that it promises to call a function "associatively" on a set of data? Thanks! Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Fri Oct 23 15:21:57 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Fri, 23 Oct 2015 17:21:57 +0200 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: Message-ID: <20151023152157.GA25220@casa.casa> On Fri, Oct 23, 2015 at 10:26:08AM -0400, Charles Durham wrote: > Is there a name for a fold that promises to call a function such that only > an associative function will always return the same result. Or in other > words, it has the property that it promises to call a function > "associatively" on a set of data? I am not sure I am understanding the question correctly. Every Monoid has a single binary operation which happens to be associative and one of the basic fold functions has signature foldMap :: (Foldable t, Monoid m) => (a -> m) -> t a -> m (which does what you expect). Does that answer your question? If not, I'd be grateful if you would provide an example. From mike at proclivis.com Fri Oct 23 15:29:03 2015 From: mike at proclivis.com (Michael Jones) Date: Fri, 23 Oct 2015 09:29:03 -0600 Subject: [Haskell-cafe] wxHaskell on Windows compilation problems Message-ID: <9CDEB451-6D8F-4274-A913-FB627848A143@proclivis.com> I?m trying to compile an established wxHaskell application (Ubuntu) on Windows 7 and after a day of frustration, I wanted to see if anyone had some clues. The problem is getting wxc to compile against wxWidgets, where wxWidgets was compiled with MinGHC (GHC 7.8.4). Following are my steps up to trouble: - On 64 bit Win 7, install MinGHC, which ends up in the AppData path. - Grab wxWidgets with git and using MSYS shell compile like: mingw32-make -f makefile.gcc SHARED=1 UNICODE=1 BUILD=release clean mingw32-make -f makefile.gcc SHARED=1 UNICODE=1 BUILD=release with the goal of compiler compatibility. - Setup some environment variables like: C_INCLUDE_PATH == C:\PCRE\include CPLUS_INCLUDE_PATH == C:\Libs\wxWidgets\3.0.2\include LIBRARY_PATH == C:\PCRE\lib;C:\Libs\wxHaskell\3.0.2\\lib\gcc_lib MSYSTEM == MINGW64 WXCFG == gcc_dll\mswu WXWIN == C:\Libs\wxWidgets\3.0.2 PATH = C:\Users\michaeljones\AppData\Local\Programs\minghc-7.8.4-x86_64\git-2.4.5.1\cmd;C:\Users\michaeljones\AppData\Local\Programs\minghc-7.8.4-x86_64\git-2.4.5.1\usr\bin;C:\Users\michaeljones\AppData\Local\Programs\minghc-7.8.4-x86_64\ghc-7.8.4\mingw\bin;C:\Users\michaeljones\AppData\Local\Programs\minghc-7.8.4-x86_64\ghc-7.8.4\bin;C:\Users\michaeljones\AppData\Local\Programs\minghc-7.8.4-x86_64\bin;C:\Users\michaeljones\AppData\Roaming\cabal\bin; - Tweak wxUSE_GRAPHICS_CONTEXT - Create sandbox for my project with pointer to a local copy of wxHaskell - Apply a few patches to enable some new table support (stable stuff) - Configure with cabal and compile The first problem is it can?t run wx-config because it looks for a script, so I tweaked the Setup.hs to use the exe and it continues to compile. It gets this error: Building wxc C:\Users\michaeljones\AppData\Local\Programs\minghc-7.8.4-x86_64\ghc-7.8.4\mingw\bin\gcc.exe -Isrc/include -IC:/Users/michaeljones /Documents/linti/libs/wxHaskell/wxc -IC:/Users/michaeljones/Documents/linti/libs/wxHaskell/wxc -DWXUSINGDLL -D_UNICODE -D__WXDEBUG __ -D__WXMSW__ -DHAVE_W32API_H -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\apppath.cpp -o dist\dist-sandbox-95204306\build\src/cp p/apppath.o In file included from C:\Libs\wxWidgets\3.0.2\include/wx/defs.h:20:0, from C:\Libs\wxWidgets\3.0.2\include/wx/wx.h:14, from src/include/wrapper.h:20, from src\cpp\apppath.cpp:1: C:\Libs\wxWidgets\3.0.2\include/wx/platform.h:136:22: fatal error: wx/setup.h: No such file or directory compilation terminated. So, I copy the wxWidgets setup.h file from include/msvc/wx to include/wx and compile to a new error: Build log ( C:\Users\michaeljones\Documents\linti\linti-beagle\.cabal-sandbox\logs\wxc-0.92.0.0.log ): Building wxc C:\Users\michaeljones\AppData\Local\Programs\minghc-7.8.4-x86_64\ghc-7.8.4\mingw\bin\gcc.exe -Isrc/include -IC:/Users/michaeljones /Documents/linti/libs/wxHaskell/wxc -IC:/Users/michaeljones/Documents/linti/libs/wxHaskell/wxc -DWXUSINGDLL -D_UNICODE -D__WXDEBUG __ -D__WXMSW__ -DHAVE_W32API_H -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\apppath.cpp -o dist\dist-sandbox-95204306\build\src/cp p/apppath.o In file included from C:\Libs\wxWidgets\3.0.2\include/wx/platform.h:136:0, from C:\Libs\wxWidgets\3.0.2\include/wx/defs.h:20, from C:\Libs\wxWidgets\3.0.2\include/wx/wx.h:14, from src/include/wrapper.h:20, from src\cpp\apppath.cpp:1: C:\Libs\wxWidgets\3.0.2\include/wx/setup.h:12:6: error: #error "This file should only be included when using Microsoft Visual C++" In file included from C:\Libs\wxWidgets\3.0.2\include/wx/platform.h:136:0, from C:\Libs\wxWidgets\3.0.2\include/wx/defs.h:20, from C:\Libs\wxWidgets\3.0.2\include/wx/wx.h:14, from src/include/wrapper.h:20, from src\cpp\apppath.cpp:1: C:\Libs\wxWidgets\3.0.2\include/wx/setup.h:121:1: error: pasting "/" and "vc_x64_dll" does not give a valid preprocessing token C:\Libs\wxWidgets\3.0.2\include/wx/setup.h:121:1: error: pasting "vc_x64_dll" and "/" does not give a valid preprocessing token C:\Libs\wxWidgets\3.0.2\include/wx/setup.h:121:1: error: pasting "/" and "msw" does not give a valid preprocessing token C:\Libs\wxWidgets\3.0.2\include/wx/setup.h:121:1: error: pasting "mswu" and "/" does not give a valid preprocessing token C:\Libs\wxWidgets\3.0.2\include/wx/setup.h:121:27: fatal error: ../../../lib/vc_x64_dll /mswu /wx/setup.h: No such file or directo I assume the problem is that the wxWidget compilation that comes with makefile.gcc is somehow bypassing some linux based compilation method and not leaving the tree in the proper state for wxHaskell. The Wiki page is based on platform, not MinGHC. I used MinGHC because it got me over problems compiling regex-pcre against libpcre where I failed with cygwin. From reading is appeared MinGHC was a good general path. Note, I had the TDM compiler on the machine, but it was taken out, so there is no accidentally use of the wrong compiler or anything going on. Does anyone have any clues how to make wxHaskell and MinGHC work together? Mike From ratzes at gmail.com Fri Oct 23 15:45:13 2015 From: ratzes at gmail.com (Charles Durham) Date: Fri, 23 Oct 2015 11:45:13 -0400 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: <20151023152157.GA25220@casa.casa> References: <20151023152157.GA25220@casa.casa> Message-ID: Yeah, sorry, should have provided an example to begin with. Let's say you have a function "thisFold :: (a -> a -> a) -> [a] -> a" and it says that the function 'f' passed in must be associative. Then it goes on to use f in "thisFold f [0,1,2]" like "f (1 (f 0 2))". Obviously f is still associative, but 'thisFold' did not call f 'associatively' on the data. My question is if there is a name for what property this broke by not calling f 'associatively'. Does that make sense? On Fri, Oct 23, 2015 at 11:21 AM, Francesco Ariis wrote: > On Fri, Oct 23, 2015 at 10:26:08AM -0400, Charles Durham wrote: > > Is there a name for a fold that promises to call a function such that > only > > an associative function will always return the same result. Or in other > > words, it has the property that it promises to call a function > > "associatively" on a set of data? > > I am not sure I am understanding the question correctly. Every Monoid has a > single binary operation which happens to be associative and one of > the basic fold functions has signature > > foldMap :: (Foldable t, Monoid m) => (a -> m) -> t a -> m > > (which does what you expect). Does that answer your question? If not, > I'd be grateful if you would provide an example. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Oct 23 15:49:03 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 23 Oct 2015 16:49:03 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> Message-ID: <20151023154903.GF16020@weber> On Fri, Oct 23, 2015 at 11:45:13AM -0400, Charles Durham wrote: > Let's say you have a function "thisFold :: (a -> a -> a) -> [a] -> a" > > and it says that the function 'f' passed in must be associative. > > Then it goes on to use f in "thisFold f [0,1,2]" like "f (1 (f 0 2))". > Obviously f is still associative, but 'thisFold' did not call f > 'associatively' on the data. My question is if there is a name for what > property this broke by not calling f 'associatively'. > > Does that make sense? I don't think it makes sense. You're asking whether there's a *name* for the property it broke, but is there even a property it broke at all? If so, can you write the property down (without naming it)? Tom From ratzes at gmail.com Fri Oct 23 16:07:57 2015 From: ratzes at gmail.com (Charles Durham) Date: Fri, 23 Oct 2015 12:07:57 -0400 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: <20151023154903.GF16020@weber> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: I can think of a few properties that folds can honor: 1. Promises to call f on all data (does not have any guarantees on order) 2. Promises to call f on all data in order (like a left fold) 3. Promises to call f "associatively" (perhaps can be formalized as an in order break down of the data into tree structures) I'm assuming at least #1 has a well known name (something completeness?) On Fri, Oct 23, 2015 at 11:49 AM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Fri, Oct 23, 2015 at 11:45:13AM -0400, Charles Durham wrote: > > Let's say you have a function "thisFold :: (a -> a -> a) -> [a] -> a" > > > > and it says that the function 'f' passed in must be associative. > > > > Then it goes on to use f in "thisFold f [0,1,2]" like "f (1 (f 0 2))". > > Obviously f is still associative, but 'thisFold' did not call f > > 'associatively' on the data. My question is if there is a name for what > > property this broke by not calling f 'associatively'. > > > > Does that make sense? > > I don't think it makes sense. You're asking whether there's a *name* for > the property it broke, but is there even a property it broke at all? If > so, > can you write the property down (without naming it)? > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Oct 23 16:12:06 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 23 Oct 2015 17:12:06 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: <20151023161206.GG16020@weber> On Fri, Oct 23, 2015 at 12:07:57PM -0400, Charles Durham wrote: > I can think of a few properties that folds can honor: > > 1. Promises to call f on all data (does not have any guarantees on order) > 2. Promises to call f on all data in order (like a left fold) > 3. Promises to call f "associatively" (perhaps can be formalized as an in > order break down of the data into tree structures) > > I'm assuming at least #1 has a well known name (something completeness?) 2. doesn't have any meaning in a pure language, I think. What would it mean to call f on data out of order? From fa-ml at ariis.it Fri Oct 23 16:38:22 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Fri, 23 Oct 2015 18:38:22 +0200 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: <20151023161206.GG16020@weber> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <20151023161206.GG16020@weber> Message-ID: <20151023163822.GA27220@casa.casa> On Fri, Oct 23, 2015 at 05:12:06PM +0100, Tom Ellis wrote: > On Fri, Oct 23, 2015 at 12:07:57PM -0400, Charles Durham wrote: > > I can think of a few properties that folds can honor: > > > > 1. Promises to call f on all data (does not have any guarantees on order) > > 2. Promises to call f on all data in order (like a left fold) > > 3. Promises to call f "associatively" (perhaps can be formalized as an in > > order break down of the data into tree structures) > > > > I'm assuming at least #1 has a well known name (something completeness?) > > 2. doesn't have any meaning in a pure language, I think. What would it mean > to call f on data out of order? He gave an example in his previous email: On Fri, Oct 23, 2015 at 11:45:13AM -0400, Charles Durham wrote: > Let's say you have a function "thisFold :: (a -> a -> a) -> [a] -> a" > > and it says that the function 'f' passed in must be associative. > > Then it goes on to use f in "thisFold f [0,1,2]" like "f (1 (f 0 2))". > Obviously f is still associative, but 'thisFold' did not call f > 'associatively' on the data. I guess it boils down to "toList has to make sense". Which for every Foldable instance I can think of does, but it's not really a property, rather what the instance wants to capture. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Oct 23 16:46:11 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 23 Oct 2015 17:46:11 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: <20151023163822.GA27220@casa.casa> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <20151023161206.GG16020@weber> <20151023163822.GA27220@casa.casa> Message-ID: <20151023164611.GH16020@weber> On Fri, Oct 23, 2015 at 06:38:22PM +0200, Francesco Ariis wrote: > On Fri, Oct 23, 2015 at 05:12:06PM +0100, Tom Ellis wrote: > > On Fri, Oct 23, 2015 at 12:07:57PM -0400, Charles Durham wrote: > > > I can think of a few properties that folds can honor: > > > > > > 1. Promises to call f on all data (does not have any guarantees on order) > > > 2. Promises to call f on all data in order (like a left fold) > > > 3. Promises to call f "associatively" (perhaps can be formalized as an in > > > order break down of the data into tree structures) > > > > > > I'm assuming at least #1 has a well known name (something completeness?) > > > > 2. doesn't have any meaning in a pure language, I think. What would it mean > > to call f on data out of order? > > He gave an example in his previous email: > > On Fri, Oct 23, 2015 at 11:45:13AM -0400, Charles Durham wrote: > > Let's say you have a function "thisFold :: (a -> a -> a) -> [a] -> a" > > > > and it says that the function 'f' passed in must be associative. > > > > Then it goes on to use f in "thisFold f [0,1,2]" like "f (1 (f 0 2))". > > Obviously f is still associative, but 'thisFold' did not call f > > 'associatively' on the data. Oh, I think I see. Not temporal order, but an order "determined" by `f`. In this case I would just say that property is that "the function factors through `foldl f`", i.e. is `g . foldl f` for some `g`. Tom From defigueiredo at ucdavis.edu Fri Oct 23 19:39:32 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Fri, 23 Oct 2015 13:39:32 -0600 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting be automated? In-Reply-To: <20151023161206.GG16020@weber> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <20151023161206.GG16020@weber> Message-ID: <562A8CF4.4010306@ucdavis.edu> Hello All, I have recently encountered 2 situations where I needed an IO action, but only had a monad stack with IO at the bottom. The two examples were: 1. from Control.Concurrent.Async withAsync :: IO a -> (Async a -> IO b) -> IO b 2. from Network.WebSockets runClient :: String -- ^ Host -> Int -- ^ Port -> String -- ^ Path -> (Connection -> IO a) -- ^ Client application -> IO a I need to pass a function that returns an IO action to both these functions. I think my life would be easier if the function signatures were: 1. withAsync :: MonadIO mIO => mIO a -> (Async a -> mIO b) -> mIO b 2. from Network.WebSockets runClient :: MonadIO mIO => -> String -- ^ Host -> Int -- ^ Port -> String -- ^ Path -> (Connection -> mIO a) -- ^ Client application -> mIO a There are many other examples, a notable one are the functions in Control.Exception also always expect an IO action. I know we have libraries to solve this problem, such as lifted-async, lifted-base and the functionality in Control.Monad.Trans.Control. But what are the best practices for writing code that uses Monadic actions? Should I always generalize my type signatures or just expect others to use the libraries when they need to? Also, to some extent it seems trivial to re-write a library like async with the generalized signatures I need. I would just need to apply 'lift' everywhere. Couldn't the compiler do this for me? ;-) Thanks, Dimitri -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Fri Oct 23 20:39:02 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Fri, 23 Oct 2015 23:39:02 +0300 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting be automated? In-Reply-To: <562A8CF4.4010306@ucdavis.edu> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <20151023161206.GG16020@weber> <562A8CF4.4010306@ucdavis.edu> Message-ID: <1445632742.2175.16.camel@gmail.com> On Fri, 2015-10-23 at 13:39 -0600, Dimitri DeFigueiredo wrote: > Hello All, > > I have recently encountered 2 situations where I needed an IO action, > but only had a monad stack with IO at the bottom. > > The two examples were: > > 1. from Control.Concurrent.Async > ????withAsync :: IO a -> (Async a -> IO b) -> IO b > > 2. from Network.WebSockets > ????runClient :: String???????-- ^ Host > ??????????????-> Int??????????-- ^ Port > ??????????????-> String???????-- ^ Path > ??????????????-> (Connection -> IO a) -- ^ Client application > ??????????????-> IO a > > I need to pass a function that returns an IO action to both these > functions. > I think my life would be easier if the function signatures were: > > 1. withAsync :: MonadIO mIO => mIO a -> (Async a -> mIO b) -> mIO b > > 2. from Network.WebSockets > ????runClient :: MonadIO mIO => > ??????????????-> String???????-- ^ Host > ??????????????-> Int??????????-- ^ Port > ??????????????-> String???????-- ^ Path > ??????????????-> (Connection -> mIO a) -- ^ Client application > ??????????????-> mIO a > > There are many other examples, a notable one are the functions in > Control.Exception also always expect an IO action. > I know we have libraries to solve this problem, such as lifted-async, > lifted-base and the functionality in Control.Monad.Trans.Control. > But what are the best practices for writing code that uses Monadic > actions? Should I always generalize my type signatures or just expect > others to use the libraries when they need to? > > Also, to some extent it seems trivial to re-write a library like > async > with the generalized signatures I need. I would just need to apply > 'lift' everywhere. Couldn't the compiler do this for me? ;-) It is hard to implement for `withAsync` because it has to pass the first argument to `forkIO` which doesn't accept `MonadIO`. We need something opposite to `liftIO` to do that. That is why `withAsync` from `lifted-async` requires `MonadBaseControl IO m` context. Semantically, when you want to run `StateT Int IO a` concurrently, you have to decide how the child state will interact with a state of the main computation. E.g. you may decide to copy state and discard any changes made in the child computation. Or you may merge states somehow. Anyway, it is better to be explicit here. Though `withAsync` can be easily generalized to something like withAsync ::?MonadBaseControl?mIO => mIO a -> (Async a -> mIO b) -> mIO b It will let you minimize number of lifts is client code. But there is other way -- don't use monad transformers based on `IO`. Seriously, in most cases `StateT`, `ExceptT` or other transformers make no sense with `IO` as a base monad. `IO` is already suitable for state passing and error handling, no need to add this functionality via transformers. Thanks, Yuras From spam at scientician.net Fri Oct 23 21:24:47 2015 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 23 Oct 2015 23:24:47 +0200 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: On 10/23/2015 06:07 PM, Charles Durham wrote: > I can think of a few properties that folds can honor: > > 1. Promises to call f on all data (does not have any guarantees on order) "Exhaustive"? ... but then that's not really observable in a language like Haskell, except if you monitor CPU heat. Regards, From defigueiredo at ucdavis.edu Fri Oct 23 22:25:43 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Fri, 23 Oct 2015 16:25:43 -0600 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting be automated? In-Reply-To: <1445632742.2175.16.camel@gmail.com> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <20151023161206.GG16020@weber> <562A8CF4.4010306@ucdavis.edu> <1445632742.2175.16.camel@gmail.com> Message-ID: <562AB3E7.4010504@ucdavis.edu> On 10/23/15 2:39 PM, Yuras Shumovich wrote: > On Fri, 2015-10-23 at 13:39 -0600, Dimitri DeFigueiredo wrote: >> Hello All, >> >> I have recently encountered 2 situations where I needed an IO action, >> but only had a monad stack with IO at the bottom. >> >> The two examples were: >> >> 1. from Control.Concurrent.Async >> withAsync :: IO a -> (Async a -> IO b) -> IO b >> >> 2. from Network.WebSockets >> runClient :: String -- ^ Host >> -> Int -- ^ Port >> -> String -- ^ Path >> -> (Connection -> IO a) -- ^ Client application >> -> IO a >> >> I need to pass a function that returns an IO action to both these >> functions. >> I think my life would be easier if the function signatures were: >> >> 1. withAsync :: MonadIO mIO => mIO a -> (Async a -> mIO b) -> mIO b >> >> 2. from Network.WebSockets >> runClient :: MonadIO mIO => >> -> String -- ^ Host >> -> Int -- ^ Port >> -> String -- ^ Path >> -> (Connection -> mIO a) -- ^ Client application >> -> mIO a >> >> There are many other examples, a notable one are the functions in >> Control.Exception also always expect an IO action. >> I know we have libraries to solve this problem, such as lifted-async, >> lifted-base and the functionality in Control.Monad.Trans.Control. >> But what are the best practices for writing code that uses Monadic >> actions? Should I always generalize my type signatures or just expect >> others to use the libraries when they need to? >> >> Also, to some extent it seems trivial to re-write a library like >> async >> with the generalized signatures I need. I would just need to apply >> 'lift' everywhere. Couldn't the compiler do this for me? ;-) > > It is hard to implement for `withAsync` because it has to pass the > first argument to `forkIO` which doesn't accept `MonadIO`. We need something opposite to `liftIO` to do that. That is why `withAsync` > from `lifted-async` requires `MonadBaseControl IO m` context. It seems that we can just apply my argument transitively then and say that forkIO should have had signature: forkIO :: MonadIO mIO => mIO () -> mIO ThreadId instead of forkIO :: IO () -> IO ThreadId An withAsync itself could have been written with more flexibility. > Semantically, when you want to run `StateT Int IO a` concurrently, you > have to decide how the child state will interact with a state of the > main computation. E.g. you may decide to copy state and discard any > changes made in the child computation. Or you may merge states somehow. > Anyway, it is better to be explicit here. > > Though `withAsync` can be easily generalized to something like > > withAsync :: MonadBaseControl mIO => mIO a -> (Async a -> mIO b) -> mIO b > > It will let you minimize number of lifts is client code. But there is > other way -- don't use monad transformers based on `IO`. Seriously, in > most cases `StateT`, `ExceptT` or other transformers make no sense with > `IO` as a base monad. `IO` is already suitable for state passing and > error handling, no need to add this functionality via transformers. Unfortunately, I am using the pipes library, so I cannot avoid using a monad transformer. Because of the functionality pipes provides, it does make sense for it to be a monad transformer. So, I'm still unclear whether I should always try to generalize my own monadic code (and complicate my type signatures) and whether this could/should be done automatically by the compiler. > Thanks, > Yuras > > Thanks, Dimitri From clintonmead at gmail.com Fri Oct 23 23:01:43 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Sat, 24 Oct 2015 10:01:43 +1100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: Basically you want to force an argument to be associative yes? I don't think there's a way to do that in Haskell, but what you could do is create a datatype: data Associative a b = Associative (a -> b) You could then make "Associative" a Category, or perhaps even an Arrow, so you could combine Associative functions to make new Associative functions. But it would still be up to the user to ensure they only promote actual associative functions to "Associative". On Sat, Oct 24, 2015 at 8:24 AM, Bardur Arantsson wrote: > On 10/23/2015 06:07 PM, Charles Durham wrote: > > I can think of a few properties that folds can honor: > > > > 1. Promises to call f on all data (does not have any guarantees on order) > > "Exhaustive"? > > ... but then that's not really observable in a language like Haskell, > except if you monitor CPU heat. > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Fri Oct 23 23:07:10 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sat, 24 Oct 2015 02:07:10 +0300 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting be automated? In-Reply-To: <562AB3E7.4010504@ucdavis.edu> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <20151023161206.GG16020@weber> <562A8CF4.4010306@ucdavis.edu> <1445632742.2175.16.camel@gmail.com> <562AB3E7.4010504@ucdavis.edu> Message-ID: <1445641630.2175.32.camel@gmail.com> On Fri, 2015-10-23 at 16:25 -0600, Dimitri DeFigueiredo wrote: > On 10/23/15 2:39 PM, Yuras Shumovich wrote: > > On Fri, 2015-10-23 at 13:39 -0600, Dimitri DeFigueiredo wrote: > > > Hello All, > > > > > > I have recently encountered 2 situations where I needed an IO > > > action, > > > but only had a monad stack with IO at the bottom. > > > > > > The two examples were: > > > > > > 1. from Control.Concurrent.Async > > > ?????withAsync :: IO a -> (Async a -> IO b) -> IO b > > > > > > 2. from Network.WebSockets > > > ?????runClient :: String???????-- ^ Host > > > ???????????????-> Int??????????-- ^ Port > > > ???????????????-> String???????-- ^ Path > > > ???????????????-> (Connection -> IO a) -- ^ Client application > > > ???????????????-> IO a > > > > > > I need to pass a function that returns an IO action to both these > > > functions. > > > I think my life would be easier if the function signatures were: > > > > > > 1. withAsync :: MonadIO mIO => mIO a -> (Async a -> mIO b) -> mIO > > > b > > > > > > 2. from Network.WebSockets > > > ?????runClient :: MonadIO mIO => > > > ???????????????-> String???????-- ^ Host > > > ???????????????-> Int??????????-- ^ Port > > > ???????????????-> String???????-- ^ Path > > > ???????????????-> (Connection -> mIO a) -- ^ Client application > > > ???????????????-> mIO a > > > > > > There are many other examples, a notable one are the functions in > > > Control.Exception also always expect an IO action. > > > I know we have libraries to solve this problem, such as lifted- > > > async, > > > lifted-base and the functionality in Control.Monad.Trans.Control. > > > But what are the best practices for writing code that uses > > > Monadic > > > actions? Should I always generalize my type signatures or just > > > expect > > > others to use the libraries when they need to? > > > > > > Also, to some extent it seems trivial to re-write a library like > > > async > > > with the generalized signatures I need. I would just need to > > > apply > > > 'lift' everywhere. Couldn't the compiler do this for me? ;-) > > > > It is hard to implement for `withAsync` because it has to pass the > > first argument to `forkIO` which doesn't accept `MonadIO`. We need > > something opposite to `liftIO` to do that. That is why `withAsync` > > from `lifted-async` requires `MonadBaseControl IO m` context. > It seems that we can just apply my argument transitively then and say > that forkIO should have had signature: > forkIO :: MonadIO mIO => mIO () -> mIO ThreadId > instead of > forkIO :: IO () -> IO ThreadId No, you can't implement it. It doesn't have well-defined semantics, see the section about `StateT` in the previous email. In theory you can do it with `MonadBaseControl`, but it practice it is not in base (strictly speaking, it is event not written in Haskell), and base can't depend on monad-control package. > > An withAsync itself could have been written with more flexibility. > > Semantically, when you want to run `StateT Int IO a` concurrently, > > you > > have to decide how the child state will interact with a state of > > the > > main computation. E.g. you may decide to copy state and discard any > > changes made in the child computation. Or you may merge states > > somehow. > > Anyway, it is better to be explicit here. > > > > Though `withAsync` can be easily generalized to something like > > > > withAsync :: MonadBaseControl mIO => mIO a -> (Async a -> mIO b) -> > > mIO b > > > > It will let you minimize number of lifts is client code. But there > > is > > other way -- don't use monad transformers based on `IO`. Seriously, > > in > > most cases `StateT`, `ExceptT` or other transformers make no sense > > with > > `IO` as a base monad. `IO` is already suitable for state passing > > and > > error handling, no need to add this functionality via transformers. > Unfortunately, I am using the pipes library, so I cannot avoid using > a > monad transformer. Because of the functionality pipes provides, it > does > make sense for it to be a monad transformer. (I'm not a user of pipes myself, so I don't know all the details) AFAIK pipes is a CPS monad. Mixing explicit continuations with a continuation framework is asking for troubles -- it can be done correctly, but it is not trivial. Probably pipes ecosystem contains ready to use building blocks for your task? E.g.?pipes-concurrency looks relevant. > > So, I'm still unclear whether I should always try to generalize my > own > monadic code (and complicate my type signatures) and whether this > could/should be done automatically by the compiler. It could not be done by compiler because compiler doesn't not semantics. For example this post describes difficulties with exception handling in CPS monad. > > > Thanks, > > Yuras > > > > > > Thanks, > > > Dimitri From shumovichy at gmail.com Fri Oct 23 23:09:30 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sat, 24 Oct 2015 02:09:30 +0300 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting be automated? In-Reply-To: <1445641630.2175.32.camel@gmail.com> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <20151023161206.GG16020@weber> <562A8CF4.4010306@ucdavis.edu> <1445632742.2175.16.camel@gmail.com> <562AB3E7.4010504@ucdavis.edu> <1445641630.2175.32.camel@gmail.com> Message-ID: <1445641770.2175.33.camel@gmail.com> On Sat, 2015-10-24 at 02:07 +0300, Yuras Shumovich wrote: > > It could not be done by compiler because compiler doesn't not > semantics. For example this post describes difficulties with > exception > handling in CPS monad. Sorry, forgot to insert the actual link: http://www.yesodweb.com/blog/2014/05/exceptions-cont-monads From ratzes at gmail.com Fri Oct 23 23:11:01 2015 From: ratzes at gmail.com (Charles Durham) Date: Fri, 23 Oct 2015 19:11:01 -0400 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: Yeah, I realize that its probably not conveniently expressible in types or anything. I was more thinking along the lines of how the Monad laws are expressed as a side note in the docs, and not type enforced in Haskell itself. I just thought it was vague to say that a fold takes an associative function instead of indicating what kind of topology a fold honors, as the former is only implying how the fold promises to operate. It would be surprising to me that this hasn't been formalized mathematically in some way. Charlie On Fri, Oct 23, 2015 at 7:01 PM, Clinton Mead wrote: > Basically you want to force an argument to be associative yes? > > I don't think there's a way to do that in Haskell, but what you could do > is create a datatype: > > data Associative a b = Associative (a -> b) > > You could then make "Associative" a Category, or perhaps even an Arrow, so > you could combine Associative functions to make new Associative functions. > > But it would still be up to the user to ensure they only promote actual > associative functions to "Associative". > > On Sat, Oct 24, 2015 at 8:24 AM, Bardur Arantsson > wrote: > >> On 10/23/2015 06:07 PM, Charles Durham wrote: >> > I can think of a few properties that folds can honor: >> > >> > 1. Promises to call f on all data (does not have any guarantees on >> order) >> >> "Exhaustive"? >> >> ... but then that's not really observable in a language like Haskell, >> except if you monitor CPU heat. >> >> Regards, >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Fri Oct 23 23:32:01 2015 From: icfp.publicity at googlemail.com (Lindsey Kuper) Date: Fri, 23 Oct 2015 23:32:01 +0000 Subject: [Haskell-cafe] ICFP 2016 Call for Workshop and Co-located Event Proposals Message-ID: <047d7b6764bcc1dc080522ce0488@google.com>          CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS                             ICFP 2016  21st ACM SIGPLAN International Conference on Functional Programming                      September 18-24, 2016                           Nara, Japan                http://icfpconference.org/icfp2016/ The 21st ACM SIGPLAN International Conference on Functional Programming will be held in Nara, Japan on September 18-24, 2016. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as tutorials) to be affiliated with ICFP 2016 and sponsored by SIGPLAN. These events should be less formal and more focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on September 18 (the day before ICFP) and September 22-24 (the three days after ICFP). ---------------------------------------------------------------------- Submission details  Deadline for submission:     November 21, 2015  Notification of acceptance:  December 20, 2015 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2016 workshop co-chairs (Andres Loeh and Nicolas Wu), via email to     icfp2016-workshops at googlegroups.com by November 21, 2015. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 20, 2015, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2016-files/icfp16-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://www.sigplan.org/Resources/Proposals/Sponsored/ ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2016 organizing committee, together with the members of the SIGPLAN executive committee.  Workshop Co-Chair: Andres Loeh                        (Well-Typed LLP)  Workshop Co-Chair: Nicolas Wu                  (University of Bristol)  General Co-Chair : Jacques Garrigue                (Nagoya University)  General Co-Chair : Gabriele Keller     (University of New South Wales)  Program Chair:     Eijiro Sumii                    (Tohoku University) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Andres Loeh and Nicolas Wu), via email to icfp2016-workshops at googlegroups.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Sat Oct 24 01:48:20 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sat, 24 Oct 2015 08:48:20 +0700 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting be automated? In-Reply-To: <562AB3E7.4010504@ucdavis.edu> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <20151023161206.GG16020@weber> <562A8CF4.4010306@ucdavis.edu> <1445632742.2175.16.camel@gmail.com> <562AB3E7.4010504@ucdavis.edu> Message-ID: On Sat, Oct 24, 2015 at 5:25 AM, Dimitri DeFigueiredo < defigueiredo at ucdavis.edu> wrote: > Unfortunately, I am using the pipes library, so I cannot avoid using a > monad transformer. Because of the functionality pipes provides, it does > make sense for it to be a monad transformer. Hi Dimitri, This is a very interesting topic, thank you for bringing it up. Unfortunately because of the very generalized way it's presented, it's very hard for anyone else aside from Yuras to give it the attention it deserves. Do you have a concrete example with sample code that you could simplify and present instead? E.g. instead of the multiply-stacked monad transformer embedded in 200 lines that you're facing, can you present an example with 2 monadic layers (the base being IO) in say, 20 lines? -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.acerbi at gmail.com Sat Oct 24 08:29:45 2015 From: matteo.acerbi at gmail.com (Matteo Acerbi) Date: Sat, 24 Oct 2015 10:29:45 +0200 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: On Fri, Oct 23, 2015 at 6:07 PM, Charles Durham wrote: > I can think of a few properties that folds can honor: > > 1. Promises to call f on all data (does not have any guarantees on order) > 2. Promises to call f on all data in order (like a left fold) > 3. Promises to call f "associatively" (perhaps can be formalized as an in > order break down of the data into tree structures) > For what concerns traversable functors, traversals enjoy properties of "unitarity" and "linearity" which *might* entail what you are interested in: M. Jaskelioff, O. Rypacek - An Investigation of the Laws of Traversals http://arxiv.org/abs/1202.2919 I have never gone through the details of that very interesting paper: the analysis in section 4 gives some intuition, though. I hope this is related to your questions. Cheers, Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Sat Oct 24 10:56:44 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Sat, 24 Oct 2015 12:56:44 +0200 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: The "unitarity" and "linearity" laws are indeed relevant for Charles's question. But they won't give him his 2. or 3. point. They will exactly entail the property he mentions in his 1. point: that each data element is touched exactly once (whereas all permutations of the order will still be legal). For proof of that, see http://dx.doi.org/10.1145/2503778.2503781, which establishes as fact the relevant conjecture from Jaskelioff & Rypacek's paper. 2015-10-24 10:29 GMT+02:00 Matteo Acerbi : > On Fri, Oct 23, 2015 at 6:07 PM, Charles Durham wrote: > >> I can think of a few properties that folds can honor: >> >> 1. Promises to call f on all data (does not have any guarantees on order) >> 2. Promises to call f on all data in order (like a left fold) >> 3. Promises to call f "associatively" (perhaps can be formalized as an in >> order break down of the data into tree structures) >> > > For what concerns traversable functors, traversals enjoy properties of > "unitarity" and "linearity" which *might* entail what you are interested in: > > M. Jaskelioff, O. Rypacek - An Investigation of the Laws of Traversals > http://arxiv.org/abs/1202.2919 > > I have never gone through the details of that very interesting paper: the > analysis in section 4 gives some intuition, though. > > I hope this is related to your questions. > > Cheers, > Matteo > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sat Oct 24 14:24:02 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 24 Oct 2015 16:24:02 +0200 Subject: [Haskell-cafe] wxHaskell on Windows compilation problems In-Reply-To: <9CDEB451-6D8F-4274-A913-FB627848A143@proclivis.com> References: <9CDEB451-6D8F-4274-A913-FB627848A143@proclivis.com> Message-ID: On Fri, 23 Oct 2015 17:29:03 +0200, Michael Jones wrote: > I?m trying to compile an established wxHaskell application (Ubuntu) on > Windows 7 : > - Grab wxWidgets with git and using MSYS shell compile like: It is better to download 3.0.2 source code, because wxHaskell cannot handle wxWidgets 3.1 yet. Even better, use a wxInstall package[0]; if you want to install wxHaskell from source on your own disk, instead of from Hackage, do not run the Install.bat. > So, I copy the wxWidgets setup.h file from include/msvc/wx to include/wx This file should have been generated by mingw32-make; if you use a wxInstall package, you have the right setup.h file. > The Wiki page is based on platform, not MinGHC. : > Does anyone have any clues how to make wxHaskell and MinGHC work > together? I tried it, the method described at the HaskellWiki page[1] works for MinGHC as well. Regards, Henk-Jan van Tuyl [0] http://sourceforge.net/projects/wxhaskell/files/wxInstall/ [1] https://wiki.haskell.org/WxHaskell/Windows#Installing_the_hard_way -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From mike at proclivis.com Sat Oct 24 17:35:06 2015 From: mike at proclivis.com (Michael Jones) Date: Sat, 24 Oct 2015 11:35:06 -0600 Subject: [Haskell-cafe] wxHaskell on Windows compilation problems In-Reply-To: References: <9CDEB451-6D8F-4274-A913-FB627848A143@proclivis.com> Message-ID: <97082D69-6600-4027-9BAA-943A964B6BAE@proclivis.com> The precompiled version will not support my application due to command line handling issues discussed elsewhere, and a few enhancements to handle very large (100K rows) tables, that are probably not high enough quality to put into the mainline, due to lack of time to make them such. I?ll look at the instructions a bit closer, but at least I know mingw32-make should create the file, so I can focus on that problem first. Thanks, Mike > On Oct 24, 2015, at 8:24 AM, Henk-Jan van Tuyl wrote: > > On Fri, 23 Oct 2015 17:29:03 +0200, Michael Jones > wrote: > >> I?m trying to compile an established wxHaskell application (Ubuntu) on Windows 7 > : >> - Grab wxWidgets with git and using MSYS shell compile like: > > It is better to download 3.0.2 source code, because wxHaskell cannot handle wxWidgets 3.1 yet. Even better, use a wxInstall package[0]; if you want to install wxHaskell from source on your own disk, instead of from Hackage, do not run the Install.bat. > > > >> So, I copy the wxWidgets setup.h file from include/msvc/wx to include/wx > > This file should have been generated by mingw32-make; if you use a wxInstall package, you have the right setup.h file. > >> The Wiki page is based on platform, not MinGHC. > : >> Does anyone have any clues how to make wxHaskell and MinGHC work together? > > I tried it, the method described at the HaskellWiki page[1] works for MinGHC as well. > > Regards, > Henk-Jan van Tuyl > > > [0] http://sourceforge.net/projects/wxhaskell/files/wxInstall/ > [1] https://wiki.haskell.org/WxHaskell/Windows#Installing_the_hard_way > > -- > Folding at home > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://folding.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- From matteo.acerbi at gmail.com Sat Oct 24 17:42:41 2015 From: matteo.acerbi at gmail.com (Matteo Acerbi) Date: Sat, 24 Oct 2015 19:42:41 +0200 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: On Sat, Oct 24, 2015 at 12:56 PM, Janis Voigtl?nder < janis.voigtlaender at gmail.com> wrote: > The "unitarity" and "linearity" laws are indeed relevant for Charles's > question. But they won't give him his 2. or 3. point. They will exactly > entail the property he mentions in his 1. point: that each data element is > touched exactly once (whereas all permutations of the order will still be > legal) > ? > For proof of that, see http://dx.doi.org/10.1145/2503778.2503781, which > establishes as fact the relevant conjecture from Jaskelioff & Rypacek's > paper. > ?Thanks for your clarifying comment, and for the link to this paper: it is very interesting, indeed. In my message I was just trying to point to research that looked relevant, and which seemed to give an answer to at least question 1: for what concerns the other two questions, I have yet to understand them. :-) Question 2 seems to assume the existence of a "default" order, but it seems to me that any such choice would be arbitrary. At least, it seems impossible to capture the property of being "like a left fold" semantically as Charles seemed to be wanting ("I was more thinking along the lines of how the Monad laws are expressed as a side note in the docs"), without actually specifying a reference order of traversal (for example, in the form of an instance of Traversable). For what concerns question 3, I didn't understand the idea of calling a function "associatively". Please let me know if I am missing an obvious interpretation. Best, Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Sat Oct 24 17:44:05 2015 From: mike at proclivis.com (Michael Jones) Date: Sat, 24 Oct 2015 11:44:05 -0600 Subject: [Haskell-cafe] wxHaskell on Windows compilation problems In-Reply-To: References: <9CDEB451-6D8F-4274-A913-FB627848A143@proclivis.com> Message-ID: Can you give me the revision in GIT that is the official 3.0.2 release so I can branch from it and apply my patch. It just convenient to use git to keep track of my tweaks and have access to the log, etc. If there are some compatible commits since then up to some point where it breaks, I would like to know where things break. Mike > On Oct 24, 2015, at 8:24 AM, Henk-Jan van Tuyl wrote: > > On Fri, 23 Oct 2015 17:29:03 +0200, Michael Jones > wrote: > >> I?m trying to compile an established wxHaskell application (Ubuntu) on Windows 7 > : >> - Grab wxWidgets with git and using MSYS shell compile like: > > It is better to download 3.0.2 source code, because wxHaskell cannot handle wxWidgets 3.1 yet. Even better, use a wxInstall package[0]; if you want to install wxHaskell from source on your own disk, instead of from Hackage, do not run the Install.bat. > > > >> So, I copy the wxWidgets setup.h file from include/msvc/wx to include/wx > > This file should have been generated by mingw32-make; if you use a wxInstall package, you have the right setup.h file. > >> The Wiki page is based on platform, not MinGHC. > : >> Does anyone have any clues how to make wxHaskell and MinGHC work together? > > I tried it, the method described at the HaskellWiki page[1] works for MinGHC as well. > > Regards, > Henk-Jan van Tuyl > > > [0] http://sourceforge.net/projects/wxhaskell/files/wxInstall/ > [1] https://wiki.haskell.org/WxHaskell/Windows#Installing_the_hard_way > > -- > Folding at home > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://folding.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- From ky3 at atamo.com Sat Oct 24 17:55:50 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sun, 25 Oct 2015 00:55:50 +0700 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: On Sun, Oct 25, 2015 at 12:42 AM, Matteo Acerbi wrote: > For what concerns question 3, I didn't understand the idea of calling a > function "associatively". > This. Associativity is a property of binary operators. It's not a property of the catamorphism 'calling' on a given binary operator. Also, when Charles writes: "Then it goes on to use f in "thisFold f [0,1,2]" like "f (1 (f 0 2))"" commutativity appears to raise its head. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Sat Oct 24 18:12:11 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Sat, 24 Oct 2015 20:12:11 +0200 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: It has already been established in this thread what Charles meant by 3. He meant that a fold-function that has the property he is after would guarantee that it: a) takes all the content elements from a data structure, say x1,...,xn, b) builds an application tree with the to-be-folded, binary operation f in the internal nodes of a binary tree, whose leafs, read from left to right, form exactly the sequence x1,...,xn, c) evaluates that application tree. Do you agree that what I describe above is a property of a given fold-like function, not of the f handed to that fold-like function? And do you agree that what I describe above is a property that is weaker than (and so, in particular different from) for example the property "this fold-like function is foldl or foldr". 2015-10-24 19:55 GMT+02:00 Kim-Ee Yeoh : > > On Sun, Oct 25, 2015 at 12:42 AM, Matteo Acerbi > wrote: > >> For what concerns question 3, I didn't understand the idea of calling a >> function "associatively". >> > > This. Associativity is a property of binary operators. It's not a property > of the catamorphism 'calling' on a given binary operator. > > Also, when Charles writes: "Then it goes on to use f in "thisFold f > [0,1,2]" like "f (1 (f 0 2))"" > > commutativity appears to raise its head. > > -- Kim-Ee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.acerbi at gmail.com Sat Oct 24 18:23:51 2015 From: matteo.acerbi at gmail.com (Matteo Acerbi) Date: Sat, 24 Oct 2015 20:23:51 +0200 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: On Sat, Oct 24, 2015 at 8:12 PM, Janis Voigtl?nder < janis.voigtlaender at gmail.com> wrote: > It has already been established in this thread what Charles meant by 3. > > He meant that a fold-function that has the property he is after would > guarantee that it: > > a) takes all the content elements from a data structure, say x1,...,xn, > > b) builds an application tree with the to-be-folded, binary operation f in > the internal nodes of a binary tree, whose leafs, read from left to right, > form exactly the sequence x1,...,xn, > > c) evaluates that application tree. > > Do you agree that what I describe above is a property of a given fold-like > function, not of the f handed to that fold-like function? > I might lack some basic knowledge, so thanks for asking. What does it mean to take all the content elements from a data structure? If one has f a = Bool -> a, and a value xs :: f Int xs True = 2 xs False = 3 what are x1 and x2? Best, Matteo PS. I won't be able to read the answer before tomorrow. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Sat Oct 24 18:34:56 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Sat, 24 Oct 2015 20:34:56 +0200 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: > If one has f a = Bool -> a, and a value > > xs :: f Int > xs True = 2 > xs False = 3 > > what are x1 and x2? One answer I could give is: That depends on the definition of the Traversable instance for the (Bool -> a) type constructor. Another answer I could give is: Ask the authors of the Traversable documentation. The first sentence on https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Traversable.html is: "Class of data structures that can be traversed from left to right, ...". So it seems that the authors of that documentation (which I criticize) assume that they can say -- for any given type constructor, so also for your (Bool -> a) example -- what "left" means and what "right" means. 2015-10-24 20:23 GMT+02:00 Matteo Acerbi : > On Sat, Oct 24, 2015 at 8:12 PM, Janis Voigtl?nder < > janis.voigtlaender at gmail.com> wrote: > >> It has already been established in this thread what Charles meant by 3. >> >> He meant that a fold-function that has the property he is after would >> guarantee that it: >> >> a) takes all the content elements from a data structure, say x1,...,xn, >> >> b) builds an application tree with the to-be-folded, binary operation f >> in the internal nodes of a binary tree, whose leafs, read from left to >> right, form exactly the sequence x1,...,xn, >> >> c) evaluates that application tree. >> >> Do you agree that what I describe above is a property of a given >> fold-like function, not of the f handed to that fold-like function? >> > > I might lack some basic knowledge, so thanks for asking. > > What does it mean to take all the content elements from a data structure? > > If one has f a = Bool -> a, and a value > > xs :: f Int > xs True = 2 > xs False = 3 > > what are x1 and x2? > > Best, > Matteo > > PS. I won't be able to read the answer before tomorrow. :-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sat Oct 24 18:58:18 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 24 Oct 2015 20:58:18 +0200 Subject: [Haskell-cafe] wxHaskell on Windows compilation problems In-Reply-To: References: <9CDEB451-6D8F-4274-A913-FB627848A143@proclivis.com> Message-ID: On Sat, 24 Oct 2015 19:44:05 +0200, Michael Jones wrote: > Can you give me the revision in GIT that is the official 3.0.2 release > so I can branch from it and apply my patch. It just convenient to use > git to keep track of my tweaks and have access to the log, etc. If there > are some compatible commits since then up to some point where it breaks, > I would like to know where things break. You can download the wxWidgets 3.0.2 source code from http://www.wxwidgets.org/downloads/ and start a new repository based on that. Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From hjgtuyl at chello.nl Sat Oct 24 19:06:38 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 24 Oct 2015 21:06:38 +0200 Subject: [Haskell-cafe] wxHaskell on Windows compilation problems In-Reply-To: References: <9CDEB451-6D8F-4274-A913-FB627848A143@proclivis.com> Message-ID: On Sat, 24 Oct 2015 20:58:18 +0200, Henk-Jan van Tuyl wrote: > On Sat, 24 Oct 2015 19:44:05 +0200, Michael Jones > wrote: > >> Can you give me the revision in GIT that is the official 3.0.2 release >> so I can branch from it and apply my patch. It just convenient to use >> git to keep track of my tweaks and have access to the log, etc. If >> there are some compatible commits since then up to some point where it >> breaks, I would like to know where things break. > > You can download the wxWidgets 3.0.2 source code from > http://www.wxwidgets.org/downloads/ > and start a new repository based on that. I am sorry, that was not a good answer; I am looking into it. Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From hjgtuyl at chello.nl Sat Oct 24 19:14:15 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 24 Oct 2015 21:14:15 +0200 Subject: [Haskell-cafe] wxHaskell on Windows compilation problems In-Reply-To: References: <9CDEB451-6D8F-4274-A913-FB627848A143@proclivis.com> Message-ID: On Sat, 24 Oct 2015 19:44:05 +0200, Michael Jones wrote: > Can you give me the revision in GIT that is the official 3.0.2 release > so I can branch from it and apply my patch. It just convenient to use > git to keep track of my tweaks and have access to the log, etc. If there > are some compatible commits since then up to some point where it breaks, > I would like to know where things break. > > Mike The 3.0.2 version has tag WX_3_0_2 in the GitHub repository Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From mark.fine at gmail.com Sat Oct 24 19:20:30 2015 From: mark.fine at gmail.com (Mark Fine) Date: Sat, 24 Oct 2015 12:20:30 -0700 Subject: [Haskell-cafe] Google Cloud API In-Reply-To: References: Message-ID: Brendan your work is awesome and enabling us to use Haskell in more and more applications! Thanks! http://brendanhay.nz/gogol-comprehensive-haskell-google-client/ Mark On Wednesday, August 26, 2015, Brendan Hay wrote: > I'd recently generated a limited operation set for personal use. I had no > plans to continue with the entire API surface, but I'll tidy up what I have > and put it on GitHub if others are interested. > > On 27 August 2015 at 00:37, Mark Fine > wrote: > >> Great! >> >> Would love to hear if anyone's pursuing generating the API's from the discovery >> service in a manner >> similar to the excellent amazonka for AWS. >> >> Mark >> >> On Wed, Aug 26, 2015 at 2:57 PM, Tomas Carnecky > > wrote: >> >>> I recently migrated some infrastructure from AWS to Google Cloud and >>> needed a way to upload a file to a storage bucket. For AWS there's an >>> awesome Haskell library (aws), but I couldn't find anything comparable for >>> interacting with the Google Cloud APIs. >>> >>> While it wouldn't be difficult to write a standalone function for that >>> simple task, I decided to package it up in a library. Currently implemented >>> is uploading a ByteString to a bucket and some metadata server queries. >>> That's all I need currently, but I may add a few more selected APIs in the >>> near future (mostly around managing compute instances). >>> >>> Adding support for new APIs should be relatively easy, even without >>> having to change the library itself. All the internals are exposed to users >>> of the library. There is nothing private or hidden. The library gives you >>> access to convenience functions to send HTTP requests. That, coupled with a >>> bit of JSON/aeson parsing, should cover most use cases. >>> >>> http://hackage.haskell.org/package/google-cloud >>> https://github.com/wereHamster/google-cloud#readme >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Oct 24 22:55:18 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 24 Oct 2015 23:55:18 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: <20151024225518.GK16020@weber> On Sat, Oct 24, 2015 at 08:12:11PM +0200, Janis Voigtl?nder wrote: > It has already been established in this thread what Charles meant by 3. > > He meant that a fold-function that has the property he is after would > guarantee that it: > > a) takes all the content elements from a data structure, say x1,...,xn, > > b) builds an application tree with the to-be-folded, binary operation f in > the internal nodes of a binary tree, whose leafs, read from left to right, > form exactly the sequence x1,...,xn, > > c) evaluates that application tree. > > Do you agree that what I describe above is a property of a given fold-like > function, not of the f handed to that fold-like function? > > And do you agree that what I describe above is a property that is weaker > than (and so, in particular different from) for example the property "this > fold-like function is foldl or foldr". I do agree. I would be interested whether you think such a property could differ from my earlier proposed property: "the function factors through `foldl f`", i.e. is `g . foldl f` for some `g`. (Actually when I wrote that I suppose I meant `g . foldl f z` for some `g` and `z`) Tom From ky3 at atamo.com Sun Oct 25 03:19:26 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sun, 25 Oct 2015 10:19:26 +0700 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: On Sun, Oct 25, 2015 at 1:12 AM, Janis Voigtl?nder < janis.voigtlaender at gmail.com> wrote: > It has already been established in this thread what Charles meant by 3. > > He meant that a fold-function that has the property he is after would > guarantee that it: > > a) takes all the content elements from a data structure, say x1,...,xn, > > b) builds an application tree with the to-be-folded, binary operation f in > the internal nodes of a binary tree, whose leafs, read from left to right, > form exactly the sequence x1,...,xn, > > c) evaluates that application tree. > > Isn't this what Charles meant by his 2nd property: > 2. Promises to call f on all data in order (like a left fold) What about his 3rd? Do you agree that what I describe above is a property of a given fold-like > function, not of the f handed to that fold-like function? > Before discussing a property of X, isnt it worth asking what X even means? The folds whose meanings are crystal clear are the arrows out of initial objects in the category of F-algebras. They are crystal clear because they couple as one with the data definition spelled out in full. In the quest for useful generalizations of catamorphisms, that coupling with the data definition continues to be assumed. Observe, for instance: > a) takes all the content elements from a data structure, say x1,...,xn, Does a foliar data structure have a canonical flattening out of its leaves? Are there symmetric canonicalizations? How is one selected over the others? Is the meaning of "all" referentially transparent? That turns out to be a subtle point, as this convo shows: http://haskell.1045720.n5.nabble.com/A-Proposed-Law-for-Foldable-tp5765339.html With the theory of F-algebras, we started with precise notions of data and folds came for free. But data can be overspecified. And also, the folds among swathes of data suggest useful generalizations. So now, a raft of proto-precise and necessarily psychological notions of Foldable waded in, and since then it's been fun playing sorting games with shape blocks and holes to squeeze them into. Fun is good. It's a stage in the journey to knowledge. And do you agree that what I describe above is a property that is weaker > than (and so, in particular different from) for example the property "this > fold-like function is foldl or foldr". > > > > > 2015-10-24 19:55 GMT+02:00 Kim-Ee Yeoh : > >> >> On Sun, Oct 25, 2015 at 12:42 AM, Matteo Acerbi >> wrote: >> >>> For what concerns question 3, I didn't understand the idea of calling a >>> function "associatively". >>> >> >> This. Associativity is a property of binary operators. It's not a >> property of the catamorphism 'calling' on a given binary operator. >> >> Also, when Charles writes: "Then it goes on to use f in "thisFold f >> [0,1,2]" like "f (1 (f 0 2))"" >> >> commutativity appears to raise its head. >> >> -- Kim-Ee >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Sun Oct 25 04:08:06 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sat, 24 Oct 2015 21:08:06 -0700 Subject: [Haskell-cafe] Projectional editing: Separating a program's AST from its presentation Message-ID: These ideas were touched on in a previous thread [1]. Our work would be easier if, as data, we separated a program's AST from its layout. If, for instance, the order in which a library's functions are presented on the page were stored as a "projection", separate from the AST that defined those functions, then one could reorder the functions without obscuring the history of changes to anything that was "moved". I assume I am not alone in making a lot of edits aimed solely at allowing me to read or traverse the code faster? Those within-function changes of presentation, like across-function changes of order, obscure the record of functional (as opposed to cosmetic) changes. They don't have to. Moreover, if projections and the AST were separate data, one could use contradictory hierarchiies|projections|layouts for the same data. One projection might group functions by their common purpose (an "is-tree"), while another grouped them by priority to the reader-rewriter (a "do-tree"). Given current technology, text folding does allow us to impose a hierarchy on a text document (even a Haskell document! you just need to indent the code relative to the comments that define the hierarchy). However, if the code is stored as text, then only one hierarchy is possible. In particular one is presently forced to choose between an "is-tree" and a "do-tree". https://groups.google.com/forum/#!msg/haskell-cafe/d8h8J8VxZxo/BNlKUjWeAgAJ -- Jeffrey Benjamin Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Sun Oct 25 05:58:23 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Sun, 25 Oct 2015 06:58:23 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: <20151024225518.GK16020@weber> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <20151024225518.GK16020@weber> Message-ID: I don't think I see what you are getting at, Tom. Let's consider the special case of non-empty lists. One fold-like function that has the property I think Charles meant by 3., would be one that works as follows: foldBalanced :: (a -> a -> a) -> [a] -> a foldBalanced f [x] = x foldBalanced f [x,y] = f x y foldBalanced f [x,y,z] = f x (f y z) foldBalanced f [x,y,z,u] = f (f x y) (f z u) ... -- I hope you can see the pattern (building f-application trees that are as balanced as possible) I don't see how this function can be written as g . foldl f z for some g and z. 2015-10-25 0:55 GMT+02:00 Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>: > On Sat, Oct 24, 2015 at 08:12:11PM +0200, Janis Voigtl?nder wrote: > > It has already been established in this thread what Charles meant by 3. > > > > He meant that a fold-function that has the property he is after would > > guarantee that it: > > > > a) takes all the content elements from a data structure, say x1,...,xn, > > > > b) builds an application tree with the to-be-folded, binary operation f > in > > the internal nodes of a binary tree, whose leafs, read from left to > right, > > form exactly the sequence x1,...,xn, > > > > c) evaluates that application tree. > > > > Do you agree that what I describe above is a property of a given > fold-like > > function, not of the f handed to that fold-like function? > > > > And do you agree that what I describe above is a property that is weaker > > than (and so, in particular different from) for example the property > "this > > fold-like function is foldl or foldr". > > I do agree. I would be interested whether you think such a property could > differ from my earlier proposed property: > > "the function factors through `foldl f`", i.e. is `g . foldl f` for > some `g`. > > (Actually when I wrote that I suppose I meant `g . foldl f z` for some `g` > and `z`) > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Sun Oct 25 06:17:17 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Sun, 25 Oct 2015 07:17:17 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: Kim-Ee, I think you are overcomplicating things (and on the specific question of 2. vs. 3.: no, what I described was specifically meant to capture Charles's 3., not 2. point; note that my "application trees" could be balanced in any way, rather than being completely left-nested). In fact, the discussion of "arbitrary data structures" (in this thread in general) distracts a lot from the properties under consideration, and from even first finding out whether they are properties of foldLike or of f in foldLike f. So, let's specialize. Let's consider only the case of non-empty lists. Then, candidate functions for "foldlike functions" will be functions of this type: foldLike : (a -> a -> a) -> [a] -> a Here are some candidates (I give only an equation for four element lists in each case, but I assume everyone has enough imagination to see how these could be extended to other lists in an intended way): foldLike1 f [a,b,c,d] = [] -- throws away stuff foldLike2 f [a,b,c,d] = f a (f b (f c d)) -- we have all ancountered this one foldLike3 f [a,b,c,d] = f (f (f a b) c) d -- also looks familiar foldLike4 f [a,b,c,d] = f (f a b) (f c d) -- that's a "new" one, but looks good foldLike5 f [a,b,c,d] = f a a -- probably not a very popular one foldLike6 f [a,b,c,d] = f (f c a) (f b d) -- a reasonable one, for example there's a Traversable instance that leads to this one; but still, it's not one that Charles would like, I think So now we can ask which of these satisfy Charles's 1., 2., 3. points. Can't we? There was: > 1. Promises to call f on all data (does not have any guarantees on order) This is satisfied by foldLike2, foldLike3, foldLike4, and foldLike6, but not by the others. > 2. Promises to call f on all data in order (like a left fold) This is satisfied by foldLike3, but not by the others. > 3. Promises to call f "associatively" (perhaps can be formalized as an in order break down of the data into tree structures) This is satisfied by foldLike2, foldLike3, and foldLike4, but not by the others. Since I am able to tell, for a given foldLike candidate, whether or not it satisfies 3. (for example, I could specifically see that foldLike6 does not satisfy 3., while it does satisfy 1.), it cannot be maintained that 3. has no meaning. Note: Nothing in the above makes any assumptions about f. Whether or not f is an associative function is irrelevant for what is asked here. 2015-10-25 4:19 GMT+01:00 Kim-Ee Yeoh : > On Sun, Oct 25, 2015 at 1:12 AM, Janis Voigtl?nder < > janis.voigtlaender at gmail.com> wrote: > >> It has already been established in this thread what Charles meant by 3. >> >> He meant that a fold-function that has the property he is after would >> guarantee that it: >> >> a) takes all the content elements from a data structure, say x1,...,xn, >> >> b) builds an application tree with the to-be-folded, binary operation f >> in the internal nodes of a binary tree, whose leafs, read from left to >> right, form exactly the sequence x1,...,xn, >> >> c) evaluates that application tree. >> >> > Isn't this what Charles meant by his 2nd property: > > > 2. Promises to call f on all data in order (like a left fold) > > What about his 3rd? > > Do you agree that what I describe above is a property of a given fold-like >> function, not of the f handed to that fold-like function? >> > > Before discussing a property of X, isnt it worth asking what X even means? > > The folds whose meanings are crystal clear are the arrows out of initial > objects in the category of F-algebras. > > They are crystal clear because they couple as one with the data definition > spelled out in full. > > In the quest for useful generalizations of catamorphisms, that coupling > with the data definition continues to be assumed. > > Observe, for instance: > > > a) takes all the content elements from a data structure, say x1,...,xn, > > Does a foliar data structure have a canonical flattening out of its > leaves? Are there symmetric canonicalizations? How is one selected over the > others? > > Is the meaning of "all" referentially transparent? That turns out to be a > subtle point, as this convo shows: > > > http://haskell.1045720.n5.nabble.com/A-Proposed-Law-for-Foldable-tp5765339.html > > With the theory of F-algebras, we started with precise notions of data and > folds came for free. > > But data can be overspecified. And also, the folds among swathes of data > suggest useful generalizations. > > So now, a raft of proto-precise and necessarily psychological notions of > Foldable waded in, and since then it's been fun playing sorting games with > shape blocks and holes to squeeze them into. > > Fun is good. It's a stage in the journey to knowledge. > > > And do you agree that what I describe above is a property that is weaker >> than (and so, in particular different from) for example the property "this >> fold-like function is foldl or foldr". >> > > > >> >> >> >> 2015-10-24 19:55 GMT+02:00 Kim-Ee Yeoh : >> >>> >>> On Sun, Oct 25, 2015 at 12:42 AM, Matteo Acerbi >> > wrote: >>> >>>> For what concerns question 3, I didn't understand the idea of calling a >>>> function "associatively". >>>> >>> >>> This. Associativity is a property of binary operators. It's not a >>> property of the catamorphism 'calling' on a given binary operator. >>> >>> Also, when Charles writes: "Then it goes on to use f in "thisFold f >>> [0,1,2]" like "f (1 (f 0 2))"" >>> >>> commutativity appears to raise its head. >>> >>> -- Kim-Ee >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Oct 25 08:33:09 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 25 Oct 2015 08:33:09 +0000 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023154903.GF16020@weber> <20151024225518.GK16020@weber> Message-ID: <20151025083309.GL16020@weber> On Sun, Oct 25, 2015 at 06:58:23AM +0100, Janis Voigtl?nder wrote: > I don't think I see what you are getting at, Tom. Let's consider the > special case of non-empty lists. One fold-like function that has the > property I think Charles meant by 3., would be one that works as follows: > > foldBalanced :: (a -> a -> a) -> [a] -> a > foldBalanced f [x] = x > foldBalanced f [x,y] = f x y > foldBalanced f [x,y,z] = f x (f y z) > foldBalanced f [x,y,z,u] = f (f x y) (f z u) > ... -- I hope you can see the pattern (building f-application trees that > are as balanced as possible) > > I don't see how this function can be written as g . foldl f z for some g > and z. Ah, thank you Janis. I think you are clarifying for me the meaning of Chris's original question: Is there a name for a fold that promises to call a function such that only an associative function will always return the same result. Or in other words, it has the property that it promises to call a function "associatively" on a set of data? So is the property that the function (h, say) satifises `h f = g . foldl f z` for all associative `f`? Tom From martin.drautzburg at web.de Sun Oct 25 08:36:17 2015 From: martin.drautzburg at web.de (martin) Date: Sun, 25 Oct 2015 09:36:17 +0100 Subject: [Haskell-cafe] Avoiding Dependency loops Message-ID: <562C9481.6090700@web.de> Hello all, I just split up a program I'm working on into several source files and ran into the following difficulty: module Process implements Process which has a field Runner. Runner is a basically a function which alters a 'System' state. So Process needs Runner, Runner needs System and thus Process needs System. module System implements among others a collection of Processes (because Processes can alter their states). So System needs Process. Eh voila, I have a loop. What I did was to leave the type of the Runner unspecified in Process, i.e. I now have (Process r) where r is the type of the Runner. Thus Process no longer needs to know about System. This does work, but it feels strange and I'm a bit worried that this is an indication for a design flaw, but I cannot see it. From dct25-561bs at mythic-beasts.com Sun Oct 25 09:01:57 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Sun, 25 Oct 2015 09:01:57 +0000 Subject: [Haskell-cafe] Avoiding Dependency loops In-Reply-To: <562C9481.6090700@web.de> References: <562C9481.6090700@web.de> Message-ID: Hi Martin, Seems reasonable to me. It's a common dependency-breaking technique, akin to introducing an interface in OO-land. Did you also introduce a typeclass constraint on the type 'r' so you can call some methods on it too? If not then Process doesn't really depend on System at all. Another thing to look for is that perhaps your System module splits into two bits, one low-level (defining types and so on) and one high-level (making use of everything in System and Process and Runner) and the two bits live at opposite ends of the dependency graph. I've found that quite a common situation to be in when splitting things up into modules too. HTH, David On 25 October 2015 at 08:36, martin wrote: > Hello all, > > I just split up a program I'm working on into several source files and ran > into the following difficulty: > > module Process implements Process which has a field Runner. Runner is a > basically a function which alters a 'System' > state. So Process needs Runner, Runner needs System and thus Process needs > System. > > module System implements among others a collection of Processes (because > Processes can alter their states). So System > needs Process. > > Eh voila, I have a loop. > > What I did was to leave the type of the Runner unspecified in Process, > i.e. I now have (Process r) where r is the type > of the Runner. Thus Process no longer needs to know about System. > > This does work, but it feels strange and I'm a bit worried that this is an > indication for a design flaw, but I cannot > see it. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Sun Oct 25 09:06:00 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Sun, 25 Oct 2015 10:06:00 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: <20151025083309.GL16020@weber> References: <20151023154903.GF16020@weber> <20151024225518.GK16020@weber> <20151025083309.GL16020@weber> Message-ID: > Chris's original question: > > Is there a name for a fold that promises to call a function such that only > an associative function will always return the same result. Or in other > words, it has the property that it promises to call a function > "associatively" on a set of data? > > So is the property that the function (h, say) satifises `h f = g . foldl f z` > for all associative `f`? That makes a lot of sense, Tom, as a property of h to satisfy, while quantifying over associative f inside that property. (Instead of as an equation-definition for h in terms of foldl.) I now wonder why any g other than the identity function should be necessary, though. And for the type of non-empty lists, one should also be able to get rid of the z? So, for the special case of non-empty lists, how about expressing the desired property as follows: "The function h must satisfy: for all associative f and all lists xs, it holds that h f xs = foldl1 f xs." Chris's original question would then be whether there is a name for that property. And how to generalize the property to other types than non-empty lists (for example, ones for which it is not clear what "left" and "right" mean) would be a separate concern. 2015-10-25 9:33 GMT+01:00 Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>: > On Sun, Oct 25, 2015 at 06:58:23AM +0100, Janis Voigtl?nder wrote: > > I don't think I see what you are getting at, Tom. Let's consider the > > special case of non-empty lists. One fold-like function that has the > > property I think Charles meant by 3., would be one that works as follows: > > > > foldBalanced :: (a -> a -> a) -> [a] -> a > > foldBalanced f [x] = x > > foldBalanced f [x,y] = f x y > > foldBalanced f [x,y,z] = f x (f y z) > > foldBalanced f [x,y,z,u] = f (f x y) (f z u) > > ... -- I hope you can see the pattern (building f-application trees that > > are as balanced as possible) > > > > I don't see how this function can be written as g . foldl f z for some g > > and z. > > Ah, thank you Janis. I think you are clarifying for me the meaning of > Chris's original question: > > Is there a name for a fold that promises to call a function such that > only > an associative function will always return the same result. Or in > other > words, it has the property that it promises to call a function > "associatively" on a set of data? > > So is the property that the function (h, say) satifises `h f = g . foldl f > z` > for all associative `f`? > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Oct 25 09:19:15 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 25 Oct 2015 09:19:15 +0000 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151024225518.GK16020@weber> <20151025083309.GL16020@weber> Message-ID: <20151025091915.GD21969@weber> On Sun, Oct 25, 2015 at 10:06:00AM +0100, Janis Voigtl?nder wrote: > > Chris's original question: > > > > Is there a name for a fold that promises to call a function such that only > > an associative function will always return the same result. Or in other > > words, it has the property that it promises to call a function > > "associatively" on a set of data? > > > > So is the property that the function (h, say) satifises `h f = g . foldl > f z` > > for all associative `f`? > > That makes a lot of sense, Tom, as a property of h to satisfy, while > quantifying over associative f inside that property. (Instead of as an > equation-definition for h in terms of foldl.) > > I now wonder why any g other than the identity function should be > necessary, though. And for the type of non-empty lists, one should also be > able to get rid of the z? Chris said "Is there a name for a fold", which I originally misunderstood as "Is there a name for a function". I'm not quite sure how to define "fold", but if it agrees with your definition of "fold" then your characterization below should be fine. > So, for the special case of non-empty lists, how about expressing the > desired property as follows: "The function h must satisfy: for all > associative f and all lists xs, it holds that h f xs = foldl1 f xs." Tom From matteo.acerbi at gmail.com Sun Oct 25 09:09:21 2015 From: matteo.acerbi at gmail.com (Matteo Acerbi) Date: Sun, 25 Oct 2015 10:09:21 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: <87bnbnclyr.fsf@gmail.com> Janis Voigtl?nder writes: > One answer I could give is: That depends on the definition of the > Traversable instance for the (Bool -> a) type constructor. > > Another answer I could give is: Ask the authors of the Traversable > documentation. [..] Since Charles had not mentioned Traversable in his messages, I still find the original question 2 to be ambiguous. If one has a Traversable instance, then he can say what being left fold-like means for a function. As far as I understand, however, this should be equivalent to the property of being extensionally equal to the foldl1 of the Foldable superclass, provided instances follow the laws. Please, again, correct me if I am wrong. I want to remark that mine is not criticism towards Charles's message: on the contrary, I think that starting a discussion on not completely specified ideas can be very beneficial for everyone, as several people at once will make some effort to get a clearer understanding, sharing their points of view. Thanks for taking the time to explain your interpretation. Best, Matteo From janis.voigtlaender at gmail.com Sun Oct 25 10:09:26 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Sun, 25 Oct 2015 11:09:26 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: <87bnbnclyr.fsf@gmail.com> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <87bnbnclyr.fsf@gmail.com> Message-ID: My messages this morning have decoupled the discussion from Traversable, by specialising to one container type for which left-to-right is predefined. In my mind, that gets to the heart of what Charles was after, namely the "calling in an associative manner" thing, which is independent of the question "how do we know right from left in the first place". Do the considerations then make sense to you as well? 2015-10-25 10:09 GMT+01:00 Matteo Acerbi : > > Janis Voigtl?nder writes: > > > One answer I could give is: That depends on the definition of the > > Traversable instance for the (Bool -> a) type constructor. > > > > Another answer I could give is: Ask the authors of the Traversable > > documentation. [..] > > Since Charles had not mentioned Traversable in his messages, I still > find the original question 2 to be ambiguous. > > If one has a Traversable instance, then he can say what being left > fold-like means for a function. As far as I understand, however, this > should be equivalent to the property of being extensionally equal to the > foldl1 of the Foldable superclass, provided instances follow the laws. > > Please, again, correct me if I am wrong. > > I want to remark that mine is not criticism towards Charles's message: > on the contrary, I think that starting a discussion on not completely > specified ideas can be very beneficial for everyone, as several people > at once will make some effort to get a clearer understanding, sharing > their points of view. > > Thanks for taking the time to explain your interpretation. > > Best, > Matteo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.drautzburg at web.de Sun Oct 25 10:35:02 2015 From: martin.drautzburg at web.de (martin) Date: Sun, 25 Oct 2015 11:35:02 +0100 Subject: [Haskell-cafe] Avoiding Dependency loops In-Reply-To: References: <562C9481.6090700@web.de> Message-ID: <562CB056.5030808@web.de> Thanks David. Maybe I better show the actual code; * module Process * data Process r = Prc { prcSources :: [Port], prcSinks :: [Port], prcRunner :: r, prcId :: PrcId } deriving (Show) * module System * data System = Sys { sysProcesses :: ProcessDb, sysItems :: ItemDb } deriving Show type ProcessDb = M.Map Int (Process PrcRunner) data PrcRunner = PrcRun (Timed Event -> Process PrcRunner -> State System EventQu) I understand your reasoning about the type contraints, but I cannot see what I should actually do. AS for your second suggestion of splitting things up even more, I don't think this will help, because the loop is already on type level. My feeling is that I got caught in OO thinking too much and the runner should not be part of the process at all. But again I cannot see how to fix it. The thing is, Process itself does not really have any business with its Runner. There is no function which actually does anyting with it. The Process type just provides a home for the runner. Thinking aloud: On top of the whole thing sits a simulation, which among others changes the state of the System. This includes changes to the Processes. I want to capture this by altering the Runner associated with a particular Process. Wouldn't this suggest that System needs an association between Process and Runner rather than making Runner a field of Process? Am 10/25/2015 um 10:01 AM schrieb David Turner: > Hi Martin, > > Seems reasonable to me. It's a common dependency-breaking technique, akin to introducing an interface in OO-land. Did > you also introduce a typeclass constraint on the type 'r' so you can call some methods on it too? If not then Process > doesn't really depend on System at all. > > Another thing to look for is that perhaps your System module splits into two bits, one low-level (defining types and so > on) and one high-level (making use of everything in System and Process and Runner) and the two bits live at opposite > ends of the dependency graph. I've found that quite a common situation to be in when splitting things up into modules too. > > HTH, > > David > > > > > On 25 October 2015 at 08:36, martin > wrote: > > Hello all, > > I just split up a program I'm working on into several source files and ran into the following difficulty: > > module Process implements Process which has a field Runner. Runner is a basically a function which alters a 'System' > state. So Process needs Runner, Runner needs System and thus Process needs System. > > module System implements among others a collection of Processes (because Processes can alter their states). So System > needs Process. > > Eh voila, I have a loop. > > What I did was to leave the type of the Runner unspecified in Process, i.e. I now have (Process r) where r is the type > of the Runner. Thus Process no longer needs to know about System. > > This does work, but it feels strange and I'm a bit worried that this is an indication for a design flaw, but I cannot > see it. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > From dct25-561bs at mythic-beasts.com Sun Oct 25 11:03:04 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Sun, 25 Oct 2015 11:03:04 +0000 Subject: [Haskell-cafe] Avoiding Dependency loops In-Reply-To: <562CB056.5030808@web.de> References: <562C9481.6090700@web.de> <562CB056.5030808@web.de> Message-ID: Hi Martin, Tempted to agree with you that Process has no business knowing about its runner - even in OO-land this would seem a bit unexpected to me. On the other hand, if PrcRunner is a function that takes a Process as its second argument, does a Process's prcRunner field ever run a Process other than the one that owns it? If not, it strikes me that partially applying it on construction be better: data PrcRunner = PrcRun (Timed Event -> State System EventQu)? Or you could decide to keep your types mutually recursive and define them all in their own .Types module and then your various implementation modules can depend on that without introducing any cycles. Basically, there's lots of options depending on what you're trying to do! Drawing the boundaries around modules is definitely an art and not a science - there's a good (albeit OO-centric) article http://martinfowler.com/articles/refactoring-dependencies.html where Fowler says* "The hardest part of splitting a program into modules is just deciding on what the module boundaries should be. There's no easy guidelines to follow for this, indeed a major theme of my life's work is to try and understand what good module boundaries will look like." *which you may find interesting. Cheers, On 25 October 2015 at 10:35, martin wrote: > Thanks David. > > Maybe I better show the actual code; > > * module Process * > > data Process r = Prc { > prcSources :: [Port], > prcSinks :: [Port], > prcRunner :: r, > prcId :: PrcId > } deriving (Show) > > > * module System * > > data System = Sys { > sysProcesses :: ProcessDb, > sysItems :: ItemDb > } deriving Show > > type ProcessDb = M.Map Int (Process PrcRunner) > > data PrcRunner = PrcRun (Timed Event -> Process PrcRunner -> State System > EventQu) > > > I understand your reasoning about the type contraints, but I cannot see > what I should actually do. > > AS for your second suggestion of splitting things up even more, I don't > think this will help, because the loop is > already on type level. > > My feeling is that I got caught in OO thinking too much and the runner > should not be part of the process at all. But > again I cannot see how to fix it. The thing is, Process itself does not > really have any business with its Runner. There > is no function which actually does anyting with it. The Process type just > provides a home for the runner. > > Thinking aloud: > > On top of the whole thing sits a simulation, which among others changes > the state of the System. This includes changes > to the Processes. I want to capture this by altering the Runner associated > with a particular Process. Wouldn't this > suggest that System needs an association between Process and Runner rather > than making Runner a field of Process? > > > Am 10/25/2015 um 10:01 AM schrieb David Turner: > > Hi Martin, > > > > Seems reasonable to me. It's a common dependency-breaking technique, > akin to introducing an interface in OO-land. Did > > you also introduce a typeclass constraint on the type 'r' so you can > call some methods on it too? If not then Process > > doesn't really depend on System at all. > > > > Another thing to look for is that perhaps your System module splits into > two bits, one low-level (defining types and so > > on) and one high-level (making use of everything in System and Process > and Runner) and the two bits live at opposite > > ends of the dependency graph. I've found that quite a common situation > to be in when splitting things up into modules too. > > > > HTH, > > > > David > > > > > > > > > > On 25 October 2015 at 08:36, martin martin.drautzburg at web.de>> wrote: > > > > Hello all, > > > > I just split up a program I'm working on into several source files > and ran into the following difficulty: > > > > module Process implements Process which has a field Runner. Runner > is a basically a function which alters a 'System' > > state. So Process needs Runner, Runner needs System and thus Process > needs System. > > > > module System implements among others a collection of Processes > (because Processes can alter their states). So System > > needs Process. > > > > Eh voila, I have a loop. > > > > What I did was to leave the type of the Runner unspecified in > Process, i.e. I now have (Process r) where r is the type > > of the Runner. Thus Process no longer needs to know about System. > > > > This does work, but it feels strange and I'm a bit worried that this > is an indication for a design flaw, but I cannot > > see it. > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.drautzburg at web.de Sun Oct 25 11:29:46 2015 From: martin.drautzburg at web.de (martin) Date: Sun, 25 Oct 2015 12:29:46 +0100 Subject: [Haskell-cafe] Avoiding Dependency loops In-Reply-To: References: <562C9481.6090700@web.de> <562CB056.5030808@web.de> Message-ID: <562CBD2A.7060908@web.de> Am 10/25/2015 um 12:03 PM schrieb David Turner: > Hi Martin, > > Tempted to agree with you that Process has no business knowing about its runner - even in OO-land this would seem a bit > unexpected to me. On the other hand, if PrcRunner is a function that takes a Process as its second argument, does a > Process's prcRunner field ever run a Process other than the one that owns it? If not, it strikes me that partially > applying it on construction be better: data PrcRunner = PrcRun (Timed Event -> State System EventQu)? This was where I was caught in OO-land. You are absolutely right and your answer helps a lot. > Or you could > decide to keep your types mutually recursive and define them all in their own .Types module and then your various > implementation modules can depend on that without introducing any cycles. > > Basically, there's lots of options depending on what you're trying to do! Drawing the boundaries around modules is > definitely an art and not a science - there's a good (albeit OO-centric) article > http://martinfowler.com/articles/refactoring-dependencies.html where Fowler says/"The hardest part of splitting a > program into modules is just deciding on what the module boundaries should be. There's no easy guidelines to follow for > this, indeed a major theme of my life's work is to try and understand what good module boundaries will look > like." /which you may find interesting. > > Cheers, > > > On 25 October 2015 at 10:35, martin > wrote: > > Thanks David. > > Maybe I better show the actual code; > > * module Process * > > data Process r = Prc { > prcSources :: [Port], > prcSinks :: [Port], > prcRunner :: r, > prcId :: PrcId > } deriving (Show) > > > * module System * > > data System = Sys { > sysProcesses :: ProcessDb, > sysItems :: ItemDb > } deriving Show > > type ProcessDb = M.Map Int (Process PrcRunner) > > data PrcRunner = PrcRun (Timed Event -> Process PrcRunner -> State System EventQu) > > > I understand your reasoning about the type contraints, but I cannot see what I should actually do. > > AS for your second suggestion of splitting things up even more, I don't think this will help, because the loop is > already on type level. > > My feeling is that I got caught in OO thinking too much and the runner should not be part of the process at all. But > again I cannot see how to fix it. The thing is, Process itself does not really have any business with its Runner. There > is no function which actually does anyting with it. The Process type just provides a home for the runner. > > Thinking aloud: > > On top of the whole thing sits a simulation, which among others changes the state of the System. This includes changes > to the Processes. I want to capture this by altering the Runner associated with a particular Process. Wouldn't this > suggest that System needs an association between Process and Runner rather than making Runner a field of Process? > > > Am 10/25/2015 um 10:01 AM schrieb David Turner: > > Hi Martin, > > > > Seems reasonable to me. It's a common dependency-breaking technique, akin to introducing an interface in OO-land. Did > > you also introduce a typeclass constraint on the type 'r' so you can call some methods on it too? If not then Process > > doesn't really depend on System at all. > > > > Another thing to look for is that perhaps your System module splits into two bits, one low-level (defining types and so > > on) and one high-level (making use of everything in System and Process and Runner) and the two bits live at opposite > > ends of the dependency graph. I've found that quite a common situation to be in when splitting things up into modules too. > > > > HTH, > > > > David > > > > > > > > > > On 25 October 2015 at 08:36, martin >> wrote: > > > > Hello all, > > > > I just split up a program I'm working on into several source files and ran into the following difficulty: > > > > module Process implements Process which has a field Runner. Runner is a basically a function which alters a 'System' > > state. So Process needs Runner, Runner needs System and thus Process needs System. > > > > module System implements among others a collection of Processes (because Processes can alter their states). So System > > needs Process. > > > > Eh voila, I have a loop. > > > > What I did was to leave the type of the Runner unspecified in Process, i.e. I now have (Process r) where r is the type > > of the Runner. Thus Process no longer needs to know about System. > > > > This does work, but it feels strange and I'm a bit worried that this is an indication for a design flaw, but I cannot > > see it. > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > > From matteo.acerbi at gmail.com Sun Oct 25 12:03:04 2015 From: matteo.acerbi at gmail.com (Matteo Acerbi) Date: Sun, 25 Oct 2015 13:03:04 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <87bnbnclyr.fsf@gmail.com> Message-ID: <878u6rcfkc.fsf@gmail.com> Janis Voigtl?nder writes: > My messages this morning have decoupled the discussion from Traversable, by > specialising to one container type for which left-to-right is predefined. > > In my mind, that gets to the heart of what Charles was after, namely the > "calling in an associative manner" thing, which is independent of the > question "how do we know right from left in the first place". Do the > considerations then make sense to you as well? Yes, they do. The examples related to non-empty lists were most clarifying. I agree that the interesting part was question 3, concerning which I think I have now understood your interpretation. As an exercise, I'll try to express it in my own words. Let's restrict to non-empty lists. I'll use these definitions: data NonEmptyList a = Last a | Cons a (NonEmptyList a) -- or the one from package semigroups data Tree a = Leaf a | Node (Tree a) (Tree a) foldTree :: (a -> a -> a) -> Tree a -> a foldTree f (Leaf a) = a foldTree f (Node x y) = f (foldTree f x) (foldTree f y) (<>) :: NonEmptyList a -> NonEmptyList a -> NonEmptyList a Last a <> ys = Cons a ys Cons a xs <> ys = Cons a (xs <> ys) toNonEmptyList :: Tree a -> NonEmptyList a toNonEmptyList (Leaf a) = Last a toNonEmptyList (Node x y) = toNonEmptyList x <> toNonEmptyList y Given the above, a fold h which calls the first argument "in an associative manner" is a function of type h :: (a -> a -> a) -> NonEmptyList a -> a which can be equivalently expressed in terms of another function h' :: NonEmptyList a -> Tree a such that toNonEmptyList . h' = id as h f = foldTree f . h' . h' is allowed to build an application tree whose shape can be a function of the input list, but its leaves, considered in left-to-right order, must contain precisely the input sequence. Is this correct? Best, Matteo From Burkhard.Groh at gmx.de Sun Oct 25 14:17:29 2015 From: Burkhard.Groh at gmx.de (Burkhard Groh) Date: Sun, 25 Oct 2015 16:17:29 +0200 Subject: [Haskell-cafe] Glib-0.13.2.1 build failure: multiple definition of `__debugbreak' (ghc-7.11.20151024) Message-ID: <562CE479.6080502@gmx.de> In my latest attempt to finally build the gtk3 package with ghc-head 'ghc-master' (7.11.20151024) for a current project under windows x64 using the latest msys2-version and its supplied gtk3 libraries (mingw64/mingw-w64-x86_64-gtk3 3.18.2-1) I encountered this cryptical (linking) error. (See complete log for command './Setup build -v3' attached) I should add that I'm rather a beginner with regards to the Haskell language and its package distribution system cabal. Thus all thoughts, ideas and suggestions how to fix this problem are welcome. Best regards Burkhard complete building response in msys2-shell using the mingw64 script: $ ./Setup build -v3 Component build order: library creating dist\build creating dist\build\autogen Building glib-0.13.2.1... Environment: [("","C:=C:\\Windows\\System32"),("ACLOCAL_PATH","C:\\MSYS2\\mingw64\\share\\aclocal;C:\\MSYS2\\usr\\share\\aclocal"),("ALLUSERSPROFILE","C:\\ProgramData"),("APPDATA","C:\\Users\\PC-08\\AppData\\Roaming"),("CHECKDEF","C:\\Applications\\wingx\\bin"),("COMMONPROGRAMFILES","C:\\Program Files\\Common Files"),("COMMONPROGRAMFILES(X86)","C:\\Program Files (x86)\\Common Files"),("COMMONPROGRAMW6432","C:\\Program Files\\Common Files"),("COMPUTERNAME","PC-08"),("COMSPEC","C:\\Windows\\system32\\cmd.exe"),("FP_NO_HOST_CHECK","NO"),("HOME","C:\\MSYS2\\home\\Ms PC-08"),("HOMEDRIVE","C:"),("HOMEPATH","\\Users\\PC-08"),("HOSTNAME","PC-08"),("INFOPATH","C:\\MSYS2\\usr\\local\\info;C:\\MSYS2\\usr\\share\\info;C:\\MSYS2\\usr\\info;C:\\MSYS2\\share\\info"),("LANG","de_DE.UTF-8"),("LOCALAPPDATA","C:\\Users\\PC-08\\AppData\\Local"),("LOGONSERVER","\\\\PC-08"),("MANPATH","C:\\MSYS2\\mingw64\\share\\man;C:\\MSYS2\\usr\\local\\man;C:\\MSYS2\\usr\\share\\man;C:\\MSYS2\\usr\\man;C:\\MSYS2\\share\\man"),("MSYSCON","mintty.exe"),("MSYSTEM","MINGW64"),("NUMBER_OF_PROCESSORS","4"),("OLDPWD","C:/MSYS2/home/Ms PC-08/cabal"),("ORTEPDIR","C:\\Applications\\ortep3"),("OS","Windows_NT"),("PATH","C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Haskell\\ghc-7.11.20151024\\bin;C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin;C:\\MSYS2\\mingw64\\bin;C:\\MSYS2\\usr\\local\\bin;C:\\MSYS2\\usr\\bin;C:\\MSYS2\\usr\\bin;C:\\Program Files (x86)\\CambridgeSoft\\ChemOffice2015\\ChemScript\\Lib;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0;C:\\Program Files (x86)\\ATI Technologies\\ATI.ACE\\Core-Static;C:\\Program Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common Files\\Intel\\WirelessCommon;C:\\Applications\\LinksPortable;C:\\Program Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common Files\\Intel\\WirelessCommon;C:\\Program Files\\Miktex\\miktex\\bin\\x64;C:\\MSYS2\\usr\\bin\\site_perl;C:\\MSYS2\\usr\\bin\\vendor_perl;C:\\MSYS2\\usr\\bin\\core_perl;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin"),("PATHEXT",".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"),("PGFONT","C:\\Applications\\wingx\\files\\grfont.dat"),("PKG_CONFIG_PATH","C:\\MSYS2\\mingw64\\lib\\pkgconfig;C:\\MSYS2\\mingw64\\share\\pkgconfig"),("PRINTER","Brother HL-5270DN"),("PROCESSOR_ARCHITECTURE","AMD64"),("PROCESSOR_IDENTIFIER","Intel64 Family 6 Model 69 Stepping 1, GenuineIntel"),("PROCESSOR_LEVEL","6"),("PROCESSOR_REVISION","4501"),("PROGRAMDATA","C:\\ProgramData"),("PROGRAMFILES","C:\\Program Files"),("PROGRAMFILES(X86)","C:\\Program Files (x86)"),("PROGRAMW6432","C:\\Program Files"),("PROMPT","$P$G"),("PS1","\\[\\e]0;\\w\\a\\]\\n\\[\\e[32m\\]\\u@\\h \\[\\e[35m\\]$MSYSTEM\\[\\e[0m\\] \\[\\e[33m\\]\\w\\[\\e[0m\\]\\n\\$ "),("PSMODULEPATH","C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\"),("PUBLIC","C:\\Users\\Public"),("PWD","C:/Haskell/gtk2hs-master/glib"),("PYTHONPATH","C:\\Program Files (x86)\\CambridgeSoft\\ChemOffice2015\\ChemScript\\Lib"),("RASMOLPATH","C:\\Program Files (x86)\\RasWin"),("SESSIONNAME","Console"),("SHELL","C:/MSYS2/usr/bin/bash"),("SHLVL","1"),("SYSTEMDRIVE","C:"),("SYSTEMROOT","C:\\Windows"),("TEMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("TERM","xterm-256color"),("TMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("UOIPME_REG_PATH","C:\\Program Files\\Intel Corporation\\USB over IP"),("USER","Ms PC-08"),("USERDOMAIN","PC-08"),("USERNAME","Ms PC-08"),("USERPROFILE","C:\\Users\\PC-08"),("VS110COMNTOOLS","C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\Common7\\Tools\\"),("VS120COMNTOOLS","C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\Tools\\"),("WD","C:\\MSYS2\\usr\\bin\\"),("WINDIR","C:\\Windows"),("WINGXDIR","C:\\Applications\\wingx"),("XML_CATALOG_FILES","C:/MSYS2/etc/xml/docbook-xml /etc/xml/catalog"),("_","./Setup")] ("C:\\Haskell\\ghc-7.11.20151024\\bin\\ghc-pkg.exe",["init","dist\\package.conf.inplace","-v2"]) writing cache dist\package.conf.inplace\package.cache Preprocessing library glib-0.13.2.1... creating dist\build\System\Glib Environment: [("","C:=C:\\Windows\\System32"),("ACLOCAL_PATH","C:\\MSYS2\\mingw64\\share\\aclocal;C:\\MSYS2\\usr\\share\\aclocal"),("ALLUSERSPROFILE","C:\\ProgramData"),("APPDATA","C:\\Users\\PC-08\\AppData\\Roaming"),("CHECKDEF","C:\\Applications\\wingx\\bin"),("COMMONPROGRAMFILES","C:\\Program Files\\Common Files"),("COMMONPROGRAMFILES(X86)","C:\\Program Files (x86)\\Common Files"),("COMMONPROGRAMW6432","C:\\Program Files\\Common Files"),("COMPUTERNAME","PC-08"),("COMSPEC","C:\\Windows\\system32\\cmd.exe"),("FP_NO_HOST_CHECK","NO"),("HOME","C:\\MSYS2\\home\\Ms PC-08"),("HOMEDRIVE","C:"),("HOMEPATH","\\Users\\PC-08"),("HOSTNAME","PC-08"),("INFOPATH","C:\\MSYS2\\usr\\local\\info;C:\\MSYS2\\usr\\share\\info;C:\\MSYS2\\usr\\info;C:\\MSYS2\\share\\info"),("LANG","de_DE.UTF-8"),("LOCALAPPDATA","C:\\Users\\PC-08\\AppData\\Local"),("LOGONSERVER","\\\\PC-08"),("MANPATH","C:\\MSYS2\\mingw64\\share\\man;C:\\MSYS2\\usr\\local\\man;C:\\MSYS2\\usr\\share\\man;C:\\MSYS2\\usr\\man;C:\\MSYS2\\share\\man"),("MSYSCON","mintty.exe"),("MSYSTEM","MINGW64"),("NUMBER_OF_PROCESSORS","4"),("OLDPWD","C:/MSYS2/home/Ms PC-08/cabal"),("OS","Windows_NT"),("PATH","C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Haskell\\ghc-7.11.20151024\\bin;C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin;C:\\MSYS2\\mingw64\\bin;C:\\MSYS2\\usr\\local\\bin;C:\\MSYS2\\usr\\bin;C:\\MSYS2\\usr\\bin;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0;C:\\Program Files (x86)\\ATI Technologies\\ATI.ACE\\Core-Static;C:\\Program Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common Files\\Intel\\WirelessCommon;C:\\Program Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common Files\\Intel\\WirelessCommon;C:\\Program Files\\Miktex\\miktex\\bin\\x64;C:\\MSYS2\\usr\\bin\\site_perl;C:\\MSYS2\\usr\\bin\\vendor_perl;C:\\MSYS2\\usr\\bin\\core_perl;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin"),("PATHEXT",".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"),("PGFONT","C:\\Applications\\wingx\\files\\grfont.dat"),("PKG_CONFIG_PATH","C:\\MSYS2\\mingw64\\lib\\pkgconfig;C:\\MSYS2\\mingw64\\share\\pkgconfig"),("PRINTER",""),("PROCESSOR_ARCHITECTURE","AMD64"),("PROCESSOR_IDENTIFIER","Intel64 Family 6 Model 69 Stepping 1, GenuineIntel"),("PROCESSOR_LEVEL","6"),("PROCESSOR_REVISION","4501"),("PROGRAMDATA","C:\\ProgramData"),("PROGRAMFILES","C:\\Program Files"),("PROGRAMFILES(X86)","C:\\Program Files (x86)"),("PROGRAMW6432","C:\\Program Files"),("PROMPT","$P$G"),("PS1","\\[\\e]0;\\w\\a\\]\\n\\[\\e[32m\\]\\u@\\h \\[\\e[35m\\]$MSYSTEM\\[\\e[0m\\] \\[\\e[33m\\]\\w\\[\\e[0m\\]\\n\\$ "),("PSMODULEPATH","C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\"),("PUBLIC","C:\\Users\\Public"),("PWD","C:/Haskell/gtk2hs-master/glib"),("PYTHONPATH","C:\\Program Files (x86)\\CambridgeSoft\\ChemOffice2015\\ChemScript\\Lib"),("RASMOLPATH","C:\\Program Files (x86)\\RasWin"),("SESSIONNAME","Console"),("SHELL","C:/MSYS2/usr/bin/bash"),("SHLVL","1"),("SYSTEMDRIVE","C:"),("SYSTEMROOT","C:\\Windows"),("TEMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("TERM","xterm-256color"),("TMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("UOIPME_REG_PATH","C:\\Program Files\\Intel Corporation\\USB over IP"),("USER","Ms PC-08"),("USERDOMAIN","PC-08"),("USERNAME","Ms PC-08"),("USERPROFILE","C:\\Users\\PC-08"),("VS110COMNTOOLS","C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\Common7\\Tools\\"),("VS120COMNTOOLS","C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\Tools\\"),("WD","C:\\MSYS2\\usr\\bin\\"),("WINDIR","C:\\Windows"),("WINGXDIR","C:\\Applications\\wingx"),("XML_CATALOG_FILES","C:/MSYS2/etc/xml/docbook-xml /etc/xml/catalog"),("_","./Setup")] ("C:\\Haskell\\ghc-7.11.20151024\\bin\\hsc2hs.exe",["--cc=C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin\\gcc.exe","--ld=C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin\\gcc.exe","--cflag=-fno-stack-protector","--lflag=-fno-stack-protector","--cflag=-D__GLASGOW_HASKELL__=711","--cflag=-Dmingw32_BUILD_OS=1","--cflag=-Dx86_64_BUILD_ARCH=1","--cflag=-Dmingw32_HOST_OS=1","--cflag=-Dx86_64_HOST_ARCH=1","--cflag=-Idist\\build\\autogen","--cflag=-Idist\\build","--cflag=-ISystem/Glib","--cflag=-IC:/MSYS2/mingw64/include/glib-2.0","--cflag=-IC:/MSYS2/mingw64/lib/glib-2.0/include","--cflag=-mms-bitfields","--cflag=-U__BLOCKS__","--cflag=-D__attribute__(A)=","--cflag=-DUSE_GCLOSURE_SIGNALS_IMPL","--cflag=-Idist\\build\\autogen","--cflag=-include","--cflag=dist\\build\\autogen\\cabal_macros.h","--lflag=-LC:/MSYS2/mingw64/lib","--lflag=-lgobject-2.0","--lflag=-lglib-2.0","--lflag=-lintl","--cflag=-IC:\\Haskell\\ghc-7.11.20151024\\lib\\bytestring-0.10.6.0\\include","--cflag=-IC:\\Haskell\\ghc-7.11.20151024\\lib\\base-4.8.2.0\\include","--cflag=-IC:\\Haskell\\ghc-7.11.20151024\\lib\\integer-gmp-1.0.0.0\\include","--cflag=-IC:\\Haskell\\ghc-7.11.20151024\\lib/include","--lflag=-LC:\\Users\\PC-08\\AppData\\Roaming\\cabal\\x86_64-windows-ghc-7.11.20151024\\utf8s_LAIfwUZWplI3JK3b6W44Yv","--lflag=-LC:\\Users\\PC-08\\AppData\\Roaming\\cabal\\x86_64-windows-ghc-7.11.20151024\\text_IqwR9CiNGjxJyQdu3bLbNv","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\binary-0.7.5.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\containers-0.5.6.2","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\bytestring-0.10.6.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\deepseq-1.4.1.1","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\array-0.5.1.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\base-4.8.2.0","--lflag=-lwsock32","--lflag=-luser32","--lflag=-lshell32","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\integer-gmp-1.0.0.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\ghc-prim-0.4.0.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib/rts","--lflag=-lm","--lflag=-lwsock32","--lflag=-lgdi32","--lflag=-lwinmm","-o","dist\\build\\System\\Glib\\StoreValue.hs","System\\Glib\\StoreValue.hsc"]) dist\build\System\Glib\StoreValue_hsc_utils.o:StoreValue_hsc_utils.c:(.text+0x0): multiple definition of `__debugbreak' dist\build\System\Glib\StoreValue_hsc_make.o:StoreValue_hsc_make.c:(.text+0x0): first defined here collect2.exe: error: ld returned 1 exit status linking dist\build\System\Glib\StoreValue_hsc_make.o failed (exit code 1) command was: C:\Haskell\ghc-7.11.20151024\mingw\bin\gcc.exe dist\build\System\Glib\StoreValue_hsc_make.o dist\build\System\Glib\StoreValue_hsc_utils.o -o dist\build\System\Glib\StoreValue_hsc_make.exe -fno-stack-protector -LC:/MSYS2/mingw64/lib -lgobject-2.0 -lglib-2.0 -lintl -LC:\Users\PC-08\AppData\Roaming\cabal\x86_64-windows-ghc-7.11.20151024\utf8s_LAIfwUZWplI3JK3b6W44Yv -LC:\Users\PC-08\AppData\Roaming\cabal\x86_64-windows-ghc-7.11.20151024\text_IqwR9CiNGjxJyQdu3bLbNv -LC:\Haskell\ghc-7.11.20151024\lib\binary-0.7.5.0 -LC:\Haskell\ghc-7.11.20151024\lib\containers-0.5.6.2 -LC:\Haskell\ghc-7.11.20151024\lib\bytestring-0.10.6.0 -LC:\Haskell\ghc-7.11.20151024\lib\deepseq-1.4.1.1 -LC:\Haskell\ghc-7.11.20151024\lib\array-0.5.1.0 -LC:\Haskell\ghc-7.11.20151024\lib\base-4.8.2.0 -lwsock32 -luser32 -lshell32 -LC:\Haskell\ghc-7.11.20151024\lib\integer-gmp-1.0.0.0 -LC:\Haskell\ghc-7.11.20151024\lib\ghc-prim-0.4.0.0 -LC:\Haskell\ghc-7.11.20151024\lib/rts -lm -lwsock32 -lgdi32 -lwinmm C:\Haskell\ghc-7.11.20151024\bin\hsc2hs.exe returned ExitFailure 1 From matej.borovec at yahoo.com Sun Oct 25 14:37:50 2015 From: matej.borovec at yahoo.com (Matej Borovec) Date: Sun, 25 Oct 2015 14:37:50 +0000 (UTC) Subject: [Haskell-cafe] Glib-0.13.2.1 build failure: multiple definition of `__debugbreak' (ghc-7.11.20151024) In-Reply-To: <562CE479.6080502@gmx.de> References: <562CE479.6080502@gmx.de> Message-ID: <1207358281.2595021.1445783870089.JavaMail.yahoo@mail.yahoo.com> The problem seems to be in "cpp-options" field in glib.cabal where "__attribute__(A)" is redefined to nothing. This seems to cause problems only with head GHC because in head MinGW that comes with GHC is upgraded to 5.2. Simply removing that redefinition from .cabal fixed problem for me. Note that you will need to do the same thing for pango and gio packages. On Sunday, October 25, 2015 3:17 PM, Burkhard Groh wrote: In my latest attempt to finally build the gtk3 package with ghc-head 'ghc-master' (7.11.20151024) for a current project under windows x64 using the latest msys2-version and its supplied gtk3 libraries (mingw64/mingw-w64-x86_64-gtk3 3.18.2-1)? I encountered this cryptical (linking) error. (See complete log for command './Setup build -v3' attached) I should add that I'm rather a beginner with regards to the Haskell language and its package distribution system cabal. Thus all thoughts, ideas and suggestions how to fix this problem are welcome. Best regards Burkhard complete building response in msys2-shell using the mingw64 script: $ ./Setup build -v3 Component build order: library creating dist\build creating dist\build\autogen Building glib-0.13.2.1... Environment: [("","C:=C:\\Windows\\System32"),("ACLOCAL_PATH","C:\\MSYS2\\mingw64\\share\\aclocal;C:\\MSYS2\\usr\\share\\aclocal"),("ALLUSERSPROFILE","C:\\ProgramData"),("APPDATA","C:\\Users\\PC-08\\AppData\\Roaming"),("CHECKDEF","C:\\Applications\\wingx\\bin"),("COMMONPROGRAMFILES","C:\\Program Files\\Common Files"),("COMMONPROGRAMFILES(X86)","C:\\Program Files (x86)\\Common Files"),("COMMONPROGRAMW6432","C:\\Program Files\\Common Files"),("COMPUTERNAME","PC-08"),("COMSPEC","C:\\Windows\\system32\\cmd.exe"),("FP_NO_HOST_CHECK","NO"),("HOME","C:\\MSYS2\\home\\Ms PC-08"),("HOMEDRIVE","C:"),("HOMEPATH","\\Users\\PC-08"),("HOSTNAME","PC-08"),("INFOPATH","C:\\MSYS2\\usr\\local\\info;C:\\MSYS2\\usr\\share\\info;C:\\MSYS2\\usr\\info;C:\\MSYS2\\share\\info"),("LANG","de_DE.UTF-8"),("LOCALAPPDATA","C:\\Users\\PC-08\\AppData\\Local"),("LOGONSERVER","\\\\PC-08"),("MANPATH","C:\\MSYS2\\mingw64\\share\\man;C:\\MSYS2\\usr\\local\\man;C:\\MSYS2\\usr\\share\\man;C:\\MSYS2\\usr\\man;C:\\MSYS2\\share\\man"),("MSYSCON","mintty.exe"),("MSYSTEM","MINGW64"),("NUMBER_OF_PROCESSORS","4"),("OLDPWD","C:/MSYS2/home/Ms PC-08/cabal"),("ORTEPDIR","C:\\Applications\\ortep3"),("OS","Windows_NT"),("PATH","C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Haskell\\ghc-7.11.20151024\\bin;C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin;C:\\MSYS2\\mingw64\\bin;C:\\MSYS2\\usr\\local\\bin;C:\\MSYS2\\usr\\bin;C:\\MSYS2\\usr\\bin;C:\\Program Files (x86)\\CambridgeSoft\\ChemOffice2015\\ChemScript\\Lib;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0;C:\\Program Files (x86)\\ATI Technologies\\ATI.ACE\\Core-Static;C:\\Program Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common Files\\Intel\\WirelessCommon;C:\\Applications\\LinksPortable;C:\\Program Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common Files\\Intel\\WirelessCommon;C:\\Program Files\\Miktex\\miktex\\bin\\x64;C:\\MSYS2\\usr\\bin\\site_perl;C:\\MSYS2\\usr\\bin\\vendor_perl;C:\\MSYS2\\usr\\bin\\core_perl;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin"),("PATHEXT",".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"),("PGFONT","C:\\Applications\\wingx\\files\\grfont.dat"),("PKG_CONFIG_PATH","C:\\MSYS2\\mingw64\\lib\\pkgconfig;C:\\MSYS2\\mingw64\\share\\pkgconfig"),("PRINTER","Brother HL-5270DN"),("PROCESSOR_ARCHITECTURE","AMD64"),("PROCESSOR_IDENTIFIER","Intel64 Family 6 Model 69 Stepping 1, GenuineIntel"),("PROCESSOR_LEVEL","6"),("PROCESSOR_REVISION","4501"),("PROGRAMDATA","C:\\ProgramData"),("PROGRAMFILES","C:\\Program Files"),("PROGRAMFILES(X86)","C:\\Program Files (x86)"),("PROGRAMW6432","C:\\Program Files"),("PROMPT","$P$G"),("PS1","\\[\\e]0;\\w\\a\\]\\n\\[\\e[32m\\]\\u@\\h \\[\\e[35m\\]$MSYSTEM\\[\\e[0m\\] \\[\\e[33m\\]\\w\\[\\e[0m\\]\\n\\$ "),("PSMODULEPATH","C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\"),("PUBLIC","C:\\Users\\Public"),("PWD","C:/Haskell/gtk2hs-master/glib"),("PYTHONPATH","C:\\Program Files (x86)\\CambridgeSoft\\ChemOffice2015\\ChemScript\\Lib"),("RASMOLPATH","C:\\Program Files (x86)\\RasWin"),("SESSIONNAME","Console"),("SHELL","C:/MSYS2/usr/bin/bash"),("SHLVL","1"),("SYSTEMDRIVE","C:"),("SYSTEMROOT","C:\\Windows"),("TEMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("TERM","xterm-256color"),("TMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("UOIPME_REG_PATH","C:\\Program Files\\Intel Corporation\\USB over IP"),("USER","Ms PC-08"),("USERDOMAIN","PC-08"),("USERNAME","Ms PC-08"),("USERPROFILE","C:\\Users\\PC-08"),("VS110COMNTOOLS","C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\Common7\\Tools\\"),("VS120COMNTOOLS","C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\Tools\\"),("WD","C:\\MSYS2\\usr\\bin\\"),("WINDIR","C:\\Windows"),("WINGXDIR","C:\\Applications\\wingx"),("XML_CATALOG_FILES","C:/MSYS2/etc/xml/docbook-xml /etc/xml/catalog"),("_","./Setup")] ("C:\\Haskell\\ghc-7.11.20151024\\bin\\ghc-pkg.exe",["init","dist\\package.conf.inplace","-v2"]) writing cache dist\package.conf.inplace\package.cache Preprocessing library glib-0.13.2.1... creating dist\build\System\Glib Environment: [("","C:=C:\\Windows\\System32"),("ACLOCAL_PATH","C:\\MSYS2\\mingw64\\share\\aclocal;C:\\MSYS2\\usr\\share\\aclocal"),("ALLUSERSPROFILE","C:\\ProgramData"),("APPDATA","C:\\Users\\PC-08\\AppData\\Roaming"),("CHECKDEF","C:\\Applications\\wingx\\bin"),("COMMONPROGRAMFILES","C:\\Program Files\\Common Files"),("COMMONPROGRAMFILES(X86)","C:\\Program Files (x86)\\Common Files"),("COMMONPROGRAMW6432","C:\\Program Files\\Common Files"),("COMPUTERNAME","PC-08"),("COMSPEC","C:\\Windows\\system32\\cmd.exe"),("FP_NO_HOST_CHECK","NO"),("HOME","C:\\MSYS2\\home\\Ms PC-08"),("HOMEDRIVE","C:"),("HOMEPATH","\\Users\\PC-08"),("HOSTNAME","PC-08"),("INFOPATH","C:\\MSYS2\\usr\\local\\info;C:\\MSYS2\\usr\\share\\info;C:\\MSYS2\\usr\\info;C:\\MSYS2\\share\\info"),("LANG","de_DE.UTF-8"),("LOCALAPPDATA","C:\\Users\\PC-08\\AppData\\Local"),("LOGONSERVER","\\\\PC-08"),("MANPATH","C:\\MSYS2\\mingw64\\share\\man;C:\\MSYS2\\usr\\local\\man;C:\\MSYS2\\usr\\share\\man;C:\\MSYS2\\usr\\man;C:\\MSYS2\\share\\man"),("MSYSCON","mintty.exe"),("MSYSTEM","MINGW64"),("NUMBER_OF_PROCESSORS","4"),("OLDPWD","C:/MSYS2/home/Ms PC-08/cabal"),("OS","Windows_NT"),("PATH","C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Haskell\\ghc-7.11.20151024\\bin;C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin;C:\\MSYS2\\mingw64\\bin;C:\\MSYS2\\usr\\local\\bin;C:\\MSYS2\\usr\\bin;C:\\MSYS2\\usr\\bin;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0;C:\\Program Files (x86)\\ATI Technologies\\ATI.ACE\\Core-Static;C:\\Program Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common Files\\Intel\\WirelessCommon;C:\\Program Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common Files\\Intel\\WirelessCommon;C:\\Program Files\\Miktex\\miktex\\bin\\x64;C:\\MSYS2\\usr\\bin\\site_perl;C:\\MSYS2\\usr\\bin\\vendor_perl;C:\\MSYS2\\usr\\bin\\core_perl;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin"),("PATHEXT",".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"),("PGFONT","C:\\Applications\\wingx\\files\\grfont.dat"),("PKG_CONFIG_PATH","C:\\MSYS2\\mingw64\\lib\\pkgconfig;C:\\MSYS2\\mingw64\\share\\pkgconfig"),("PRINTER",""),("PROCESSOR_ARCHITECTURE","AMD64"),("PROCESSOR_IDENTIFIER","Intel64 Family 6 Model 69 Stepping 1, GenuineIntel"),("PROCESSOR_LEVEL","6"),("PROCESSOR_REVISION","4501"),("PROGRAMDATA","C:\\ProgramData"),("PROGRAMFILES","C:\\Program Files"),("PROGRAMFILES(X86)","C:\\Program Files (x86)"),("PROGRAMW6432","C:\\Program Files"),("PROMPT","$P$G"),("PS1","\\[\\e]0;\\w\\a\\]\\n\\[\\e[32m\\]\\u@\\h \\[\\e[35m\\]$MSYSTEM\\[\\e[0m\\] \\[\\e[33m\\]\\w\\[\\e[0m\\]\\n\\$ "),("PSMODULEPATH","C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\"),("PUBLIC","C:\\Users\\Public"),("PWD","C:/Haskell/gtk2hs-master/glib"),("PYTHONPATH","C:\\Program Files (x86)\\CambridgeSoft\\ChemOffice2015\\ChemScript\\Lib"),("RASMOLPATH","C:\\Program Files (x86)\\RasWin"),("SESSIONNAME","Console"),("SHELL","C:/MSYS2/usr/bin/bash"),("SHLVL","1"),("SYSTEMDRIVE","C:"),("SYSTEMROOT","C:\\Windows"),("TEMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("TERM","xterm-256color"),("TMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("UOIPME_REG_PATH","C:\\Program Files\\Intel Corporation\\USB over IP"),("USER","Ms PC-08"),("USERDOMAIN","PC-08"),("USERNAME","Ms PC-08"),("USERPROFILE","C:\\Users\\PC-08"),("VS110COMNTOOLS","C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\Common7\\Tools\\"),("VS120COMNTOOLS","C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\Tools\\"),("WD","C:\\MSYS2\\usr\\bin\\"),("WINDIR","C:\\Windows"),("WINGXDIR","C:\\Applications\\wingx"),("XML_CATALOG_FILES","C:/MSYS2/etc/xml/docbook-xml /etc/xml/catalog"),("_","./Setup")] ("C:\\Haskell\\ghc-7.11.20151024\\bin\\hsc2hs.exe",["--cc=C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin\\gcc.exe","--ld=C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin\\gcc.exe","--cflag=-fno-stack-protector","--lflag=-fno-stack-protector","--cflag=-D__GLASGOW_HASKELL__=711","--cflag=-Dmingw32_BUILD_OS=1","--cflag=-Dx86_64_BUILD_ARCH=1","--cflag=-Dmingw32_HOST_OS=1","--cflag=-Dx86_64_HOST_ARCH=1","--cflag=-Idist\\build\\autogen","--cflag=-Idist\\build","--cflag=-ISystem/Glib","--cflag=-IC:/MSYS2/mingw64/include/glib-2.0","--cflag=-IC:/MSYS2/mingw64/lib/glib-2.0/include","--cflag=-mms-bitfields","--cflag=-U__BLOCKS__","--cflag=-D__attribute__(A)=","--cflag=-DUSE_GCLOSURE_SIGNALS_IMPL","--cflag=-Idist\\build\\autogen","--cflag=-include","--cflag=dist\\build\\autogen\\cabal_macros.h","--lflag=-LC:/MSYS2/mingw64/lib","--lflag=-lgobject-2.0","--lflag=-lglib-2.0","--lflag=-lintl","--cflag=-IC:\\Haskell\\ghc-7.11.20151024\\lib\\bytestring-0.10.6.0\\include","--cflag=-IC:\\Haskell\\ghc-7.11.20151024 \\lib\\base-4.8.2.0\\include","--cflag=-IC:\\Haskell\\ghc-7.11.20151024\\lib\\integer-gmp-1.0.0.0\\include","--cflag=-IC:\\Haskell\\ghc-7.11.20151024\\lib/include","--lflag=-LC:\\Users\\PC-08\\AppData\\Roaming\\cabal\\x86_64-windows-ghc-7.11.20151024\\utf8s_LAIfwUZWplI3JK3b6W44Yv","--lflag=-LC:\\Users\\PC-08\\AppData\\Roaming\\cabal\\x86_64-windows-ghc-7.11.20151024\\text_IqwR9CiNGjxJyQdu3bLbNv","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\binary-0.7.5.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\containers-0.5.6.2","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\bytestring-0.10.6.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\deepseq-1.4.1.1","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\array-0.5.1.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\base-4.8.2.0","--lflag=-lwsock32","--lflag=-luser32","--lflag=-lshell32","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\integer-gmp-1.0.0.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\ghc-prim-0.4.0.0","--lflag=-LC: \\Haskell\\ghc-7.11.20151024\\lib/rts","--lflag=-lm","--lflag=-lwsock32","--lflag=-lgdi32","--lflag=-lwinmm","-o","dist\\build\\System\\Glib\\StoreValue.hs","System\\Glib\\StoreValue.hsc"]) dist\build\System\Glib\StoreValue_hsc_utils.o:StoreValue_hsc_utils.c:(.text+0x0): multiple definition of `__debugbreak' dist\build\System\Glib\StoreValue_hsc_make.o:StoreValue_hsc_make.c:(.text+0x0): first defined here collect2.exe: error: ld returned 1 exit status linking dist\build\System\Glib\StoreValue_hsc_make.o failed (exit code 1) command was: C:\Haskell\ghc-7.11.20151024\mingw\bin\gcc.exe dist\build\System\Glib\StoreValue_hsc_make.o dist\build\System\Glib\StoreValue_hsc_utils.o -o dist\build\System\Glib\StoreValue_hsc_make.exe -fno-stack-protector -LC:/MSYS2/mingw64/lib -lgobject-2.0 -lglib-2.0 -lintl -LC:\Users\PC-08\AppData\Roaming\cabal\x86_64-windows-ghc-7.11.20151024\utf8s_LAIfwUZWplI3JK3b6W44Yv -LC:\Users\PC-08\AppData\Roaming\cabal\x86_64-windows-ghc-7.11.20151024\text_IqwR9CiNGjxJyQdu3bLbNv -LC:\Haskell\ghc-7.11.20151024\lib\binary-0.7.5.0 -LC:\Haskell\ghc-7.11.20151024\lib\containers-0.5.6.2 -LC:\Haskell\ghc-7.11.20151024\lib\bytestring-0.10.6.0 -LC:\Haskell\ghc-7.11.20151024\lib\deepseq-1.4.1.1 -LC:\Haskell\ghc-7.11.20151024\lib\array-0.5.1.0 -LC:\Haskell\ghc-7.11.20151024\lib\base-4.8.2.0 -lwsock32 -luser32 -lshell32 -LC:\Haskell\ghc-7.11.20151024\lib\integer-gmp-1.0.0.0 -LC:\Haskell\ghc-7.11.20151024\lib\ghc-prim-0.4.0.0 -LC:\Haskell\ghc-7.11.20151024\lib/rts -lm -lwsock32 -lgdi32 -lwinmm C:\Haskell\ghc-7.11.20151024\bin\hsc2hs.exe returned ExitFailure 1 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Sun Oct 25 20:03:15 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Sun, 25 Oct 2015 21:03:15 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: <878u6rcfkc.fsf@gmail.com> References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <87bnbnclyr.fsf@gmail.com> <878u6rcfkc.fsf@gmail.com> Message-ID: Yes, nicely put. 2015-10-25 13:03 GMT+01:00 Matteo Acerbi : > > Janis Voigtl?nder writes: > > > My messages this morning have decoupled the discussion from Traversable, > by > > specialising to one container type for which left-to-right is predefined. > > > > In my mind, that gets to the heart of what Charles was after, namely the > > "calling in an associative manner" thing, which is independent of the > > question "how do we know right from left in the first place". Do the > > considerations then make sense to you as well? > > Yes, they do. > > The examples related to non-empty lists were most clarifying. > > I agree that the interesting part was question 3, concerning which I > think I have now understood your interpretation. > > As an exercise, I'll try to express it in my own words. > > Let's restrict to non-empty lists. > > I'll use these definitions: > > data NonEmptyList a = Last a | Cons a (NonEmptyList a) > -- or the one from package semigroups > > data Tree a = Leaf a | Node (Tree a) (Tree a) > > foldTree :: (a -> a -> a) -> Tree a -> a > foldTree f (Leaf a) = a > foldTree f (Node x y) = f (foldTree f x) (foldTree f y) > > (<>) :: NonEmptyList a -> NonEmptyList a -> NonEmptyList a > Last a <> ys = Cons a ys > Cons a xs <> ys = Cons a (xs <> ys) > > toNonEmptyList :: Tree a -> NonEmptyList a > toNonEmptyList (Leaf a) = Last a > toNonEmptyList (Node x y) = toNonEmptyList x <> toNonEmptyList y > > Given the above, a fold h which calls the first argument "in an > associative manner" is a function of type > > h :: (a -> a -> a) -> NonEmptyList a -> a > > which can be equivalently expressed in terms of another function > > h' :: NonEmptyList a -> Tree a > > such that > > toNonEmptyList . h' = id > > as > > h f = foldTree f . h' > > . > > h' is allowed to build an application tree whose shape can be a function > of the input list, but its leaves, considered in left-to-right order, > must contain precisely the input sequence. > > Is this correct? > > Best, > Matteo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Burkhard.Groh at gmx.de Sun Oct 25 22:18:30 2015 From: Burkhard.Groh at gmx.de (Burkhard Groh) Date: Mon, 26 Oct 2015 00:18:30 +0200 Subject: [Haskell-cafe] Glib-0.13.2.1 build failure: multiple definition of `__debugbreak' (ghc-7.11.20151024) In-Reply-To: <1207358281.2595021.1445783870089.JavaMail.yahoo@mail.yahoo.com> References: <562CE479.6080502@gmx.de> <1207358281.2595021.1445783870089.JavaMail.yahoo@mail.yahoo.com> Message-ID: <562D5536.4030602@gmx.de> Thank you very much for your response. Removing the '-D__attribute__(A)=' field from cpp-options in glib.cabal and also in following packages indeed did the trick. After spending the last couple of weekends on sorting things out to make the gtk package work on the haskell plattform/ghc release rather unsuccessfully I was really glad to be greeted with the following lines: $ runhaskell Setup install Installing library in C:\Users\PC-08\AppData\Roaming\cabal\x86_64-windows-ghc-7.11.20151024\gtk3-0.14.1-5qebDIGBW46XNcTrIexOxy Registering gtk3-0.14.1... Now I can finally continue to focus my attention on the actual project. Thanks again for your concise (and very helpful) answer. Keep up the good work! Best regards Burkhard On 25.10.2015 16:37, Matej Borovec wrote: > The problem seems to be in "cpp-options" field in glib.cabal where > "__attribute__(A)" is redefined to nothing. This seems to cause > problems only with head GHC because in head MinGW that comes with GHC > is upgraded to 5.2. > > Simply removing that redefinition from .cabal fixed problem for me. > Note that you will need to do the same thing for pango and gio packages. > > > > On Sunday, October 25, 2015 3:17 PM, Burkhard Groh > wrote: > > > In my latest attempt to finally build the gtk3 package with ghc-head > 'ghc-master' (7.11.20151024) for a current project under windows x64 > using the latest msys2-version and its supplied gtk3 libraries > (mingw64/mingw-w64-x86_64-gtk3 3.18.2-1) I encountered this cryptical > (linking) error. (See complete log for command './Setup build -v3' > attached) I should add that I'm rather a beginner with regards to the > Haskell language and its package distribution system cabal. > Thus all thoughts, ideas and suggestions how to fix this problem are > welcome. > > Best regards > Burkhard > > complete building response in msys2-shell using the mingw64 script: > > $ ./Setup build -v3 > Component build order: library > creating dist\build > creating dist\build\autogen > Building glib-0.13.2.1... > Environment: > [("","C:=C:\\Windows\\System32"),("ACLOCAL_PATH","C:\\MSYS2\\mingw64\\share\\aclocal;C:\\MSYS2\\usr\\share\\aclocal"),("ALLUSERSPROFILE","C:\\ProgramData"),("APPDATA","C:\\Users\\PC-08\\AppData\\Roaming"),("CHECKDEF","C:\\Applications\\wingx\\bin"),("COMMONPROGRAMFILES","C:\\Program > > Files\\Common Files"),("COMMONPROGRAMFILES(X86)","C:\\Program Files > (x86)\\Common Files"),("COMMONPROGRAMW6432","C:\\Program Files\\Common > Files"),("COMPUTERNAME","PC-08"),("COMSPEC","C:\\Windows\\system32\\cmd.exe"),("FP_NO_HOST_CHECK","NO"),("HOME","C:\\MSYS2\\home\\Ms > > PC-08"),("HOMEDRIVE","C:"),("HOMEPATH","\\Users\\PC-08"),("HOSTNAME","PC-08"),("INFOPATH","C:\\MSYS2\\usr\\local\\info;C:\\MSYS2\\usr\\share\\info;C:\\MSYS2\\usr\\info;C:\\MSYS2\\share\\info"),("LANG","de_DE.UTF-8"),("LOCALAPPDATA","C:\\Users\\PC-08\\AppData\\Local"),("LOGONSERVER","\\\\PC-08"),("MANPATH","C:\\MSYS2\\mingw64\\share\\man;C:\\MSYS2\\usr\\local\\man;C:\\MSYS2\\usr\\share\\man;C:\\MSYS2\\usr\\man;C:\\MSYS2\\share\\man"),("MSYSCON","mintty.exe"),("MSYSTEM","MINGW64"),("NUMBER_OF_PROCESSORS","4"),("OLDPWD","C:/MSYS2/home/Ms > > PC-08/cabal"),("ORTEPDIR","C:\\Applications\\ortep3"),("OS","Windows_NT"),("PATH","C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Haskell\\ghc-7.11.20151024\\bin;C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin;C:\\MSYS2\\mingw64\\bin;C:\\MSYS2\\usr\\local\\bin;C:\\MSYS2\\usr\\bin;C:\\MSYS2\\usr\\bin;C:\\Program > > Files > (x86)\\CambridgeSoft\\ChemOffice2015\\ChemScript\\Lib;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0;C:\\Program > > Files (x86)\\ATI Technologies\\ATI.ACE\\Core-Static;C:\\Program > Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common > Files\\Intel\\WirelessCommon;C:\\Applications\\LinksPortable;C:\\Program > Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common > Files\\Intel\\WirelessCommon;C:\\Program > Files\\Miktex\\miktex\\bin\\x64;C:\\MSYS2\\usr\\bin\\site_perl;C:\\MSYS2\\usr\\bin\\vendor_perl;C:\\MSYS2\\usr\\bin\\core_perl;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin"),("PATHEXT",".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"),("PGFONT","C:\\Applications\\wingx\\files\\grfont.dat"),("PKG_CONFIG_PATH","C:\\MSYS2\\mingw64\\lib\\pkgconfig;C:\\MSYS2\\mingw64\\share\\pkgconfig"),("PRINTER","Brother > > HL-5270DN"),("PROCESSOR_ARCHITECTURE","AMD64"),("PROCESSOR_IDENTIFIER","Intel64 > > Family 6 Model 69 Stepping 1, > GenuineIntel"),("PROCESSOR_LEVEL","6"),("PROCESSOR_REVISION","4501"),("PROGRAMDATA","C:\\ProgramData"),("PROGRAMFILES","C:\\Program > > Files"),("PROGRAMFILES(X86)","C:\\Program Files > (x86)"),("PROGRAMW6432","C:\\Program > Files"),("PROMPT","$P$G"),("PS1","\\[\\e]0;\\w\\a\\]\\n\\[\\e[32m\\]\\u@\\h > > \\[\\e[35m\\]$MSYSTEM\\[\\e[0m\\] \\[\\e[33m\\]\\w\\[\\e[0m\\]\\n\\$ > "),("PSMODULEPATH","C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\"),("PUBLIC","C:\\Users\\Public"),("PWD","C:/Haskell/gtk2hs-master/glib"),("PYTHONPATH","C:\\Program > > Files > (x86)\\CambridgeSoft\\ChemOffice2015\\ChemScript\\Lib"),("RASMOLPATH","C:\\Program > > Files > (x86)\\RasWin"),("SESSIONNAME","Console"),("SHELL","C:/MSYS2/usr/bin/bash"),("SHLVL","1"),("SYSTEMDRIVE","C:"),("SYSTEMROOT","C:\\Windows"),("TEMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("TERM","xterm-256color"),("TMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("UOIPME_REG_PATH","C:\\Program > > Files\\Intel Corporation\\USB over IP"),("USER","Ms > PC-08"),("USERDOMAIN","PC-08"),("USERNAME","Ms > PC-08"),("USERPROFILE","C:\\Users\\PC-08"),("VS110COMNTOOLS","C:\\Program > Files > (x86)\\Microsoft Visual Studio > 11.0\\Common7\\Tools\\"),("VS120COMNTOOLS","C:\\Program Files > (x86)\\Microsoft Visual Studio > 12.0\\Common7\\Tools\\"),("WD","C:\\MSYS2\\usr\\bin\\"),("WINDIR","C:\\Windows"),("WINGXDIR","C:\\Applications\\wingx"),("XML_CATALOG_FILES","C:/MSYS2/etc/xml/docbook-xml > > /etc/xml/catalog"),("_","./Setup")] > ("C:\\Haskell\\ghc-7.11.20151024\\bin\\ghc-pkg.exe",["init","dist\\package.conf.inplace","-v2"]) > writing cache dist\package.conf.inplace\package.cache > Preprocessing library glib-0.13.2.1... > creating dist\build\System\Glib > Environment: > [("","C:=C:\\Windows\\System32"),("ACLOCAL_PATH","C:\\MSYS2\\mingw64\\share\\aclocal;C:\\MSYS2\\usr\\share\\aclocal"),("ALLUSERSPROFILE","C:\\ProgramData"),("APPDATA","C:\\Users\\PC-08\\AppData\\Roaming"),("CHECKDEF","C:\\Applications\\wingx\\bin"),("COMMONPROGRAMFILES","C:\\Program > > Files\\Common Files"),("COMMONPROGRAMFILES(X86)","C:\\Program Files > (x86)\\Common Files"),("COMMONPROGRAMW6432","C:\\Program Files\\Common > Files"),("COMPUTERNAME","PC-08"),("COMSPEC","C:\\Windows\\system32\\cmd.exe"),("FP_NO_HOST_CHECK","NO"),("HOME","C:\\MSYS2\\home\\Ms > > PC-08"),("HOMEDRIVE","C:"),("HOMEPATH","\\Users\\PC-08"),("HOSTNAME","PC-08"),("INFOPATH","C:\\MSYS2\\usr\\local\\info;C:\\MSYS2\\usr\\share\\info;C:\\MSYS2\\usr\\info;C:\\MSYS2\\share\\info"),("LANG","de_DE.UTF-8"),("LOCALAPPDATA","C:\\Users\\PC-08\\AppData\\Local"),("LOGONSERVER","\\\\PC-08"),("MANPATH","C:\\MSYS2\\mingw64\\share\\man;C:\\MSYS2\\usr\\local\\man;C:\\MSYS2\\usr\\share\\man;C:\\MSYS2\\usr\\man;C:\\MSYS2\\share\\man"),("MSYSCON","mintty.exe"),("MSYSTEM","MINGW64"),("NUMBER_OF_PROCESSORS","4"),("OLDPWD","C:/MSYS2/home/Ms > > PC-08/cabal"),("OS","Windows_NT"),("PATH","C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Haskell\\ghc-7.11.20151024\\bin;C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin;C:\\MSYS2\\mingw64\\bin;C:\\MSYS2\\usr\\local\\bin;C:\\MSYS2\\usr\\bin;C:\\MSYS2\\usr\\bin;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0;C:\\Program > > Files (x86)\\ATI Technologies\\ATI.ACE\\Core-Static;C:\\Program > Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common > Files\\Intel\\WirelessCommon;C:\\Program > Files\\Intel\\WiFi\\bin;C:\\Program Files\\Common > Files\\Intel\\WirelessCommon;C:\\Program > Files\\Miktex\\miktex\\bin\\x64;C:\\MSYS2\\usr\\bin\\site_perl;C:\\MSYS2\\usr\\bin\\vendor_perl;C:\\MSYS2\\usr\\bin\\core_perl;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin;C:\\Users\\PC-08\\AppData\\Roaming\\cabal\\bin"),("PATHEXT",".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"),("PGFONT","C:\\Applications\\wingx\\files\\grfont.dat"),("PKG_CONFIG_PATH","C:\\MSYS2\\mingw64\\lib\\pkgconfig;C:\\MSYS2\\mingw64\\share\\pkgconfig"),("PRINTER",""),("PROCESSOR_ARCHITECTURE","AMD64"),("PROCESSOR_IDENTIFIER","Intel64 > > Family 6 Model 69 Stepping 1, > GenuineIntel"),("PROCESSOR_LEVEL","6"),("PROCESSOR_REVISION","4501"),("PROGRAMDATA","C:\\ProgramData"),("PROGRAMFILES","C:\\Program > > Files"),("PROGRAMFILES(X86)","C:\\Program Files > (x86)"),("PROGRAMW6432","C:\\Program > Files"),("PROMPT","$P$G"),("PS1","\\[\\e]0;\\w\\a\\]\\n\\[\\e[32m\\]\\u@\\h > > \\[\\e[35m\\]$MSYSTEM\\[\\e[0m\\] \\[\\e[33m\\]\\w\\[\\e[0m\\]\\n\\$ > "),("PSMODULEPATH","C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\"),("PUBLIC","C:\\Users\\Public"),("PWD","C:/Haskell/gtk2hs-master/glib"),("PYTHONPATH","C:\\Program > > Files > (x86)\\CambridgeSoft\\ChemOffice2015\\ChemScript\\Lib"),("RASMOLPATH","C:\\Program > > Files > (x86)\\RasWin"),("SESSIONNAME","Console"),("SHELL","C:/MSYS2/usr/bin/bash"),("SHLVL","1"),("SYSTEMDRIVE","C:"),("SYSTEMROOT","C:\\Windows"),("TEMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("TERM","xterm-256color"),("TMP","C:\\Users\\PC-08\\AppData\\Local\\Temp"),("UOIPME_REG_PATH","C:\\Program > > Files\\Intel Corporation\\USB over IP"),("USER","Ms > PC-08"),("USERDOMAIN","PC-08"),("USERNAME","Ms > PC-08"),("USERPROFILE","C:\\Users\\PC-08"),("VS110COMNTOOLS","C:\\Program > Files > (x86)\\Microsoft Visual Studio > 11.0\\Common7\\Tools\\"),("VS120COMNTOOLS","C:\\Program Files > (x86)\\Microsoft Visual Studio > 12.0\\Common7\\Tools\\"),("WD","C:\\MSYS2\\usr\\bin\\"),("WINDIR","C:\\Windows"),("WINGXDIR","C:\\Applications\\wingx"),("XML_CATALOG_FILES","C:/MSYS2/etc/xml/docbook-xml > > /etc/xml/catalog"),("_","./Setup")] > ("C:\\Haskell\\ghc-7.11.20151024\\bin\\hsc2hs.exe",["--cc=C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin\\gcc.exe","--ld=C:\\Haskell\\ghc-7.11.20151024\\mingw\\bin\\gcc.exe","--cflag=-fno-stack-protector","--lflag=-fno-stack-protector","--cflag=-D__GLASGOW_HASKELL__=711","--cflag=-Dmingw32_BUILD_OS=1","--cflag=-Dx86_64_BUILD_ARCH=1","--cflag=-Dmingw32_HOST_OS=1","--cflag=-Dx86_64_HOST_ARCH=1","--cflag=-Idist\\build\\autogen","--cflag=-Idist\\build","--cflag=-ISystem/Glib","--cflag=-IC:/MSYS2/mingw64/include/glib-2.0","--cflag=-IC:/MSYS2/mingw64/lib/glib-2.0/include","--cflag=-mms-bitfields","--cflag=-U__BLOCKS__","--cflag=-D__attribute__(A)=","--cflag=-DUSE_GCLOSURE_SIGNALS_IMPL","--cflag=-Idist\\build\\autogen","--cflag=-include","--cflag=dist\\build\\autogen\\cabal_macros.h","--lflag=-LC:/MSYS2/mingw64/lib","--lflag=-lgobject-2.0","--lflag=-lglib-2.0","--lflag=-lintl","--cflag=-IC:\\Haskell\\ghc-7.11.20151024\\lib\\bytestring-0.10.6.0\\include","--cflag=-IC:\\Haskell\\ghc-7.11.20151024 > \\lib\\base-4.8.2.0\\include","--cflag=-IC:\\Haskell\\ghc-7.11.20151024\\lib\\integer-gmp-1.0.0.0\\include","--cflag=-IC:\\Haskell\\ghc-7.11.20151024\\lib/include","--lflag=-LC:\\Users\\PC-08\\AppData\\Roaming\\cabal\\x86_64-windows-ghc-7.11.20151024\\utf8s_LAIfwUZWplI3JK3b6W44Yv","--lflag=-LC:\\Users\\PC-08\\AppData\\Roaming\\cabal\\x86_64-windows-ghc-7.11.20151024\\text_IqwR9CiNGjxJyQdu3bLbNv","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\binary-0.7.5.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\containers-0.5.6.2","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\bytestring-0.10.6.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\deepseq-1.4.1.1","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\array-0.5.1.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\base-4.8.2.0","--lflag=-lwsock32","--lflag=-luser32","--lflag=-lshell32","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\integer-gmp-1.0.0.0","--lflag=-LC:\\Haskell\\ghc-7.11.20151024\\lib\\ghc-prim-0.4.0.0","--lflag=-LC: > \\Haskell\\ghc-7.11.20151024\\lib/rts","--lflag=-lm","--lflag=-lwsock32","--lflag=-lgdi32","--lflag=-lwinmm","-o","dist\\build\\System\\Glib\\StoreValue.hs","System\\Glib\\StoreValue.hsc"]) > dist\build\System\Glib\StoreValue_hsc_utils.o:StoreValue_hsc_utils.c:(.text+0x0): > > multiple definition of `__debugbreak' > dist\build\System\Glib\StoreValue_hsc_make.o:StoreValue_hsc_make.c:(.text+0x0): > > first defined here > collect2.exe: error: ld returned 1 exit status > linking dist\build\System\Glib\StoreValue_hsc_make.o failed (exit code 1) > command was: C:\Haskell\ghc-7.11.20151024\mingw\bin\gcc.exe > dist\build\System\Glib\StoreValue_hsc_make.o > dist\build\System\Glib\StoreValue_hsc_utils.o -o > dist\build\System\Glib\StoreValue_hsc_make.exe -fno-stack-protector > -LC:/MSYS2/mingw64/lib -lgobject-2.0 -lglib-2.0 -lintl > -LC:\Users\PC-08\AppData\Roaming\cabal\x86_64-windows-ghc-7.11.20151024\utf8s_LAIfwUZWplI3JK3b6W44Yv > > -LC:\Users\PC-08\AppData\Roaming\cabal\x86_64-windows-ghc-7.11.20151024\text_IqwR9CiNGjxJyQdu3bLbNv > > -LC:\Haskell\ghc-7.11.20151024\lib\binary-0.7.5.0 > -LC:\Haskell\ghc-7.11.20151024\lib\containers-0.5.6.2 > -LC:\Haskell\ghc-7.11.20151024\lib\bytestring-0.10.6.0 > -LC:\Haskell\ghc-7.11.20151024\lib\deepseq-1.4.1.1 > -LC:\Haskell\ghc-7.11.20151024\lib\array-0.5.1.0 > -LC:\Haskell\ghc-7.11.20151024\lib\base-4.8.2.0 -lwsock32 -luser32 > -lshell32 -LC:\Haskell\ghc-7.11.20151024\lib\integer-gmp-1.0.0.0 > -LC:\Haskell\ghc-7.11.20151024\lib\ghc-prim-0.4.0.0 > -LC:\Haskell\ghc-7.11.20151024\lib/rts -lm -lwsock32 -lgdi32 -lwinmm > C:\Haskell\ghc-7.11.20151024\bin\hsc2hs.exe returned ExitFailure 1 > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > From omeragacan at gmail.com Mon Oct 26 01:29:15 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 25 Oct 2015 21:29:15 -0400 Subject: [Haskell-cafe] Hackage feature request: show types of names listed in index page Message-ID: I pretty much said all I wanted to say in the title, but just to rephrase, I think it'd be super helpful if Hackage listed types of names listed in index pages. The reason is because most of the time I'm using index pages for searching things, but if I wanted to list all functions that somehow use a type, for example, index pages don't help. With type information in the index pages I can just search for a type and my browser would highlight all functions that somehow use the type. From erantapaa at gmail.com Mon Oct 26 04:17:43 2015 From: erantapaa at gmail.com (Erik Rantapaa) Date: Sun, 25 Oct 2015 21:17:43 -0700 (PDT) Subject: [Haskell-cafe] mashup of Haskell News and hdiff Message-ID: Hi all, For Haskell News junkies I created a simple mashup of haskellnews.org and Luite Stegeman's hdiff site. It adds a "hdiff" link to all Hackage upload news items so you can conveniently see what changed in the new version. It consists of just an html file and .js file and is available at: https://github.com/erantapaa/haskellnews-hdiff ER -------------- next part -------------- An HTML attachment was scrubbed... URL: From erantapaa at gmail.com Mon Oct 26 04:38:25 2015 From: erantapaa at gmail.com (Erik Rantapaa) Date: Sun, 25 Oct 2015 21:38:25 -0700 (PDT) Subject: [Haskell-cafe] Hackage feature request: show types of names listed in index page In-Reply-To: References: Message-ID: <41e1f5c5-980e-4099-b5fb-195f5dd47c83@googlegroups.com> The hoogle index files might be another way to perform this kind of search. You can download all of the hoogle index files for packages on Hackage at: http://hackage.haskell.org/packages/hoogle.tar.gz Each package has it's own .txt file which you can search using grep. You can also create index files for your own cabal projects using the command `cabal haddock --hoogle`. On Sunday, October 25, 2015 at 8:30:02 PM UTC-5, ?mer Sinan A?acan wrote: > > I pretty much said all I wanted to say in the title, but just to > rephrase, I think it'd be super helpful if Hackage listed types of > names listed in index pages. The reason is because most of the time > I'm using index pages for searching things, but if I wanted to list > all functions that somehow use a type, for example, index pages don't > help. > > With type information in the index pages I can just search for a type > and my browser would highlight all functions that somehow use the > type. > _______________________________________________ > Haskell-Cafe mailing list > Haskel... at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erantapaa at gmail.com Mon Oct 26 05:05:06 2015 From: erantapaa at gmail.com (Erik Rantapaa) Date: Sun, 25 Oct 2015 22:05:06 -0700 (PDT) Subject: [Haskell-cafe] mashup of Haskell News and hdiff In-Reply-To: References: Message-ID: Well... it should work for Safari users. I'll update this message when I have a solution for Firefox and Chrome. On Sunday, October 25, 2015 at 11:17:43 PM UTC-5, Erik Rantapaa wrote: > > Hi all, > > For Haskell News junkies I created a simple mashup of haskellnews.org and Luite > Stegeman's hdiff site. It adds a "hdiff" link to all Hackage upload news > items so you can conveniently see what changed in the new version. > > It consists of just an html file and .js file and is available at: > https://github.com/erantapaa/haskellnews-hdiff > > ER > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From defigueiredo at ucdavis.edu Mon Oct 26 07:27:37 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Mon, 26 Oct 2015 01:27:37 -0600 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting be automated? In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> <20151023161206.GG16020@weber> <562A8CF4.4010306@ucdavis.edu> <1445632742.2175.16.camel@gmail.com> <562AB3E7.4010504@ucdavis.edu> Message-ID: <562DD5E9.1030308@ucdavis.edu> Hi Kim-Ee, Sorry for not making the problem clear enough! Here's an example. It is somewhat contrived, but I think it captures the essence of the problem. Imagine I need to read a .CSV file which may or may not contain column titles on its first line. I'm not interested in the column titles, I just want the rest of the file. I am provided a library function to read the contents of the file (using a "callback"). The library author provided this function in the IO monad. withCSV :: FilePath -> (Handle -> IO r) -> IO r withCSV path action = do putStrLn "opening file" h <- openFile path ReadWriteMode r <- action h hClose h putStrLn "file closed" return r The problem arises because I also want to use the ReaderT monad transformer. My environment information will tell me whether or not to disregard the first (i.e. column title) line. Here's a *failed* attempt at writing this next step: data ColumnHeaders = FirstLine | None getFileContents :: ReaderT ColumnHeaders IO String getFileContents = liftIO $ withCSV "data.csv" myReadFile where myReadFile :: Handle -> IO String myReadFile handle = do header <- ask --- OOOPPSss!!! FAIL! Can't ask. case header of None -> return "" FirstLine -> hGetLine handle -- skip first line text <- hGetContents handle evaluate (length text) -- force lazy IO return text main = do cs <- runReaderT getFileContents FirstLine print cs Unfortunately, I can't write getFileContents as described above because myReadFile is an IO action and cannot access the configuration information available through the Reader. If I could rewrite withCSV I could fix this issue: withCSVLifted :: MonadIO mIO => FilePath -> (Handle -> mIO r) -> mIO r withCSVLifted path action = do liftIO $putStrLn "opening file" h <- liftIO $ openFile path ReadMode r <- action h liftIO $ hClose h liftIO $ putStrLn "file closed" return r The difference between withCSV and withCSVLifted is just a bunch of liftIO operations and a more flexible type signature. The crucial change is that the lifted version allows any function of type (MonadIO mIO => Handle -> mIO r) rather than just (Handle -> IO r). This is general enough to allow me to re-write my configuration step and call ask (from within the callback). getFileContentsLifted :: ReaderT ColumnHeaders IO String getFileContentsLifted = withCSVLifted "data.csv" myReadFile where myReadFile :: Handle -> ReaderT ColumnHeaders IO String myReadFile handle = do header <- ask case header of None -> return "" FirstLine -> liftIO $ hGetLine handle -- skip first line then text <- liftIO $ hGetContents handle liftIO $ evaluate (length text) -- force lazy IO return text Other than calling the respective lifted version of withCSV the only difference between getFileContentsLifted and getFileContents are the extra liftIO calls. It can be very cumbersome to write a working version of getFileContents in the IO monad without easy access to ReaderT's ask. So, my questions were: 1. Should library authors always provide lifted versions of functions that take callbacks? In other words, is withCSVLifted :: MonadIO mIO => FilePath -> (Handle -> mIO r) -> mIO r always better than withCSV :: FilePath -> (Handle -> IO r) -> IO r ? If not, what's the best practice? 2. Once we define the MonadIO class, shouldn't the compiler be able to transform withCSV :: FilePath -> (Handle -> IO r) -> IO r into withCSVLifted :: MonadIO mIO => FilePath -> (Handle -> mIO r) -> mIO r by adding a number of liftIO calls to that class upon request? It seems like the kind of change we would like to automate. This email turned out to be longer than I expected. I hope it is clearer. You can find all the code here: https://gist.github.com/dimitri-xyz/3f9d1f6632479ef59304 Thanks! Dimitri On 10/23/15 7:48 PM, Kim-Ee Yeoh wrote: > > On Sat, Oct 24, 2015 at 5:25 AM, Dimitri DeFigueiredo > > wrote: > > Unfortunately, I am using the pipes library, so I cannot avoid > using a monad transformer. Because of the functionality pipes > provides, it does make sense for it to be a monad transformer. > > > Hi Dimitri, > > This is a very interesting topic, thank you for bringing it up. > > Unfortunately because of the very generalized way it's presented, it's > very hard for anyone else aside from Yuras to give it the attention it > deserves. > > Do you have a concrete example with sample code that you could > simplify and present instead? > > E.g. instead of the multiply-stacked monad transformer embedded in 200 > lines that you're facing, can you present an example with 2 monadic > layers (the base being IO) in say, 20 lines? > > -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From fis at etc-network.de Mon Oct 26 10:11:38 2015 From: fis at etc-network.de (Matthias Fischmann) Date: Mon, 26 Oct 2015 11:11:38 +0100 Subject: [Haskell-cafe] Five more days: Call for Contributions: BOB 2016 - Berlin, Feb 19, 2016 Message-ID: <20151026101138.GQ15402@lig> The submission deadline for is five days away. We are happy with the submissions so far, but you can always have more. So if you always wanted to look into some library that everybody is fussing about and then tell people what you learned, or if you have this trick or you wrote that piece of code that you are fond of, please take a minute to check out our submission guidelines this week. http://bobkonf.de/2016/cfp (We have speaker grants for under-represented groups.) cheers, m. From oleg at okmij.org Mon Oct 26 11:03:32 2015 From: oleg at okmij.org (Oleg) Date: Mon, 26 Oct 2015 20:03:32 +0900 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting be automated? Message-ID: <20151026110332.GA2129@Magus.sf-private> Dimitri DeFigueiredo wrote: > Imagine I need to read a .CSV file which may or may not contain column > titles on its first line. I'm not interested in the column titles, I > just want the rest of the file. I am provided a library function to read > the contents of the file (using a "callback"). The library author > provided this function in the IO monad. > withCSV :: FilePath -> (Handle -> IO r) -> IO r > withCSV path action = do > putStrLn "opening file" > h <- openFile path ReadWriteMode > r <- action h > hClose h > putStrLn "file closed" > return r > The problem arises because I also want to use the ReaderT monad > transformer. My environment information will tell me > whether or not to disregard the first (i.e. column title) line. For this particular example, the answer is easy: If you have the IO monads, you have the Reader monad, and the State/Writer as well. This is just an IORef. > getFileContents :: IO String > getFileContents = do > ref <- newIORef False > withCSV "data.csv" (myReadFile ref) > where > myReadFile :: IORef Bool -> Handle -> IO String > myReadFile ref handle = do > header <- readIORef ref -- ask --- OOOPPSss!!! FAIL! Can't ask. > case header of > False -> return "" > True -> hGetLine handle -- skip first line > text <- hGetContents handle > return text Using just IO, you can get State, Reader, Writer, and Exception (and in a modular way!) As to you general question, I will and do advocating abandoning monad transformers altogether. The paper on extensible effects demonstrated a new solution to the MonadCatchIO problem that solved the long-standing issue of discarding state upon exception. See Sec 6 of http://okmij.org/ftp/Haskell/extensible/more.pdf From roma at ro-che.info Mon Oct 26 12:10:48 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 26 Oct 2015 14:10:48 +0200 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting be automated? In-Reply-To: <20151026110332.GA2129@Magus.sf-private> References: <20151026110332.GA2129@Magus.sf-private> Message-ID: <562E1848.2020801@ro-che.info> On 10/26/2015 01:03 PM, Oleg wrote: > For this particular example, the answer is easy: If you have the IO > monads, you have the Reader monad, and the State/Writer as well. This > is just an IORef. > >> getFileContents :: IO String >> getFileContents = do >> ref <- newIORef False >> withCSV "data.csv" (myReadFile ref) >> where >> myReadFile :: IORef Bool -> Handle -> IO String >> myReadFile ref handle = do >> header <- readIORef ref -- ask --- OOOPPSss!!! FAIL! Can't ask. >> case header of >> False -> return "" >> True -> hGetLine handle -- skip first line >> text <- hGetContents handle >> return text Not really. You are passing 'ref' into myReadFile by hand here. If you are willing to pass parameters by hand, there is no need in IORef at all; you could just as well pass header directly. Passing extra arguments is precisely what ReaderT liberates you from. I agree that *given a ReaderT* (or implicit params, or your implicit configurations), you can emulate StateT/WriterT using IORefs (but only one way of stacking w.r.t. exceptions). Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From oleg at okmij.org Mon Oct 26 13:55:22 2015 From: oleg at okmij.org (Oleg) Date: Mon, 26 Oct 2015 22:55:22 +0900 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting In-Reply-To: <562E1848.2020801@ro-che.info> Message-ID: <20151026135522.GA2792@Magus.sf-private> Roman Cheplyaka wrote: > Not really. You are passing 'ref' into myReadFile by hand here. If you > are willing to pass parameters by hand, there is no need in IORef at > all; you could just as well pass header directly. I confess in embellishing the problem and tacitly upgrading Reader to the State. The original problem seemed too simple. In penance, I show the solution to the original problem, using exactly the signature of the original poster, and using exactly his code for myReadFile, (but with the lifted type, which is what he wanted, it seems). > data ColumnHeaders = FirstLine | None > getFileContents :: ReaderT ColumnHeaders IO String > getFileContents = do > header <- ask -- can ask it here > lift $ withCSV "data.csv" (\handle -> runReaderT (myReadFile handle) header) > where > myReadFile :: Handle -> ReaderT ColumnHeaders IO String > myReadFile handle = do > header <- ask -- Now, we can ask it, alright > case header of > None -> return "" > FirstLine -> lift $ hGetLine handle -- skip first line > text <- lift $ hGetContents handle > return text The idea is simple: since withCSV wants its callback to be IO rather than ReaderT IO, it means the withCSV is not capable of altering the environment of the callback. Therefore, the myReadFile is executed in the same environment, regardless of the Handle. Once we understand this, the solution is trivial. So, to answer the question of the original poster: it seems we can do what he wants withCSV he got. There is no need to ask withCSV author for anything. > I agree that *given a ReaderT* (or implicit params, or your implicit > configurations), you can emulate StateT/WriterT using IORefs (but only > one way of stacking w.r.t. exceptions). Actually, it is easy to get other ways of `stacking with respect to exceptions.' Once we get persistent state (which is what IORef provide), we can always discard that state by writing an appropriate exception handler. I guess I can make another stab at monad transformers and say that thinking in terms of stacks is not always productive. From omeragacan at gmail.com Mon Oct 26 14:22:17 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 26 Oct 2015 10:22:17 -0400 Subject: [Haskell-cafe] Hackage feature request: show types of names listed in index page In-Reply-To: <41e1f5c5-980e-4099-b5fb-195f5dd47c83@googlegroups.com> References: <41e1f5c5-980e-4099-b5fb-195f5dd47c83@googlegroups.com> Message-ID: Thanks for the tip Erik, it sounds really useful. Still, an index page would list only public names, which is arguably more useful because you can't use hidden names. grepping the whole code is also a worse option because of all the useless code that grep will list. 2015-10-26 0:38 GMT-04:00 Erik Rantapaa : > The hoogle index files might be another way to perform this kind of search. > > You can download all of the hoogle index files for packages on Hackage at: > > http://hackage.haskell.org/packages/hoogle.tar.gz > > Each package has it's own .txt file which you can search using grep. You can > also create index files for your own cabal projects using the command `cabal > haddock --hoogle`. > > > On Sunday, October 25, 2015 at 8:30:02 PM UTC-5, ?mer Sinan A?acan wrote: >> >> I pretty much said all I wanted to say in the title, but just to >> rephrase, I think it'd be super helpful if Hackage listed types of >> names listed in index pages. The reason is because most of the time >> I'm using index pages for searching things, but if I wanted to list >> all functions that somehow use a type, for example, index pages don't >> help. >> >> With type information in the index pages I can just search for a type >> and my browser would highlight all functions that somehow use the >> type. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskel... at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From defigueiredo at ucdavis.edu Mon Oct 26 16:36:40 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Mon, 26 Oct 2015 10:36:40 -0600 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting In-Reply-To: <20151026135522.GA2792@Magus.sf-private> References: <20151026135522.GA2792@Magus.sf-private> Message-ID: <562E5698.4050907@ucdavis.edu> It seems I need to read Oleg's paper. I might have over simplified the problem by using ReaderT in my example. In my original problem this role is played by the Pipes library (and instead of using 'ask', I wanted to 'yield' control to a downstream pipe). Thanks for the feedback! :-) Dimitri On 10/26/15 7:55 AM, Oleg wrote: > Roman Cheplyaka wrote: >> Not really. You are passing 'ref' into myReadFile by hand here. If you >> are willing to pass parameters by hand, there is no need in IORef at >> all; you could just as well pass header directly. > I confess in embellishing the problem and tacitly upgrading Reader to > the State. The original problem seemed too simple. In penance, I show > the solution to the original problem, using exactly the signature of > the original poster, and using exactly his code for myReadFile, > (but with the lifted type, which is what he wanted, it seems). > > >> data ColumnHeaders = FirstLine | None >> getFileContents :: ReaderT ColumnHeaders IO String >> getFileContents = do >> header <- ask -- can ask it here >> lift $ withCSV "data.csv" (\handle -> runReaderT (myReadFile handle) header) >> where > >> myReadFile :: Handle -> ReaderT ColumnHeaders IO String >> myReadFile handle = do >> header <- ask -- Now, we can ask it, alright >> case header of >> None -> return "" >> FirstLine -> lift $ hGetLine handle -- skip first line >> text <- lift $ hGetContents handle >> return text > The idea is simple: since withCSV wants its callback to be IO rather > than ReaderT IO, it means the withCSV is not capable of altering the > environment of the callback. Therefore, the myReadFile is executed in > the same environment, regardless of the Handle. Once we understand > this, the solution is trivial. > > So, to answer the question of the original poster: it seems we can do > what he wants withCSV he got. There is no need to ask withCSV author > for anything. > > >> I agree that *given a ReaderT* (or implicit params, or your implicit >> configurations), you can emulate StateT/WriterT using IORefs (but only >> one way of stacking w.r.t. exceptions). > Actually, it is easy to get other ways of `stacking with respect to > exceptions.' Once we get persistent state (which is what IORef > provide), we can always discard that state by writing an appropriate > exception handler. I guess I can make another stab at monad > transformers and say that thinking in terms of stacks is not always > productive. From ky3 at atamo.com Mon Oct 26 16:47:55 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Mon, 26 Oct 2015 23:47:55 +0700 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting In-Reply-To: <562E5698.4050907@ucdavis.edu> References: <20151026135522.GA2792@Magus.sf-private> <562E5698.4050907@ucdavis.edu> Message-ID: On Mon, Oct 26, 2015 at 11:36 PM, Dimitri DeFigueiredo < defigueiredo at ucdavis.edu> wrote: > I might have over simplified the problem by using ReaderT in my example. > In my original problem this role is played by the Pipes library (and > instead of using 'ask', I wanted to 'yield' control to a downstream pipe). Is there a way you could introduce just enough complexity to allow Oleg another stab? Also, there's always the fallback of showing your Pipes-based code although that library doesn't enjoy universal familiarity. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From chneukirchen at gmail.com Mon Oct 26 20:45:31 2015 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Mon, 26 Oct 2015 21:45:31 +0100 Subject: [Haskell-cafe] Munich Haskell Meeting, 2015-10-29 @ 19:30 Message-ID: <87a8r5bbpw.fsf@gmail.com> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, October 29 at Cafe Puck at 19h30. For details see here: http://chneukirchen.github.io/haskell-munich.de/dates (http://www.haskell-munich.de/ is currently out of order, but will be restored soon! I hope...) If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-oct-2015/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From dominic at steinitz.org Mon Oct 26 20:49:07 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Mon, 26 Oct 2015 20:49:07 +0000 Subject: [Haskell-cafe] Haskell Report Infelicity? Message-ID: I have probably misunderstood but is the following expected? floor, round, truncate and ceiling give similar results (all methods of the RealFrac class). properFraction :: (Integral b, RealFrac a) => a -> (b, a) *Girsanov> properFraction (-1 / 0) (-17976931348623159077293051907890247336179769789423065727343008115773267 5805500963132708477322407536021120113879871393357658789768814416622492847 4306394741243777678934248654852763022196012460941194530829520850057688381 5068234246288147391311054082723716335051068458629823994724593847971630483 5356329624224137216,0.0) *Girsanov> properFraction (1 / 0) (179769313486231590772930519078902473361797697894230657273430081157732675 8055009631327084773224075360211201138798713933576587897688144166224928474 3063947412437776789342486548527630221960124609411945308295208500576883815 0682342462881473913110540827237163350510684586298239947245938479716304835 356329624224137216,0.0) *Girsanov> properFraction (0 / 0) (-26965397022934738615939577861835371004269654684134598591014512173659901 3708251444699062715983611304031680170819807090036488184653221624933739271 1459592111865666518401372982279144533294018691411791796244281275086532572 2602351369432221086966581124085574502576602687944735992086890771957445725 3034494436336205824,0.0) The Haskell Report "6.4.6 Coercions and Component Extraction" is silent on what to expect with NaN, Infinity and -Infinity so I think it should be amended. Alternatively, one could expect implementations to throw a runtime error? In ghc, the problem is here https://phabricator.haskell.org/D160a /* This is expected to replace uses of __decodeDouble_2Int() in the long run */ StgInt __decodeDouble_Int64 (StgInt64 *const mantissa, const StgDouble dbl) { if (dbl) { int exp = 0; *mantissa = (StgInt64)scalbn(frexp(dbl, &exp), DBL_MANT_DIG); return exp-DBL_MANT_DIG; } else { *mantissa = 0; return 0; } } I believe frexp [1] and scalbn [2] both pass through NaN, Infinity and -Infinity and I think type coercion in C is undefined for these values. Furthermore exp is undefined for these values [1]. 1. http://en.cppreference.com/w/cpp/numeric/math/frexp 2. http://en.cppreference.com/w/cpp/numeric/math/scalbn Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com From erkokl at gmail.com Mon Oct 26 20:54:57 2015 From: erkokl at gmail.com (Levent Erkok) Date: Mon, 26 Oct 2015 13:54:57 -0700 Subject: [Haskell-cafe] Haskell Report Infelicity? In-Reply-To: References: Message-ID: There's an existing ticket about this, filed 7 years ago: https://ghc.haskell.org/trac/ghc/ticket/3070 On Mon, Oct 26, 2015 at 1:49 PM, Dominic Steinitz wrote: > I have probably misunderstood but is the following expected? floor, round, > truncate and ceiling give similar results (all methods of the RealFrac > class). > > properFraction :: (Integral b, RealFrac a) => a -> (b, a) > > *Girsanov> properFraction (-1 / 0) > (-17976931348623159077293051907890247336179769789423065727343008115773267 > 5805500963132708477322407536021120113879871393357658789768814416622492847 > 4306394741243777678934248654852763022196012460941194530829520850057688381 > 5068234246288147391311054082723716335051068458629823994724593847971630483 > 5356329624224137216,0.0) > *Girsanov> properFraction (1 / 0) > (179769313486231590772930519078902473361797697894230657273430081157732675 > 8055009631327084773224075360211201138798713933576587897688144166224928474 > 3063947412437776789342486548527630221960124609411945308295208500576883815 > 0682342462881473913110540827237163350510684586298239947245938479716304835 > 356329624224137216,0.0) > *Girsanov> properFraction (0 / 0) > (-26965397022934738615939577861835371004269654684134598591014512173659901 > 3708251444699062715983611304031680170819807090036488184653221624933739271 > 1459592111865666518401372982279144533294018691411791796244281275086532572 > 2602351369432221086966581124085574502576602687944735992086890771957445725 > 3034494436336205824,0.0) > > The Haskell Report "6.4.6 Coercions and Component Extraction" is > silent on what to expect with NaN, Infinity and -Infinity so I think it > should > be amended. Alternatively, one could expect implementations to throw a > runtime error? > > In ghc, the problem is here https://phabricator.haskell.org/D160a > > /* This is expected to replace uses of __decodeDouble_2Int() in the long > run */ > StgInt > __decodeDouble_Int64 (StgInt64 *const mantissa, const StgDouble dbl) > { > if (dbl) { > int exp = 0; > *mantissa = (StgInt64)scalbn(frexp(dbl, &exp), DBL_MANT_DIG); > return exp-DBL_MANT_DIG; > } else { > *mantissa = 0; > return 0; > } > } > > I believe frexp [1] and scalbn [2] both pass through NaN, Infinity and > -Infinity and I > think type coercion in C is undefined for these values. > > Furthermore exp is undefined for these values [1]. > > 1. http://en.cppreference.com/w/cpp/numeric/math/frexp > 2. http://en.cppreference.com/w/cpp/numeric/math/scalbn > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maydwell at gmail.com Mon Oct 26 22:16:37 2015 From: maydwell at gmail.com (Lyndon Maydwell) Date: Tue, 27 Oct 2015 09:16:37 +1100 Subject: [Haskell-cafe] Melbourne Haskell Meetup, 2015-10-29 @ 18:30 Message-ID: Hi All, This week, the monthly Melbourne Haskell Meetup will take place on Thursday, October 29 at the Silverpond offices on Hardware Lane. For details see here: http://www.meetup.com/Melbourne-Haskell-Users-Group/events/225596759/ There will be a talk on Constraint Programming in Haskell by David Overton, as well as the usual free discussion about all things Haskell. Please come along if this interests you :-) - Lyndon ( Thanks to Christian Neukirchen's Munich Haskell announcement for reminding me to tell the Caf? about our meetup from time to time. ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Tue Oct 27 09:38:01 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Tue, 27 Oct 2015 09:38:01 +0000 Subject: [Haskell-cafe] Haskell Report Infelicity? In-Reply-To: References: Message-ID: <254E618C-39FE-4B14-8636-525B279EABBC@steinitz.org> Hi Levent, Thanks for this although it made me feel sad that this has not been resolved in 7 years. I just had a quick look at what OCAML does and they define floor :: Double -> Double (the don?t really but that?s the gist of it). Python, in so far as it is typed, does the same. So NaN can just be passed straight through for the user to deal with (no performance hit). Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com > On 26 Oct 2015, at 20:54, Levent Erkok wrote: > > There's an existing ticket about this, filed 7 years ago: https://ghc.haskell.org/trac/ghc/ticket/3070 > > On Mon, Oct 26, 2015 at 1:49 PM, Dominic Steinitz > wrote: > I have probably misunderstood but is the following expected? floor, round, truncate and ceiling give similar results (all methods of the RealFrac class). > > properFraction :: (Integral b, RealFrac a) => a -> (b, a) > > *Girsanov> properFraction (-1 / 0) > (-17976931348623159077293051907890247336179769789423065727343008115773267 > 5805500963132708477322407536021120113879871393357658789768814416622492847 > 4306394741243777678934248654852763022196012460941194530829520850057688381 > 5068234246288147391311054082723716335051068458629823994724593847971630483 > 5356329624224137216,0.0) > *Girsanov> properFraction (1 / 0) > (179769313486231590772930519078902473361797697894230657273430081157732675 > 8055009631327084773224075360211201138798713933576587897688144166224928474 > 3063947412437776789342486548527630221960124609411945308295208500576883815 > 0682342462881473913110540827237163350510684586298239947245938479716304835 > 356329624224137216,0.0) > *Girsanov> properFraction (0 / 0) > (-26965397022934738615939577861835371004269654684134598591014512173659901 > 3708251444699062715983611304031680170819807090036488184653221624933739271 > 1459592111865666518401372982279144533294018691411791796244281275086532572 > 2602351369432221086966581124085574502576602687944735992086890771957445725 > 3034494436336205824,0.0) > > The Haskell Report "6.4.6 Coercions and Component Extraction" is > silent on what to expect with NaN, Infinity and -Infinity so I think it should > be amended. Alternatively, one could expect implementations to throw a > runtime error? > > In ghc, the problem is here https://phabricator.haskell.org/D160a > > /* This is expected to replace uses of __decodeDouble_2Int() in the long run */ > StgInt > __decodeDouble_Int64 (StgInt64 *const mantissa, const StgDouble dbl) > { > if (dbl) { > int exp = 0; > *mantissa = (StgInt64)scalbn(frexp(dbl, &exp), DBL_MANT_DIG); > return exp-DBL_MANT_DIG; > } else { > *mantissa = 0; > return 0; > } > } > > I believe frexp [1] and scalbn [2] both pass through NaN, Infinity and -Infinity and I > think type coercion in C is undefined for these values. > > Furthermore exp is undefined for these values [1]. > > 1. http://en.cppreference.com/w/cpp/numeric/math/frexp > 2. http://en.cppreference.com/w/cpp/numeric/math/scalbn > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.browne at dit.ie Tue Oct 27 12:32:35 2015 From: patrick.browne at dit.ie (PATRICK BROWNE) Date: Tue, 27 Oct 2015 12:32:35 +0000 Subject: [Haskell-cafe] Let, Equations, and Monad Message-ID: {- From Learn Haskell Fast and Hard : 4.3.1. Maybe is a monad http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way/#maybe-monad Concerning the code below I have the following questions: 1) Are eligibleLet and eligibleEquational operationally equivalent (i.e. perform the same operations) and/or semantically equivalent(i.e. Church-Rosser)? 2) Apart from the return type of Maybe instead of Bool how does eligibleMonad differ from eligibleLet? Regards, Pat -} deposit value account = account + value withdraw value account = account - value -- You are eligible for a bonus only if your sequence of transactions stays out of the red. eligibleLet :: (Num a,Ord a) => a -> Bool eligibleLet account = let account1 = deposit 100 account in if (account1 < 0) then False else let account2 = withdraw 200 account1 in if (account2 < 0) then False else let account3 = deposit 100 account2 in if (account3 < 0) then False else let account4 = withdraw 300 account3 in if (account4 < 0) then False else let account5 = deposit 1000 account4 in if (account5 < 0) then False else True eligibleEquational :: (Num a,Ord a) => a -> Bool eligibleEquational account = let account1 = deposit 100 account in if (account1 < 0) then False else let account2 = withdraw 200 account1 in if (account2 < 0) then False else let account3 = deposit 100 account2 in if (account3 < 0) then False else let account4 = withdraw 300 account3 in if (account4 < 0) then False else let account5 = deposit 1000 account4 in if (account5 < 0) then False else True -- Monadic version depositM :: (Num a) => a -> a -> Maybe a depositM value account = Just (account + value) withdrawM :: (Num a,Ord a) => a -> a -> Maybe a withdrawM value account = if (account < value) then Nothing else Just (account - value) eligibleMonad :: (Num a, Ord a) => a -> Maybe Bool eligibleMonad account = do account1 <- depositM 100 account account2 <- withdrawM 200 account1 account3 <- depositM 100 account2 account4 <- withdrawM 300 account3 account5 <- depositM 1000 account4 Just True main = do print $ eligibleLet 300 -- True print $ eligibleLet 299 -- Falsen print $ eligibleEquational 300 -- True print $ eligibleEquational 299 -- False print $ eligibleMonad 300 -- Just True print $ eligibleMonad 299 -- Nothing -- This email originated from DIT. If you received this email in error, please delete it from your system. Please note that if you are not the named addressee, disclosing, copying, distributing or taking any action based on the contents of this email or attachments is prohibited. www.dit.ie Is ? ITB?C a th?inig an r?omhphost seo. M? fuair t? an r?omhphost seo tr? earr?id, scrios de do ch?ras ? le do thoil. Tabhair ar aird, mura t? an seola? ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon ch?ipe?il, aon d?ileadh n? ar aon ghn?omh a dh?anfar bunaithe ar an ?bhar at? sa r?omhphost n? sna hiat?in seo. www.dit.ie T? ITB?C ag aistri? go Gr?inseach Ghorm?in ? DIT is on the move to Grangegorman -------------- next part -------------- An HTML attachment was scrubbed... URL: From anakreonmejdi at gmail.com Tue Oct 27 12:34:53 2015 From: anakreonmejdi at gmail.com (Anakreontas) Date: Tue, 27 Oct 2015 05:34:53 -0700 (PDT) Subject: [Haskell-cafe] SQL select for HDBC.ODBC MSSQL driver Message-ID: <70e108a5-7feb-41d4-a59c-58aa055e8e8c@googlegroups.com> Hello. I obtain a connection and try to execute a query on MSSQL server with HDBC c <- connectODBC "Driver={SQL Server};Server=.;Database=Pure_Local;Trusted_Connection=yes;" stm <- quickQuery c "select count(*) as cnt from X__FD" [] HDBC obtains the connection but the SQL query raises an exception with the following message: SqlError {seState = "[\"25000\"]", seNativeError = -1, seErrorMsg = "disconnect: [\"0: [Microsoft][ODBC SQL Server Driver]Invalid transaction state\"]"} No matter which statement I tried, I always get the "Invalid transaction state" message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.gigante at gmail.com Tue Oct 27 12:58:42 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Tue, 27 Oct 2015 13:58:42 +0100 Subject: [Haskell-cafe] Let, Equations, and Monad In-Reply-To: References: Message-ID: > Il giorno 27 ott 2015, alle ore 13:32, PATRICK BROWNE ha scritto: > > {- From Learn Haskell Fast and Hard : 4.3.1. Maybe is a monad > http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way/#maybe-monad > > Concerning the code below I have the following questions: > 1) Are eligibleLet and eligibleEquational operationally equivalent (i.e. perform the same operations) and/or semantically equivalent(i.e. Church-Rosser)? > 2) Apart from the return type of Maybe instead of Bool how does eligibleMonad differ from eligibleLet? > > Regards, > Pat > -} > > deposit value account = account + value > withdraw value account = account - value > > -- You are eligible for a bonus only if your sequence of transactions stays out of the red. > eligibleLet :: (Num a,Ord a) => a -> Bool > eligibleLet account = > let account1 = deposit 100 account in > if (account1 < 0) > then False > else > let account2 = withdraw 200 account1 in > if (account2 < 0) > then False > else > let account3 = deposit 100 account2 in > if (account3 < 0) > then False > else > let account4 = withdraw 300 account3 in > if (account4 < 0) > then False > else > let account5 = deposit 1000 account4 in > if (account5 < 0) > then False > else > True > Hi, I may not be able to correctly answer your question, but I?d make you notice that you don?t need all that nesting to express the same thing. Since those computations are pure, you don?t need to sequence them in that way: eligible account = all (< 0) [account1, account2, account3, account4] where account1 = deposit 100 account account2 = withdraw 200 account1 account3 = deposit 100 account2 account4 = withdraw 300 account3 account5 = deposit 1000 account4 Greetings, Nicola From jan.bracker at googlemail.com Tue Oct 27 14:14:00 2015 From: jan.bracker at googlemail.com (Jan Bracker) Date: Tue, 27 Oct 2015 14:14:00 +0000 Subject: [Haskell-cafe] Why does disambiguation in RebindableSyntax sometimes requires type signatures? Message-ID: Hello, I am currently playing around with RebindableSyntax and having several bind/return/sequence functions in scope at the same time. I thought that it would be enough to just pick the right one to use in each do-block by using a "where" or a "let". Surprisingly, I get some type related issues I can only fix by adding in some type signatures, but I don't understand why these signatures are actually necessary. Here is my example program: {-# LANGUAGE RebindableSyntax #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} import Prelude import qualified Prelude as P import qualified Control.Effect as E import Control.Effect.State ifThenElse :: Bool -> a -> a -> a ifThenElse True t e = t ifThenElse False t e = e main :: IO () main = do return () where return = P.return data Tree = Leaf Int | Branch Tree Tree process :: Tree -> State '[ "flatten" :-> Bool :! 'R ] (Either Tree [Int]) process (Leaf i) = do flatten <- get (Var :: (Var "flatten")) if flatten then return $ Right [i] else return $ Left $ Leaf i where --(>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) -> State (E.Plus State f g) b (>>=) = (E.>>=) (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus State f g) b (>>) = (E.>>) return = E.return fail = E.fail process (Branch tl tr) = do eitherL <- process tl eitherR <- process tr case (eitherL, eitherR) of (Left l, Left r) -> return $ Left $ Branch l r (Right l, Right r) -> return $ Right $ l ++ r where (>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) -> State (E.Plus State f g) b (>>=) = (E.>>=) (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus State f g) b (>>) = (E.>>) return = E.return fail = E.fail The program uses the "effect-monad" package in version 0.6.1. 1) The type signatures in the "where" following each do-block of the "process" function are required. If I remove the type signature of the sequence functions I get a type error of the following nature: examples/effect/Test.hs:33:16: Could not deduce (E.Inv m0 f0 g0) arising from a use of ?E.>>? Relevant bindings include (>>) :: m0 f0 a -> m0 g0 b -> m0 (E.Plus m0 f0 g0) b (bound at examples/effect/Test.hs:33:9) In the expression: (E.>>) In an equation for ?>>?: (>>) = (E.>>) In an equation for ?process?: process (Leaf i) = do { flatten <- get (Var :: Var "flatten"); if flatten then return $ Right [...] else return $ Left $ Leaf i } where (>>=) = (E.>>=) (>>) = (E.>>) return = E.return fail = E.fail examples/effect/Test.hs:33:16: No instance for (E.Effect m0) arising from a use of ?E.>>? In the expression: (E.>>) In an equation for ?>>?: (>>) = (E.>>) In an equation for ?process?: process (Leaf i) = do { flatten <- get (Var :: Var "flatten"); if flatten then return $ Right [...] else return $ Left $ Leaf i } where (>>=) = (E.>>=) (>>) = (E.>>) return = E.return fail = E.fail Which I interpret as the inability to infer the "E.Effect" and "E.Inv" constraints that are implied by the use of "E.>>". But why can't those constraints be inferred correctly? Shouldn't a definition like "(>>) = (E.>>)" just propagate the type signature and specialize it as needed? 2) If I remove the type signature for the bind operation, I get the following type error: examples/effect/Test.hs:38:3: Couldn't match type ?'["flatten" :-> (Bool :! 'R)]? with ?'[]? Expected type: State '["flatten" :-> (Bool :! 'R)] (Either Tree [Int]) -> (Either Tree [Int] -> State '[] (Either Tree [Int])) -> State '[] (Either Tree [Int]) Actual type: State '["flatten" :-> (Bool :! 'R)] (Either Tree [Int]) -> (Either Tree [Int] -> State '[] (Either Tree [Int])) -> State (E.Plus State '["flatten" :-> (Bool :! 'R)] '[]) (Either Tree [Int]) In a stmt of a 'do' block: eitherR <- process tr In the expression: do { eitherL <- process tl; eitherR <- process tr; case (eitherL, eitherR) of { (Left l, Left r) -> return $ Left $ Branch l r (Right l, Right r) -> return $ Right $ l ++ r } } In an equation for ?process?: process (Branch tl tr) = do { eitherL <- process tl; eitherR <- process tr; case (eitherL, eitherR) of { (Left l, Left r) -> return $ Left $ Branch l r (Right l, Right r) -> return $ Right $ l ++ r } } where (>>=) = (E.>>=) (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus State f g) b (>>) = (E.>>) return = E.return Which tells me that GHC is expecting the wrong type, but inferring the correct type. Again I don't see why this wrong type is expected and the right type is ignored. In either case, why does adding or removing the type signature for the local definitions make a difference at all? I suspect the issue has to do with the language extensions I enabled or the type-level computations that are done by the "effect-monad" package, but I cannot find a satisfying answer. Does anybody have a good explanation? I am working with GHC 7.10.2. Best, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.lewis at gold.ac.uk Tue Oct 27 15:08:26 2015 From: richard.lewis at gold.ac.uk (Richard Lewis) Date: Tue, 27 Oct 2015 15:08:26 +0000 Subject: [Haskell-cafe] Cabal depend on local package with foreign dependencies Message-ID: <85si4wmjrp.wl-richard.lewis@gold.ac.uk> Hi there, I have two libraries that I'm working on, packageA and packageB. packageA was written some time ago and depends on a foreign C library, libfoo, which I also wrote and which is installed in a non-standard location. packageB depends on packageA and is new and under active development. I have the following things, then: - libfoo is installed in ~/.local/lib, with includes in ~/.local/include/foo - packageA is in ~/src/packageA - packageB is in ~/src/packageB packageA has a .cabal file which includes: library build-depends: base, ... exposed-modules: A include-dirs: /home/richard/.local/include extra-lib-dirs: /home/richard/.local/lib executable testA ... extra-lib-dirs: /home/richard/.local/lib extra-libraries: foo I've created a cabal sandbox in packageA and I can successfully build it. Now, packageB makes use of packageA. It has a .cabal file which looks like this: library build-depends: base, packageA, ... exposed-modules: B executable testB ... extra-lib-dirs: /home/richard/.local/lib extra-libraries: foo Again, I've created a cabal sandbox in packageB. In order to be able to use packageA (which is not installed anywhere) I believe I have to do: $ cabal add-source ~/src/packageA Next, when I try and configure, it says: cabal: At least the following dependencies are missing: packageA -any That's fine, I assume, because I can now just `cabal install --only-dependencies` to get packageA built into packageB's sandbox. But when I try and do this, I get: $ cabal install --only-dependencies Resolving dependencies... Configuring packageA-0.1... Building packageA-0.1... Preprocessing library packageA-0.1... In-place registering packageA-0.1... Preprocessing executable 'testA' for packageA-0.1... Foo.hsc:10:33: fatal error: foo/foo.h: No such file or directory compilation terminated. So a target of packageA which compiles fine when doing cabal build directly from packageA now fails to compile when I attempt to build it from packageB by installing packageB's dependencies. I'm not sure how to proceed. It feels like maybe I have to tell cabal--when running it from packageB--where the include files are for packageA, because packageA needs to get compiled (which involves linking against libfoo and using libfoo's includes). I know that packageA *does* compile (because I've done that already), but it won't compile inside packageB's sandbox. Any suggestions? Richard From imantc at gmail.com Tue Oct 27 15:20:09 2015 From: imantc at gmail.com (Imants Cekusins) Date: Tue, 27 Oct 2015 16:20:09 +0100 Subject: [Haskell-cafe] Cabal depend on local package with foreign dependencies In-Reply-To: <85si4wmjrp.wl-richard.lewis@gold.ac.uk> References: <85si4wmjrp.wl-richard.lewis@gold.ac.uk> Message-ID: Hi Richard after building packageA, try running "cabal copy" from packageA .cabal dir then run "cabal install packageA" from packageB .cabal dir works for me. From richard.lewis at gold.ac.uk Tue Oct 27 18:28:35 2015 From: richard.lewis at gold.ac.uk (Richard Lewis) Date: Tue, 27 Oct 2015 18:28:35 +0000 Subject: [Haskell-cafe] Cabal depend on local package with foreign dependencies In-Reply-To: References: <85si4wmjrp.wl-richard.lewis@gold.ac.uk> Message-ID: <85io5smai4.wl-richard.lewis@gold.ac.uk> Hi Imants, On Tue, 27 Oct 2015 15:20:09 +0000, Imants Cekusins wrote: > > Hi Richard > > after building packageA, > > try running > "cabal copy" > from packageA .cabal dir > then run > "cabal install packageA" > from packageB .cabal dir > > works for me. Thanks for this suggestion. I'd not come across the cabal copy command. So I can see that pacakgeA is now installed in its own .cabal-sandbox. But when I try and configure packageB it still says that the dependency is missing. And if I try and build packageB, it still tries to build packageA (and fails just as before). I noticed that cabal copy has a --destdir option, so I tried passing packageB's .cabal-sandbox/ directory as that argument. This actually resulted in it stuffing the binaries etc. into a directory which was at the end of a copy of the absolute path to packageA made inside packageB's .cabal-sandbox/ directory (i.e. ~/src/packageB/.cabal-sandbox/home/richard/src/packageB/.cabal-sandbox/)! I did try manually moving all those files into ~/src/pacakgeB/.cabal-sandbox/ but that didn't fool cabal; it still claimed that packegeA was a missing dependency. Any further thoughts? Richard From ezyang at mit.edu Tue Oct 27 18:38:29 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 27 Oct 2015 11:38:29 -0700 Subject: [Haskell-cafe] Cabal depend on local package with foreign dependencies In-Reply-To: <85si4wmjrp.wl-richard.lewis@gold.ac.uk> References: <85si4wmjrp.wl-richard.lewis@gold.ac.uk> Message-ID: <1445971052-sup-8889@sabre> Hello Richard, I am not sure why package A builds in its own sandbox, but your copypaste suggests that executable testA does not have an include-dirs section which would tell it where to find foo.h. Could that be the problem? Edward Excerpts from Richard Lewis's message of 2015-10-27 08:08:26 -0700: > Hi there, > > I have two libraries that I'm working on, packageA and packageB. > > packageA was written some time ago and depends on a foreign C library, > libfoo, which I also wrote and which is installed in a non-standard > location. packageB depends on packageA and is new and under active > development. > > I have the following things, then: > > - libfoo is installed in ~/.local/lib, with includes in ~/.local/include/foo > - packageA is in ~/src/packageA > - packageB is in ~/src/packageB > > packageA has a .cabal file which includes: > > library > build-depends: base, ... > exposed-modules: A > include-dirs: /home/richard/.local/include > extra-lib-dirs: /home/richard/.local/lib > > executable testA > ... > extra-lib-dirs: /home/richard/.local/lib > extra-libraries: foo > > I've created a cabal sandbox in packageA and I can successfully build > it. > > Now, packageB makes use of packageA. It has a .cabal file which looks > like this: > > library > build-depends: base, packageA, ... > exposed-modules: B > > executable testB > ... > extra-lib-dirs: /home/richard/.local/lib > extra-libraries: foo > > Again, I've created a cabal sandbox in packageB. In order to be able > to use packageA (which is not installed anywhere) I believe I have to > do: > > $ cabal add-source ~/src/packageA > > Next, when I try and configure, it says: > > cabal: At least the following dependencies are missing: > packageA -any > > That's fine, I assume, because I can now just `cabal install > --only-dependencies` to get packageA built into packageB's > sandbox. But when I try and do this, I get: > > $ cabal install --only-dependencies > Resolving dependencies... > Configuring packageA-0.1... > Building packageA-0.1... > Preprocessing library packageA-0.1... > In-place registering packageA-0.1... > Preprocessing executable 'testA' for packageA-0.1... > Foo.hsc:10:33: fatal error: foo/foo.h: No such file or directory > compilation terminated. > > So a target of packageA which compiles fine when doing cabal build > directly from packageA now fails to compile when I attempt to build it > from packageB by installing packageB's dependencies. > > I'm not sure how to proceed. It feels like maybe I have to tell > cabal--when running it from packageB--where the include files are for > packageA, because packageA needs to get compiled (which involves > linking against libfoo and using libfoo's includes). I know that > packageA *does* compile (because I've done that already), but it won't > compile inside packageB's sandbox. > > Any suggestions? > > Richard From imantc at gmail.com Tue Oct 27 18:52:27 2015 From: imantc at gmail.com (Imants Cekusins) Date: Tue, 27 Oct 2015 19:52:27 +0100 Subject: [Haskell-cafe] Cabal depend on local package with foreign dependencies In-Reply-To: <1445971052-sup-8889@sabre> References: <85si4wmjrp.wl-richard.lewis@gold.ac.uk> <1445971052-sup-8889@sabre> Message-ID: Try to run this from packageB dir: "cabal sandbox add-source {path to C}" Then install packageA from B Also maybe try to run "cabal install packageC" from packageB - this may not be necessary. Btw separate sandboxes - one per each project - work just fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Tue Oct 27 18:55:47 2015 From: imantc at gmail.com (Imants Cekusins) Date: Tue, 27 Oct 2015 19:55:47 +0100 Subject: [Haskell-cafe] Cabal depend on local package with foreign dependencies In-Reply-To: References: <85si4wmjrp.wl-richard.lewis@gold.ac.uk> <1445971052-sup-8889@sabre> Message-ID: ... first build & copy C ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.lewis at gold.ac.uk Tue Oct 27 19:08:10 2015 From: richard.lewis at gold.ac.uk (Richard Lewis) Date: Tue, 27 Oct 2015 19:08:10 +0000 Subject: [Haskell-cafe] Cabal depend on local package with foreign dependencies In-Reply-To: <1445971052-sup-8889@sabre> References: <85si4wmjrp.wl-richard.lewis@gold.ac.uk> <1445971052-sup-8889@sabre> Message-ID: <85h9lcm8o5.wl-richard.lewis@gold.ac.uk> Hi Edward, Hmm, well packageA's testA definitely *does* build without needing include-dirs. But I've tried inserting it in case it makes a difference for packageB; it doesn't. But I'm now looking at the errors more carefully (and using verbose cabal output). As pacakgeA was written some time ago, I'd forgotten that it uses hsc. And it's actually the hsc source file which is breaking when pacakgeB attempts to build pacakgeA. Now, I think I've just worked out what's going on here. Typically, I'd abstracted away one very important detail: the "other-modules" options in my .cabal file. The module that's failing to compile is a non-exposed module of packageA. Because it was non-exposed, I was listing it as an "other-modules" requirement of the executable testA. I think, therefore, that when pacakgeB tried to build testA, it ended up trying to build it without the necessary includes. So I've tried making this other module also exposed. (It's not ideally what I'd like, but maybe I'll learn to live with it.) And now packageB is able to build packageA in its sandbox. Richard On Tue, 27 Oct 2015 18:38:29 +0000, Edward Z. Yang wrote: > > Hello Richard, > > I am not sure why package A builds in its own sandbox, but your > copypaste suggests that executable testA does not have an include-dirs > section which would tell it where to find foo.h. Could that be > the problem? > > Edward > > Excerpts from Richard Lewis's message of 2015-10-27 08:08:26 -0700: > > Hi there, > > > > I have two libraries that I'm working on, packageA and packageB. > > > > packageA was written some time ago and depends on a foreign C library, > > libfoo, which I also wrote and which is installed in a non-standard > > location. packageB depends on packageA and is new and under active > > development. > > > > I have the following things, then: > > > > - libfoo is installed in ~/.local/lib, with includes in ~/.local/include/foo > > - packageA is in ~/src/packageA > > - packageB is in ~/src/packageB > > > > packageA has a .cabal file which includes: > > > > library > > build-depends: base, ... > > exposed-modules: A > > include-dirs: /home/richard/.local/include > > extra-lib-dirs: /home/richard/.local/lib > > > > executable testA > > ... > > extra-lib-dirs: /home/richard/.local/lib > > extra-libraries: foo > > > > I've created a cabal sandbox in packageA and I can successfully build > > it. > > > > Now, packageB makes use of packageA. It has a .cabal file which looks > > like this: > > > > library > > build-depends: base, packageA, ... > > exposed-modules: B > > > > executable testB > > ... > > extra-lib-dirs: /home/richard/.local/lib > > extra-libraries: foo > > > > Again, I've created a cabal sandbox in packageB. In order to be able > > to use packageA (which is not installed anywhere) I believe I have to > > do: > > > > $ cabal add-source ~/src/packageA > > > > Next, when I try and configure, it says: > > > > cabal: At least the following dependencies are missing: > > packageA -any > > > > That's fine, I assume, because I can now just `cabal install > > --only-dependencies` to get packageA built into packageB's > > sandbox. But when I try and do this, I get: > > > > $ cabal install --only-dependencies > > Resolving dependencies... > > Configuring packageA-0.1... > > Building packageA-0.1... > > Preprocessing library packageA-0.1... > > In-place registering packageA-0.1... > > Preprocessing executable 'testA' for packageA-0.1... > > Foo.hsc:10:33: fatal error: foo/foo.h: No such file or directory > > compilation terminated. > > > > So a target of packageA which compiles fine when doing cabal build > > directly from packageA now fails to compile when I attempt to build it > > from packageB by installing packageB's dependencies. > > > > I'm not sure how to proceed. It feels like maybe I have to tell > > cabal--when running it from packageB--where the include files are for > > packageA, because packageA needs to get compiled (which involves > > linking against libfoo and using libfoo's includes). I know that > > packageA *does* compile (because I've done that already), but it won't > > compile inside packageB's sandbox. > > > > Any suggestions? > > > > Richard From amindfv at gmail.com Tue Oct 27 20:37:59 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Tue, 27 Oct 2015 16:37:59 -0400 Subject: [Haskell-cafe] No warn on type in expression? Message-ID: <55592177-BBD2-4640-A92C-0B678CA54A02@gmail.com> An expression like: x = 5 :: Int Fails with -Wall -Werror, with "Top-level binding with no type signature". I propose we don't warn on bindings whose entire expressions are typed. This cuts in half the line noise for trivial variable values. Tom From alan.zimm at gmail.com Tue Oct 27 21:18:36 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 27 Oct 2015 23:18:36 +0200 Subject: [Haskell-cafe] haskell-ide repository name Message-ID: At the moment the repository/project is called haskell-ide This leads to the impression that it is an IDE. It is actually a backend/server to provide services for an IDE We are considering changing the name. The options are haskides / ghc-ide-daemon / ghc-ide-service / ghc-ide-engine Please cast your vote at http://strawpoll.me/5842105 Thanks Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From defigueiredo at ucdavis.edu Tue Oct 27 23:25:18 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Tue, 27 Oct 2015 17:25:18 -0600 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting In-Reply-To: References: <20151026135522.GA2792@Magus.sf-private> <562E5698.4050907@ucdavis.edu> Message-ID: <563007DE.2040904@ucdavis.edu> Here's a final pipes example then. I don't think there's a way to fix the problem as Oleg proposed because pipes are monad transformers by design. The Pipe monad transformer augments the base monad with two operations: - await: gets a result from an upstream pipe - yield: sends a result to a downstream pipe I have a producer (which is a pipe that can only 'yield') that produces the lines of the .CSV file as Strings and returns () when done: getFileContentsLifted :: Producer String IO () getFileContentsLifted = withCSVLifted "data.csv" myReadFile where myReadFile :: Handle -> Producer String IO () myReadFile handle = do eof <- lift $ hIsEOF handle unless eof $ do str <- lift $ hGetLine handle yield str myReadFile handle I then have a simple pipeline that reads each line and prints it twice: lineDoubler :: Pipe String String IO () lineDoubler = forever $ do s <- await yield s yield s main = do runEffect $ getFileContentsLifted >-> lineDoubler >-> stdoutLn The problem as before is that this code does not work with the original version of withCSV: withCSV :: FilePath -> (Handle -> IO r) -> IO r withCSV path action = do putStrLn "opening file" h <- openFile path ReadMode r <- action h hClose h putStrLn "file closed" return r only with the lifted (i.e. generalized) one. withCSVLifted :: MonadIO mIO => FilePath -> (Handle -> mIO r) -> mIO r withCSVLifted path action = do liftIO $ putStrLn "opening file" h <- liftIO $ openFile path ReadMode r <- action h liftIO $ hClose h liftIO $ putStrLn "file closed" return r And I have the same question: Should I always "generalize" my monadic actions that take callbacks as parameters? I hope this version is still clear. Thanks for everyone for their input. I thought this was an easier problem than it now appears to be. Dimitri PS. Full code is here https://gist.github.com/dimitri-xyz/f1f5bd4c0f7f2bf85379 On 10/26/15 10:47 AM, Kim-Ee Yeoh wrote: > > On Mon, Oct 26, 2015 at 11:36 PM, Dimitri DeFigueiredo > > wrote: > > I might have over simplified the problem by using ReaderT in my > example. In my original problem this role is played by the Pipes > library (and instead of using 'ask', I wanted to 'yield' control > to a downstream pipe). > > > Is there a way you could introduce just enough complexity to allow > Oleg another stab? > > Also, there's always the fallback of showing your Pipes-based code > although that library doesn't enjoy universal familiarity. > > -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Tue Oct 27 23:52:17 2015 From: lambda.fairy at gmail.com (Chris Wong) Date: Wed, 28 Oct 2015 12:52:17 +1300 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting In-Reply-To: <563007DE.2040904@ucdavis.edu> References: <20151026135522.GA2792@Magus.sf-private> <562E5698.4050907@ucdavis.edu> <563007DE.2040904@ucdavis.edu> Message-ID: Hi Dimitri, The implementation of `withCSVLifted` looks dodgy to me. If a downstream consumer terminates early, then the file will never get closed. For pipes, the standard solution to resource management is the pipes-safe[1] package. It handles early termination and IO exceptions automatically. The example in the docs should fit your use case pretty well. [1] https://hackage.haskell.org/package/pipes-safe-2.2.3/docs/Pipes-Safe.html On Wed, Oct 28, 2015 at 12:25 PM, Dimitri DeFigueiredo wrote: > Here's a final pipes example then. I don't think there's a way to fix the > problem as Oleg proposed because pipes are monad transformers by design. > > The Pipe monad transformer augments the base monad with two operations: > - await: gets a result from an upstream pipe > - yield: sends a result to a downstream pipe > > I have a producer (which is a pipe that can only 'yield') that produces the > lines of the .CSV file as Strings and returns () when done: > > getFileContentsLifted :: Producer String IO () > getFileContentsLifted = withCSVLifted "data.csv" myReadFile > where > myReadFile :: Handle -> Producer String IO () > myReadFile handle = do > eof <- lift $ hIsEOF handle > unless eof $ do > str <- lift $ hGetLine handle > yield str > myReadFile handle > > I then have a simple pipeline that reads each line and prints it twice: > > lineDoubler :: Pipe String String IO () > lineDoubler = forever $ do > s <- await > yield s > yield s > > main = do > runEffect $ getFileContentsLifted >-> lineDoubler >-> stdoutLn > > The problem as before is that this code does not work with the original > version of withCSV: > > withCSV :: FilePath -> (Handle -> IO r) -> IO r > withCSV path action = do > putStrLn "opening file" > h <- openFile path ReadMode > r <- action h > hClose h > putStrLn "file closed" > return r > > only with the lifted (i.e. generalized) one. > > withCSVLifted :: MonadIO mIO => FilePath -> (Handle -> mIO r) -> mIO r > withCSVLifted path action = do > liftIO $ putStrLn "opening file" > h <- liftIO $ openFile path ReadMode > r <- action h > liftIO $ hClose h > liftIO $ putStrLn "file closed" > return r > > And I have the same question: Should I always "generalize" my monadic > actions that take callbacks as parameters? > > I hope this version is still clear. Thanks for everyone for their input. I > thought this was an easier problem than it now appears to be. > > Dimitri > > PS. Full code is here > https://gist.github.com/dimitri-xyz/f1f5bd4c0f7f2bf85379 > > > On 10/26/15 10:47 AM, Kim-Ee Yeoh wrote: > > > On Mon, Oct 26, 2015 at 11:36 PM, Dimitri DeFigueiredo > wrote: >> >> I might have over simplified the problem by using ReaderT in my example. >> In my original problem this role is played by the Pipes library (and instead >> of using 'ask', I wanted to 'yield' control to a downstream pipe). > > > Is there a way you could introduce just enough complexity to allow Oleg > another stab? > > Also, there's always the fallback of showing your Pipes-based code although > that library doesn't enjoy universal familiarity. > > -- Kim-Ee > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Wong (https://lambda.xyz) "I fear that Haskell is doomed to succeed." -- Tony Hoare From defigueiredo at ucdavis.edu Wed Oct 28 00:02:19 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Tue, 27 Oct 2015 18:02:19 -0600 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting In-Reply-To: References: <20151026135522.GA2792@Magus.sf-private> <562E5698.4050907@ucdavis.edu> <563007DE.2040904@ucdavis.edu> Message-ID: <5630108B.3040109@ucdavis.edu> Hi Chris, You are right. The implementation is totally dodgy! In fact, Pipes already has fromHandle which does this properly. I'm just trying to come up with an example of an IO action that takes another IO action as a parameter and what to do about using that with a monad transformer such as pipes. My focus is what to do when you need to use an action such as withCSV with a action that is *not* in the IO monad. Dimitri On 10/27/15 5:52 PM, Chris Wong wrote: > Hi Dimitri, > > The implementation of `withCSVLifted` looks dodgy to me. If a > downstream consumer terminates early, then the file will never get > closed. > > For pipes, the standard solution to resource management is the > pipes-safe[1] package. It handles early termination and IO exceptions > automatically. The example in the docs should fit your use case pretty > well. > > [1] https://hackage.haskell.org/package/pipes-safe-2.2.3/docs/Pipes-Safe.html > > On Wed, Oct 28, 2015 at 12:25 PM, Dimitri DeFigueiredo > wrote: >> Here's a final pipes example then. I don't think there's a way to fix the >> problem as Oleg proposed because pipes are monad transformers by design. >> >> The Pipe monad transformer augments the base monad with two operations: >> - await: gets a result from an upstream pipe >> - yield: sends a result to a downstream pipe >> >> I have a producer (which is a pipe that can only 'yield') that produces the >> lines of the .CSV file as Strings and returns () when done: >> >> getFileContentsLifted :: Producer String IO () >> getFileContentsLifted = withCSVLifted "data.csv" myReadFile >> where >> myReadFile :: Handle -> Producer String IO () >> myReadFile handle = do >> eof <- lift $ hIsEOF handle >> unless eof $ do >> str <- lift $ hGetLine handle >> yield str >> myReadFile handle >> >> I then have a simple pipeline that reads each line and prints it twice: >> >> lineDoubler :: Pipe String String IO () >> lineDoubler = forever $ do >> s <- await >> yield s >> yield s >> >> main = do >> runEffect $ getFileContentsLifted >-> lineDoubler >-> stdoutLn >> >> The problem as before is that this code does not work with the original >> version of withCSV: >> >> withCSV :: FilePath -> (Handle -> IO r) -> IO r >> withCSV path action = do >> putStrLn "opening file" >> h <- openFile path ReadMode >> r <- action h >> hClose h >> putStrLn "file closed" >> return r >> >> only with the lifted (i.e. generalized) one. >> >> withCSVLifted :: MonadIO mIO => FilePath -> (Handle -> mIO r) -> mIO r >> withCSVLifted path action = do >> liftIO $ putStrLn "opening file" >> h <- liftIO $ openFile path ReadMode >> r <- action h >> liftIO $ hClose h >> liftIO $ putStrLn "file closed" >> return r >> >> And I have the same question: Should I always "generalize" my monadic >> actions that take callbacks as parameters? >> >> I hope this version is still clear. Thanks for everyone for their input. I >> thought this was an easier problem than it now appears to be. >> >> Dimitri >> >> PS. Full code is here >> https://gist.github.com/dimitri-xyz/f1f5bd4c0f7f2bf85379 >> >> >> On 10/26/15 10:47 AM, Kim-Ee Yeoh wrote: >> >> >> On Mon, Oct 26, 2015 at 11:36 PM, Dimitri DeFigueiredo >> wrote: >>> I might have over simplified the problem by using ReaderT in my example. >>> In my original problem this role is played by the Pipes library (and instead >>> of using 'ask', I wanted to 'yield' control to a downstream pipe). >> >> Is there a way you could introduce just enough complexity to allow Oleg >> another stab? >> >> Also, there's always the fallback of showing your Pipes-based code although >> that library doesn't enjoy universal familiarity. >> >> -- Kim-Ee >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendel at informatik.uni-tuebingen.de Wed Oct 28 00:05:05 2015 From: rendel at informatik.uni-tuebingen.de (Tillmann Rendel) Date: Wed, 28 Oct 2015 01:05:05 +0100 Subject: [Haskell-cafe] haskell-ide repository name In-Reply-To: References: Message-ID: <56301131.4050708@informatik.uni-tuebingen.de> Hi, Alan & Kim Zimmerman wrote: > The options are > > haskides / ghc-ide-daemon / ghc-ide-service / ghc-ide-engine > > Please cast your vote at http://strawpoll.me/5842105 ghc-service. Reasoning: If I understand correctly, this package provides ghc as a service to other processes. I expect that this service could be useful for non-IDEs. For example, I guess a hs-to-html tool could use this to hyperlink identifiers to their binding sites, but such a tool is not an IDE. Tillmann From lambda.fairy at gmail.com Wed Oct 28 02:31:24 2015 From: lambda.fairy at gmail.com (Chris Wong) Date: Wed, 28 Oct 2015 15:31:24 +1300 Subject: [Haskell-cafe] Why does disambiguation in RebindableSyntax sometimes requires type signatures? In-Reply-To: References: Message-ID: Hi Jan, Looks like the monomorphism restriction to me. This article [1] is a great explanation of this quirk. [1] http://lambda.jstolarek.com/2012/05/towards-understanding-haskells-monomorphism-restriction/ There are two solutions: 1. Add {-# LANGUAGE NoMonomorphismRestriction #-} to your code. 2. Give each binding explicit arguments: process = ... -- as before where m >>= k = m E.>>= k m >> n = m E.>> n return x = E.return x Since the monomorphism restriction doesn't apply to declarations with arguments, this change should make the bindings polymorphic again. Hope this helps. On Wed, Oct 28, 2015 at 3:14 AM, Jan Bracker wrote: > Hello, > > I am currently playing around with RebindableSyntax and having several > bind/return/sequence functions in scope at the same time. I thought that it > would be enough to just pick the right one to use in each do-block by using > a "where" or a "let". > Surprisingly, I get some type related issues I can only fix by adding in > some type signatures, but I don't understand why these signatures are > actually necessary. > > Here is my example program: > > {-# LANGUAGE RebindableSyntax #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE TypeOperators #-} > > import Prelude > import qualified Prelude as P > import qualified Control.Effect as E > import Control.Effect.State > > ifThenElse :: Bool -> a -> a -> a > ifThenElse True t e = t > ifThenElse False t e = e > > main :: IO () > main = do > return () > where > return = P.return > > data Tree = Leaf Int > | Branch Tree Tree > > process :: Tree -> State '[ "flatten" :-> Bool :! 'R ] (Either Tree [Int]) > process (Leaf i) = do > flatten <- get (Var :: (Var "flatten")) > if flatten > then return $ Right [i] > else return $ Left $ Leaf i > where --(>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) -> > State (E.Plus State f g) b > (>>=) = (E.>>=) > (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus > State f g) b > (>>) = (E.>>) > return = E.return > fail = E.fail > process (Branch tl tr) = do > eitherL <- process tl > eitherR <- process tr > case (eitherL, eitherR) of > (Left l, Left r) -> return $ Left $ Branch l r > (Right l, Right r) -> return $ Right $ l ++ r > where (>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) -> State > (E.Plus State f g) b > (>>=) = (E.>>=) > (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus > State f g) b > (>>) = (E.>>) > return = E.return > fail = E.fail > > The program uses the "effect-monad" package in version 0.6.1. > > 1) The type signatures in the "where" following each do-block of the > "process" function are required. If I remove the type signature of the > sequence functions I get a type error of the following nature: > > examples/effect/Test.hs:33:16: > Could not deduce (E.Inv m0 f0 g0) arising from a use of ?E.>>? > Relevant bindings include > (>>) :: m0 f0 a -> m0 g0 b -> m0 (E.Plus m0 f0 g0) b > (bound at examples/effect/Test.hs:33:9) > In the expression: (E.>>) > In an equation for ?>>?: (>>) = (E.>>) > In an equation for ?process?: > process (Leaf i) > = do { flatten <- get (Var :: Var "flatten"); > if flatten then return $ Right [...] else return $ Left $ > Leaf i } > where > (>>=) = (E.>>=) > (>>) = (E.>>) > return = E.return > fail = E.fail > > examples/effect/Test.hs:33:16: > No instance for (E.Effect m0) arising from a use of ?E.>>? > In the expression: (E.>>) > In an equation for ?>>?: (>>) = (E.>>) > In an equation for ?process?: > process (Leaf i) > = do { flatten <- get (Var :: Var "flatten"); > if flatten then return $ Right [...] else return $ Left $ > Leaf i } > where > (>>=) = (E.>>=) > (>>) = (E.>>) > return = E.return > fail = E.fail > > Which I interpret as the inability to infer the "E.Effect" and "E.Inv" > constraints that are implied by the use of "E.>>". But why can't those > constraints be inferred correctly? Shouldn't a definition like "(>>) = > (E.>>)" just propagate the type signature and specialize it as needed? > > 2) If I remove the type signature for the bind operation, I get the > following type error: > > examples/effect/Test.hs:38:3: > Couldn't match type ?'["flatten" :-> (Bool :! 'R)]? with ?'[]? > Expected type: State > '["flatten" :-> (Bool :! 'R)] (Either Tree [Int]) > -> (Either Tree [Int] -> State '[] (Either Tree [Int])) > -> State '[] (Either Tree [Int]) > Actual type: State > '["flatten" :-> (Bool :! 'R)] (Either Tree [Int]) > -> (Either Tree [Int] -> State '[] (Either Tree [Int])) > -> State > (E.Plus State '["flatten" :-> (Bool :! 'R)] '[]) > (Either Tree [Int]) > In a stmt of a 'do' block: eitherR <- process tr > In the expression: > do { eitherL <- process tl; > eitherR <- process tr; > case (eitherL, eitherR) of { > (Left l, Left r) -> return $ Left $ Branch l r > (Right l, Right r) -> return $ Right $ l ++ r } } > In an equation for ?process?: > process (Branch tl tr) > = do { eitherL <- process tl; > eitherR <- process tr; > case (eitherL, eitherR) of { > (Left l, Left r) -> return $ Left $ Branch l r > (Right l, Right r) -> return $ Right $ l ++ r } } > where > (>>=) = (E.>>=) > (>>) :: > (E.Inv State f g) => > State f a -> State g b -> State (E.Plus State f g) b > (>>) = (E.>>) > return = E.return > > Which tells me that GHC is expecting the wrong type, but inferring the > correct type. Again I don't see why this wrong type is expected and the > right type is ignored. > > In either case, why does adding or removing the type signature for the local > definitions make a difference at all? I suspect the issue has to do with the > language extensions I enabled or the type-level computations that are done > by the "effect-monad" package, but I cannot find a satisfying answer. Does > anybody have a good explanation? > > I am working with GHC 7.10.2. > > Best, > Jan > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Wong (https://lambda.xyz) "I fear that Haskell is doomed to succeed." -- Tony Hoare From r.wobben at home.nl Wed Oct 28 06:37:38 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 28 Oct 2015 07:37:38 +0100 Subject: [Haskell-cafe] asked for a mentor for some math exercises Message-ID: <56306D32.1040701@home.nl> Hello, I try to learn Haskell by the Craft of Functional programming book. But on Chapter 4 Designing there are a lot of very math questions which I do not understand. Is there someone who wants to be a volunteerbasis a mentor for me for this sort of problems. Regards, Roelof From ivan.miljenovic at gmail.com Wed Oct 28 07:05:39 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 28 Oct 2015 18:05:39 +1100 Subject: [Haskell-cafe] haskell-ide repository name In-Reply-To: <56301131.4050708@informatik.uni-tuebingen.de> References: <56301131.4050708@informatik.uni-tuebingen.de> Message-ID: On 28 October 2015 at 11:05, Tillmann Rendel wrote: > Hi, > > Alan & Kim Zimmerman wrote: >> >> The options are >> >> haskides / ghc-ide-daemon / ghc-ide-service / ghc-ide-engine >> >> Please cast your vote at http://strawpoll.me/5842105 > > > ghc-service. > > Reasoning: If I understand correctly, this package provides ghc as a service > to other processes. I expect that this service could be useful for non-IDEs. > For example, I guess a hs-to-html tool could use this to hyperlink > identifiers to their binding sites, but such a tool is not an IDE. +1 Or you could expand it out a bit and get GHC-as-a-Service, or GaaS ;-) Is this envisaged to be just a daemon/service, or also a library that can be used (e.g. a nicer abstraction over trying to use GHC's internals to parse Haskell code, etc.)? > > Tillmann > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From s.j.thompson at kent.ac.uk Wed Oct 28 07:17:42 2015 From: s.j.thompson at kent.ac.uk (Simon Thompson) Date: Wed, 28 Oct 2015 07:17:42 +0000 Subject: [Haskell-cafe] haskell-ide repository name In-Reply-To: <56301131.4050708@informatik.uni-tuebingen.de> References: <56301131.4050708@informatik.uni-tuebingen.de> Message-ID: +1 > On 28 Oct 2015, at 00:05, Tillmann Rendel wrote: > > Hi, > > Alan & Kim Zimmerman wrote: >> The options are >> >> haskides / ghc-ide-daemon / ghc-ide-service / ghc-ide-engine >> >> Please cast your vote at http://strawpoll.me/5842105 > > ghc-service. > > Reasoning: If I understand correctly, this package provides ghc as a service to other processes. I expect that this service could be useful for non-IDEs. For example, I guess a hs-to-html tool could use this to hyperlink identifiers to their binding sites, but such a tool is not an IDE. > > Tillmann > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt From palotai.robin at gmail.com Wed Oct 28 11:18:53 2015 From: palotai.robin at gmail.com (Robin Palotai) Date: Wed, 28 Oct 2015 11:18:53 +0000 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting In-Reply-To: <5630108B.3040109@ucdavis.edu> References: <20151026135522.GA2792@Magus.sf-private> <562E5698.4050907@ucdavis.edu> <563007DE.2040904@ucdavis.edu> <5630108B.3040109@ucdavis.edu> Message-ID: I'm shooting in the dark, but isn't monad-control's liftBaseWith supposed to address such situations? https://hackage.haskell.org/package/monad-control-1.0.0.4/docs/Control-Monad-Trans-Control.html#g:3 Robin Dimitri DeFigueiredo ezt ?rta (id?pont: 2015. okt. 28., Sze, 1:02): > Hi Chris, > > You are right. The implementation is totally dodgy! In fact, Pipes already > has fromHandle which does this properly. I'm just trying to come up with > an example of an IO action that takes another IO action as a parameter and > what to do about using that with a monad transformer such as pipes. My > focus is what to do when you need to use an action such as withCSV with a > action that is *not* in the IO monad. > > > Dimitri > > > On 10/27/15 5:52 PM, Chris Wong wrote: > > Hi Dimitri, > > The implementation of `withCSVLifted` looks dodgy to me. If a > downstream consumer terminates early, then the file will never get > closed. > > For pipes, the standard solution to resource management is the > pipes-safe[1] package. It handles early termination and IO exceptions > automatically. The example in the docs should fit your use case pretty > well. > > [1] https://hackage.haskell.org/package/pipes-safe-2.2.3/docs/Pipes-Safe.html > > On Wed, Oct 28, 2015 at 12:25 PM, Dimitri DeFigueiredo wrote: > > Here's a final pipes example then. I don't think there's a way to fix the > problem as Oleg proposed because pipes are monad transformers by design. > > The Pipe monad transformer augments the base monad with two operations: > - await: gets a result from an upstream pipe > - yield: sends a result to a downstream pipe > > I have a producer (which is a pipe that can only 'yield') that produces the > lines of the .CSV file as Strings and returns () when done: > > getFileContentsLifted :: Producer String IO () > getFileContentsLifted = withCSVLifted "data.csv" myReadFile > where > myReadFile :: Handle -> Producer String IO () > myReadFile handle = do > eof <- lift $ hIsEOF handle > unless eof $ do > str <- lift $ hGetLine handle > yield str > myReadFile handle > > I then have a simple pipeline that reads each line and prints it twice: > > lineDoubler :: Pipe String String IO () > lineDoubler = forever $ do > s <- await > yield s > yield s > > main = do > runEffect $ getFileContentsLifted >-> lineDoubler >-> stdoutLn > > The problem as before is that this code does not work with the original > version of withCSV: > > withCSV :: FilePath -> (Handle -> IO r) -> IO r > withCSV path action = do > putStrLn "opening file" > h <- openFile path ReadMode > r <- action h > hClose h > putStrLn "file closed" > return r > > only with the lifted (i.e. generalized) one. > > withCSVLifted :: MonadIO mIO => FilePath -> (Handle -> mIO r) -> mIO r > withCSVLifted path action = do > liftIO $ putStrLn "opening file" > h <- liftIO $ openFile path ReadMode > r <- action h > liftIO $ hClose h > liftIO $ putStrLn "file closed" > return r > > And I have the same question: Should I always "generalize" my monadic > actions that take callbacks as parameters? > > I hope this version is still clear. Thanks for everyone for their input. I > thought this was an easier problem than it now appears to be. > > Dimitri > > PS. Full code is herehttps://gist.github.com/dimitri-xyz/f1f5bd4c0f7f2bf85379 > > > On 10/26/15 10:47 AM, Kim-Ee Yeoh wrote: > > > On Mon, Oct 26, 2015 at 11:36 PM, Dimitri DeFigueiredo wrote: > > > I might have over simplified the problem by using ReaderT in my example. > In my original problem this role is played by the Pipes library (and instead > of using 'ask', I wanted to 'yield' control to a downstream pipe). > > > > Is there a way you could introduce just enough complexity to allow Oleg > another stab? > > Also, there's always the fallback of showing your Pipes-based code although > that library doesn't enjoy universal familiarity. > > -- Kim-Ee > > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Wed Oct 28 11:46:05 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Wed, 28 Oct 2015 12:46:05 +0100 Subject: [Haskell-cafe] haskell-ide repository name In-Reply-To: References: <56301131.4050708@informatik.uni-tuebingen.de> Message-ID: <5630B57D.5090702@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 28/10/15 08:05, Ivan Lazar Miljenovic wrote: > Or you could expand it out a bit and get GHC-as-a-Service, or GaaS > ;-) Please just go with ghc-service. Any association with "SaaS" leaves a foul taste in my mouth... - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWMLV9AAoJENQqWdRUGk8BZd4QALBayggwmDP5rCOwPiT501Oc zFtB/XboKb2aQgI27NwrpKJiVikVGY/PxW1W8Wxupwc9irwBQYrdVHPYAUVXltji 5i0yHRdLsrmaGUzU1tfEGzYnzIvMMGfiUUC3qPFhaDSZRcTB8L44EGi5yQ2CHgrI 65dHIB/ybPNBjJo5gv5crwcN9ZpnVhu3UpvBo/0FRCRxH+BxfweFqGUQyuyKdKOu pEkklTZe/uSkEbzl48fTQQvtgqj9MTp0AEpk3wS2SEe6kat24WuLpNegtecX/m75 MqJqvQPbcCja5ut/yq2gcHPKpjm8z46OmS/ZDbXzVs1OcV2fIud42w7bjwZbvmKl OVHUSb01OgPa+gvgS58cskOSGnIGe93E2gU1p2ROYD3iefw0XkL6lq3BqnBNMUBR rQs83fu5PQFoMKP23e4r0t1A6lkOf0tsBlYU8N9/26QuehEq3LVayQ3k/nsR4RN6 jXY4Nl4MbLcHfyEnwNQYI/OlsU2WMN2mnsw9mOx8IPKVcHW34O/UyKO0RdrPQUbE KsrLbuGdYR14mqveYfqLPTL5PV4o36ZGQsa477le9OA7DaGw7zBskRLsxTMr/PV4 TVerii9pKcR1at38js2BbOv4KtgwwZoUnoIgZi/5/sATAg7ISFwNo6pRjBs1WI0H 9s0C8lT99kvksO8PXi08 =mJPW -----END PGP SIGNATURE----- From ky3 at atamo.com Wed Oct 28 12:41:10 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 28 Oct 2015 19:41:10 +0700 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: On Sun, Oct 25, 2015 at 1:17 PM, Janis Voigtl?nder < janis.voigtlaender at gmail.com> wrote: > Kim-Ee, I think you are overcomplicating things > No. Matteo cited a paper on traversables and you added a rejoinder. So it wasn't me who introduced data abstraction. Also, OP explicitly asked about a fold "on a set of data". Only later, when requested for an example, did he give lists. In fact, the discussion of "arbitrary data structures" (in this thread in > general) distracts a lot from the properties under consideration, and from > even first finding out whether they are properties of foldLike or of f in > foldLike f. > > So, let's specialize. Let's consider only the case of non-empty lists. > And look at what we have: A definitive answer to OP's question: Question: What is a fold of type "(a -> a -> a) -> [a] -> a" that promises to call its first parameter "associatively"? Answer: It is a fold equivalent to a fold1 (left or right, it doesn't matter). That's nice. But is that all we can come up with? Does it really do justice to the original question? Viz. "Is there a name for a fold that promises to call a function such that only an associative function will always return the same result. Or in other words, it has the property that it promises to call a function "associatively" on a set of data?" The challenge becomes: * generalize the result to fearsomely complicated "arbitrary data structures" * answer the original question in a holistic spirit > Then, candidate functions for "foldlike functions" will be functions of > this type: > > foldLike : (a -> a -> a) -> [a] -> a > > Here are some candidates (I give only an equation for four element lists > in each case, but I assume everyone has enough imagination to see how these > could be extended to other lists in an intended way): > > foldLike1 f [a,b,c,d] = [] -- throws away stuff > foldLike2 f [a,b,c,d] = f a (f b (f c d)) -- we have all ancountered this > one > foldLike3 f [a,b,c,d] = f (f (f a b) c) d -- also looks familiar > foldLike4 f [a,b,c,d] = f (f a b) (f c d) -- that's a "new" one, but looks > good > foldLike5 f [a,b,c,d] = f a a -- probably not a very popular one > foldLike6 f [a,b,c,d] = f (f c a) (f b d) -- a reasonable one, for example > there's a Traversable instance that leads to this one; but still, it's not > one that Charles would like, I think > > So now we can ask which of these satisfy Charles's 1., 2., 3. points. > Can't we? > > There was: > > > 1. Promises to call f on all data (does not have any guarantees on order) > > This is satisfied by foldLike2, foldLike3, foldLike4, and foldLike6, but > not by the others. > > > 2. Promises to call f on all data in order (like a left fold) > > This is satisfied by foldLike3, but not by the others. > > > 3. Promises to call f "associatively" (perhaps can be formalized as an > in order break down of the data into tree structures) > > This is satisfied by foldLike2, foldLike3, and foldLike4, but not by the > others. > > Since I am able to tell, for a given foldLike candidate, whether or not it > satisfies 3. (for example, I could specifically see that foldLike6 does not > satisfy 3., while it does satisfy 1.), it cannot be maintained that 3. has > no meaning. > > Note: Nothing in the above makes any assumptions about f. Whether or not f > is an associative function is irrelevant for what is asked here. > > > > > 2015-10-25 4:19 GMT+01:00 Kim-Ee Yeoh : > >> On Sun, Oct 25, 2015 at 1:12 AM, Janis Voigtl?nder < >> janis.voigtlaender at gmail.com> wrote: >> >>> It has already been established in this thread what Charles meant by 3. >>> >>> He meant that a fold-function that has the property he is after would >>> guarantee that it: >>> >>> a) takes all the content elements from a data structure, say x1,...,xn, >>> >>> b) builds an application tree with the to-be-folded, binary operation f >>> in the internal nodes of a binary tree, whose leafs, read from left to >>> right, form exactly the sequence x1,...,xn, >>> >>> c) evaluates that application tree. >>> >>> >> Isn't this what Charles meant by his 2nd property: >> >> > 2. Promises to call f on all data in order (like a left fold) >> >> What about his 3rd? >> >> Do you agree that what I describe above is a property of a given >>> fold-like function, not of the f handed to that fold-like function? >>> >> >> Before discussing a property of X, isnt it worth asking what X even means? >> >> The folds whose meanings are crystal clear are the arrows out of initial >> objects in the category of F-algebras. >> >> They are crystal clear because they couple as one with the data >> definition spelled out in full. >> >> In the quest for useful generalizations of catamorphisms, that coupling >> with the data definition continues to be assumed. >> >> Observe, for instance: >> >> > a) takes all the content elements from a data structure, say x1,...,xn, >> >> Does a foliar data structure have a canonical flattening out of its >> leaves? Are there symmetric canonicalizations? How is one selected over the >> others? >> >> Is the meaning of "all" referentially transparent? That turns out to be a >> subtle point, as this convo shows: >> >> >> http://haskell.1045720.n5.nabble.com/A-Proposed-Law-for-Foldable-tp5765339.html >> >> With the theory of F-algebras, we started with precise notions of data >> and folds came for free. >> >> But data can be overspecified. And also, the folds among swathes of data >> suggest useful generalizations. >> >> So now, a raft of proto-precise and necessarily psychological notions of >> Foldable waded in, and since then it's been fun playing sorting games with >> shape blocks and holes to squeeze them into. >> >> Fun is good. It's a stage in the journey to knowledge. >> >> >> And do you agree that what I describe above is a property that is weaker >>> than (and so, in particular different from) for example the property "this >>> fold-like function is foldl or foldr". >>> >> >> >> >>> >>> >>> >>> 2015-10-24 19:55 GMT+02:00 Kim-Ee Yeoh : >>> >>>> >>>> On Sun, Oct 25, 2015 at 12:42 AM, Matteo Acerbi < >>>> matteo.acerbi at gmail.com> wrote: >>>> >>>>> For what concerns question 3, I didn't understand the idea of calling >>>>> a function "associatively". >>>>> >>>> >>>> This. Associativity is a property of binary operators. It's not a >>>> property of the catamorphism 'calling' on a given binary operator. >>>> >>>> Also, when Charles writes: "Then it goes on to use f in "thisFold f >>>> [0,1,2]" like "f (1 (f 0 2))"" >>>> >>>> commutativity appears to raise its head. >>>> >>>> -- Kim-Ee >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Wed Oct 28 12:50:10 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Wed, 28 Oct 2015 13:50:10 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: Kim-Ee, I think you are overcomplicating things No. Your message contained lots of category-theory-speak that wasn?t called for. Question: What is a fold of type ?(a -> a -> a) -> [a] -> a? that promises to call its first parameter ?associatively?? Answer: It is a fold equivalent to a fold1 (left or right, it doesn?t matter). No, it seems you haven?t understood the answer. At least, that was not the answer. ? 2015-10-28 13:41 GMT+01:00 Kim-Ee Yeoh : > On Sun, Oct 25, 2015 at 1:17 PM, Janis Voigtl?nder < > janis.voigtlaender at gmail.com> wrote: > >> Kim-Ee, I think you are overcomplicating things >> > > No. > > Matteo cited a paper on traversables and you added a rejoinder. So it > wasn't me who introduced data abstraction. > > Also, OP explicitly asked about a fold "on a set of data". Only later, > when requested for an example, did he give lists. > > In fact, the discussion of "arbitrary data structures" (in this thread in >> general) distracts a lot from the properties under consideration, and from >> even first finding out whether they are properties of foldLike or of f in >> foldLike f. >> >> So, let's specialize. Let's consider only the case of non-empty lists. >> > > And look at what we have: A definitive answer to OP's question: > > Question: What is a fold of type "(a -> a -> a) -> [a] -> a" that promises > to call its first parameter "associatively"? > > Answer: It is a fold equivalent to a fold1 (left or right, it doesn't > matter). > > That's nice. > > But is that all we can come up with? Does it really do justice to the > original question? Viz. > > "Is there a name for a fold that promises to call a function such that > only an associative function will always return the same result. Or in > other words, it has the property that it promises to call a function > "associatively" on a set of data?" > > The challenge becomes: > > * generalize the result to fearsomely complicated "arbitrary data > structures" > * answer the original question in a holistic spirit > > > > > >> Then, candidate functions for "foldlike functions" will be functions of >> this type: >> >> foldLike : (a -> a -> a) -> [a] -> a >> >> Here are some candidates (I give only an equation for four element lists >> in each case, but I assume everyone has enough imagination to see how these >> could be extended to other lists in an intended way): >> >> foldLike1 f [a,b,c,d] = [] -- throws away stuff >> foldLike2 f [a,b,c,d] = f a (f b (f c d)) -- we have all ancountered this >> one >> foldLike3 f [a,b,c,d] = f (f (f a b) c) d -- also looks familiar >> foldLike4 f [a,b,c,d] = f (f a b) (f c d) -- that's a "new" one, but >> looks good >> foldLike5 f [a,b,c,d] = f a a -- probably not a very popular one >> foldLike6 f [a,b,c,d] = f (f c a) (f b d) -- a reasonable one, for >> example there's a Traversable instance that leads to this one; but still, >> it's not one that Charles would like, I think >> >> So now we can ask which of these satisfy Charles's 1., 2., 3. points. >> Can't we? >> >> There was: >> >> > 1. Promises to call f on all data (does not have any guarantees on >> order) >> >> This is satisfied by foldLike2, foldLike3, foldLike4, and foldLike6, but >> not by the others. >> >> > 2. Promises to call f on all data in order (like a left fold) >> >> This is satisfied by foldLike3, but not by the others. >> >> > 3. Promises to call f "associatively" (perhaps can be formalized as an >> in order break down of the data into tree structures) >> >> This is satisfied by foldLike2, foldLike3, and foldLike4, but not by the >> others. >> >> Since I am able to tell, for a given foldLike candidate, whether or not >> it satisfies 3. (for example, I could specifically see that foldLike6 does >> not satisfy 3., while it does satisfy 1.), it cannot be maintained that 3. >> has no meaning. >> >> Note: Nothing in the above makes any assumptions about f. Whether or not >> f is an associative function is irrelevant for what is asked here. >> >> >> >> >> 2015-10-25 4:19 GMT+01:00 Kim-Ee Yeoh : >> >>> On Sun, Oct 25, 2015 at 1:12 AM, Janis Voigtl?nder < >>> janis.voigtlaender at gmail.com> wrote: >>> >>>> It has already been established in this thread what Charles meant by 3. >>>> >>>> He meant that a fold-function that has the property he is after would >>>> guarantee that it: >>>> >>>> a) takes all the content elements from a data structure, say x1,...,xn, >>>> >>>> b) builds an application tree with the to-be-folded, binary operation f >>>> in the internal nodes of a binary tree, whose leafs, read from left to >>>> right, form exactly the sequence x1,...,xn, >>>> >>>> c) evaluates that application tree. >>>> >>>> >>> Isn't this what Charles meant by his 2nd property: >>> >>> > 2. Promises to call f on all data in order (like a left fold) >>> >>> What about his 3rd? >>> >>> Do you agree that what I describe above is a property of a given >>>> fold-like function, not of the f handed to that fold-like function? >>>> >>> >>> Before discussing a property of X, isnt it worth asking what X even >>> means? >>> >>> The folds whose meanings are crystal clear are the arrows out of initial >>> objects in the category of F-algebras. >>> >>> They are crystal clear because they couple as one with the data >>> definition spelled out in full. >>> >>> In the quest for useful generalizations of catamorphisms, that coupling >>> with the data definition continues to be assumed. >>> >>> Observe, for instance: >>> >>> > a) takes all the content elements from a data structure, say x1,...,xn, >>> >>> Does a foliar data structure have a canonical flattening out of its >>> leaves? Are there symmetric canonicalizations? How is one selected over the >>> others? >>> >>> Is the meaning of "all" referentially transparent? That turns out to be >>> a subtle point, as this convo shows: >>> >>> >>> http://haskell.1045720.n5.nabble.com/A-Proposed-Law-for-Foldable-tp5765339.html >>> >>> With the theory of F-algebras, we started with precise notions of data >>> and folds came for free. >>> >>> But data can be overspecified. And also, the folds among swathes of data >>> suggest useful generalizations. >>> >>> So now, a raft of proto-precise and necessarily psychological notions of >>> Foldable waded in, and since then it's been fun playing sorting games with >>> shape blocks and holes to squeeze them into. >>> >>> Fun is good. It's a stage in the journey to knowledge. >>> >>> >>> And do you agree that what I describe above is a property that is weaker >>>> than (and so, in particular different from) for example the property "this >>>> fold-like function is foldl or foldr". >>>> >>> >>> >>> >>>> >>>> >>>> >>>> 2015-10-24 19:55 GMT+02:00 Kim-Ee Yeoh : >>>> >>>>> >>>>> On Sun, Oct 25, 2015 at 12:42 AM, Matteo Acerbi < >>>>> matteo.acerbi at gmail.com> wrote: >>>>> >>>>>> For what concerns question 3, I didn't understand the idea of calling >>>>>> a function "associatively". >>>>>> >>>>> >>>>> This. Associativity is a property of binary operators. It's not a >>>>> property of the catamorphism 'calling' on a given binary operator. >>>>> >>>>> Also, when Charles writes: "Then it goes on to use f in "thisFold f >>>>> [0,1,2]" like "f (1 (f 0 2))"" >>>>> >>>>> commutativity appears to raise its head. >>>>> >>>>> -- Kim-Ee >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg at okmij.org Wed Oct 28 13:54:57 2015 From: oleg at okmij.org (Oleg) Date: Wed, 28 Oct 2015 22:54:57 +0900 Subject: [Haskell-cafe] best practice for lifting of IO and could lifting In-Reply-To: <562E5698.4050907@ucdavis.edu> Message-ID: <20151028135457.GA2310@Magus.sf-private> Just to finish beating this horse: let me explain why the function with the following signature is actually a bad idea. > withCSVLifted :: MonadIO mIO => FilePath -> (Handle -> mIO r) -> mIO r > withCSVLifted path action = do > liftIO $putStrLn "opening file" > h <- liftIO $ openFile path ReadMode > r <- action h > liftIO $ hClose h > liftIO $ putStrLn "file closed" > return r It accepts the callback that can do any MonadIO action, really any, including an action that throws an exception. If the callback 'action' throws an exception, who would close the CSV file? Further, the mIO action could do a non-deterministic choice. One may think of a such a choice as `forking' a lightweight `thread': m1 `mplus` m2 could be understood as forking a thread to execute m2, whereas the parent will execute m1. If the parent dies (if the m1 action or its consequences turned out unsuccessful), the child is awoken. The parent thread will eventually return through withCSVLifted and the CSV file will be closed. Suppose, the parent dies shortly after that. The child wakes up and tries to read from the Handle, which by that time will already be closed. (UNIX fork(2) does not have such problem because the OS duplicates not only the address space of the process but also all open file descriptors.) There is another problem with the withCSVLifted signature: the type of the return value is unrestricted. Therefore, r may be instantiated to Handle (or, more subtly, to the type of a closure containing a Handle), hence leaking the Handle out of the scope of withCSVLifted. The goal of withCSVLifted is to encapsulate a resource (file handle). Such encapsulation is far more difficult than it appears. I will recommend the old paper http://okmij.org/ftp/Haskell/regions.html#light-weight that illustrates these problems with simple approaches. It was a pleasant surprise that extensible effects (Haskell 2015 paper) turn out to implement monadic regions simpler than before. Please see Sec 7 of that paper (Freer monads, more extensible effects). The section also talks about the restrictions we have to impose on effects that are allowed to cross the region's boundary, so to speak. > pipes are monad transformers by design. That is regrettable. BTW, the Haskell 2015 paper describes the extensible-effect implementation of Reader and Writer effects. Those effects are more general than their name implies: Reader is actually an iteratee and Writer can write to a file. As to Monad Control, that was recently mentioned: there is a problem with them that is explained in Sec 6 of the Haskell 2015 paper. From marcin.jan.mrotek at gmail.com Wed Oct 28 19:05:22 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 28 Oct 2015 20:05:22 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: > > And look at what we have: A definitive answer to OP's question: > > Question: What is a fold of type "(a -> a -> a) -> [a] -> a" that promises > to call its first parameter "associatively"? > > Answer: It is a fold equivalent to a fold1 (left or right, it doesn't > matter). > > That's nice. > > But is that all we can come up with? Does it really do justice to the > original question? Viz. > Hello, Sorry for jumping into the thread, but I've read the previous responses, and I still don't get it (perhaps it's because I'm not a native English speaker): what does "associatively" mean in this context? From what I understand, "associativity" is a property of a function, that f (f a b) c = f a (f b c). Nothing more, nothing less. In order to encode this property in the type of a "fold" function, you'd need dependent types and a type-level proof that a given function is associative. Without dependent types, you can only trust the user to either supply an associative function, or accept wrong results (like REPA does). Am I missing something? Best regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Wed Oct 28 19:25:05 2015 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 28 Oct 2015 12:25:05 -0700 Subject: [Haskell-cafe] GHC can't find DLL dependencies on Windows Message-ID: I recently decided to try out a simple diagrams-cairo project on Windows 8 (x86_64) to discover that GHC (7.10.2, to be specific) acts rather bizarrely when dealing with external DLL dependencies. To start, I downloaded MSYS2 [1], installed the libraries needed for cairo and pango to work [2], installed diagrams-cairo [3], and tried running a simple diagrams program: module Main (main) where import Diagrams.Prelude import Diagrams.Backend.Cairo.CmdLine main :: IO () main = mainWith (circle 1 :: Diagram B) like so from MSYS2: runghc Cairo.hs -o circle.svg -w 400 And it worked. Hooray! Now, I normally use cmd.exe/PowerShell for most of my Windows command-line tasks, so later I tried invoking the above command on PowerShell, only to be greeted with an error message: $ runghc.exe .\Cairo.hs -o circle.svg -w 400 Cairo.hs: warning: _tzset from msvcrt is linked instead of __imp__tzset Cairo.hs: libcairo-2: The specified procedure could not be found. Cairo.hs: : can't load .so/.DLL for: libcairo-2.dll (addDLL: could not load DLL) PowerShell, alas, couldn't find libcairo-2.dll when MSYS2 had no trouble whatsoever. I realized that MSYS2 stores all of its MinGW-related DLL files in a special location (C:\msys64\mingw64\bin). This can be observed by running cygcheck on the executable: $ C:\msys64\usr\bin\cygcheck.exe .\Cairo.exe C:\Users\ryanscot\Documents\Hacking\Haskell\Cairo.exe cygcheck: track_down: could not find libcairo-2.dll cygcheck: track_down: could not find libglib-2.0-0.dll cygcheck: track_down: could not find libgobject-2.0-0.dll cygcheck: track_down: could not find libpango-1.0-0.dll cygcheck: track_down: could not find libpangocairo-1.0-0.dll ... After reading about DLL search paths in Windows [4], I got the impression that I could add C:\msys64\mingw64\bin to my PATH, and then executables would look for DLLs there. Adding C:\msys64\mingw64\bin to my PATH seemed to make cygcheck happy: $ C:\msys64\usr\bin\cygcheck.exe .\Cairo.exe C:\Users\ryanscot\Documents\Hacking\Haskell\Cairo.exe C:\msys64\mingw64\bin\libcairo-2.dll ... But invoking runghc Cairo.exe on PowerShell still fails with the same error message! For the life of me, I can't figure out what kind of sorcery MSYS2 is doing to make C:\msys64\mingw64\bin visible to the DLL search path from GHC. The only way I can trick PowerShell into seeing libcairo-2.dll is to (1) Copy libcairo-2.dll directly to C:\Windows\System32, or (2) Invoke SetDllDirectory("C:\msys64\mingw64\bin") [5] from a PowerShell startup script Neither of these options are very satisfying, since (1) has massive security implications, and (2) only works when you have one external DLL directory (if you called SetDllDirectory again with a different directory, it overrides the first one). I know there are folks out there who have managed to get diagrams working on Windows, so can someone let me know if I'm doing something wrong? Ryan S. ----- [1] http://msys2.github.io/ [2] pacman -S mingw-w64-x86_64-cairo mingw-w64-x86_64-pango 1.38.1-1 [3] cabal install diagrams-cairo [4] https://msdn.microsoft.com/en-us/library/ms682586.aspx#search_order_for_desktop_applications [5] https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203%28v=vs.85%29.aspx From janis.voigtlaender at gmail.com Wed Oct 28 19:25:08 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Wed, 28 Oct 2015 20:25:08 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: There is no point in trying to understand the concept from the name 'calling "associatively"' here. The "-signs around that word were there precisely because the OP didn't know what to call this. Also, nobody is trying to encode associativity in the type or anything like that. What the OP was essentially asking about (as I understand) was: How do I express (and how do I name) the property X of a fold-like function, whose (X's) intuitive meaning is: The fold-like function under consideration takes elements x1,...,xn from a data-structure in left-to-right order (so, let's assume the data structure is actually a list, so that there can be no doubt about what left-to-right means) and then builds a well-bracketed application expression with f on those elements, where the order of the x1,...,xn should not be changed. (So it would be okay for the fold-like function to decide to compute (((x1 `f` x2) `f` x3) `f` ... xn), it would also be okay for the fold-like function to decide to compute (((x1 `f` x2) `f` (x3 `f` x4)) `f` ... xn), but it would not be okay for the fold-like function to decide to compute ((((x2 `f` x3) `f` x1) `f` x4) `f` ... xn).) That is a property of the fold-like function, not a property of f. Also, it is not making an assumption about f being associative. It is just saying what the fold-like function should be allowed to do, and not allowed to do, given an arbitrary f. 2015-10-28 20:05 GMT+01:00 Marcin Mrotek : > And look at what we have: A definitive answer to OP's question: >> >> Question: What is a fold of type "(a -> a -> a) -> [a] -> a" that >> promises to call its first parameter "associatively"? >> >> Answer: It is a fold equivalent to a fold1 (left or right, it doesn't >> matter). >> >> That's nice. >> >> But is that all we can come up with? Does it really do justice to the >> original question? Viz. >> > > Hello, > > Sorry for jumping into the thread, but I've read the previous responses, > and I still don't get it (perhaps it's because I'm not a native English > speaker): what does "associatively" mean in this context? From what I > understand, "associativity" is a property of a function, that f (f a b) c = > f a (f b c). Nothing more, nothing less. In order to encode this property > in the type of a "fold" function, you'd need dependent types and a > type-level proof that a given function is associative. Without dependent > types, you can only trust the user to either supply an associative > function, or accept wrong results (like REPA does). Am I missing something? > > Best regards, > Marcin Mrotek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ratzes at gmail.com Wed Oct 28 19:26:12 2015 From: ratzes at gmail.com (Charles Durham) Date: Wed, 28 Oct 2015 15:26:12 -0400 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: I said "associatively" to be a place holder for a property I was trying to express, but unable to formalize. So yes, from what I understand associativity is a property of a function and has a formalization. As for the category theory, this is where I thought that this calling hierarchy might already be formalized in. I thought it would be nice to say something to the effect of "This fold has x property and exploits it to support parallelization". Obviously f does not need to be associative if the caller of the fold understands that only the x property is promised in the implementation. On Wed, Oct 28, 2015 at 3:05 PM, Marcin Mrotek wrote: > And look at what we have: A definitive answer to OP's question: >> >> Question: What is a fold of type "(a -> a -> a) -> [a] -> a" that >> promises to call its first parameter "associatively"? >> >> Answer: It is a fold equivalent to a fold1 (left or right, it doesn't >> matter). >> >> That's nice. >> >> But is that all we can come up with? Does it really do justice to the >> original question? Viz. >> > > Hello, > > Sorry for jumping into the thread, but I've read the previous responses, > and I still don't get it (perhaps it's because I'm not a native English > speaker): what does "associatively" mean in this context? From what I > understand, "associativity" is a property of a function, that f (f a b) c = > f a (f b c). Nothing more, nothing less. In order to encode this property > in the type of a "fold" function, you'd need dependent types and a > type-level proof that a given function is associative. Without dependent > types, you can only trust the user to either supply an associative > function, or accept wrong results (like REPA does). Am I missing something? > > Best regards, > Marcin Mrotek > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.jan.mrotek at gmail.com Wed Oct 28 20:15:57 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 28 Oct 2015 21:15:57 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: So you mean "associatively" meaning "the property that people usually ascribe to Foldable but that can't be expressed in Haskell type system, that the operation passed to foldMap "will be called with each and every element of the container but without ever commuting the elements"? In that case, I get it, but I'd consider it a case against the Foldable type class (i.e. that the type system is not able to express this property) or Haskell's type system, or just leave it be and consider it to be one of the things to be taken on faith. Best regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Wed Oct 28 21:31:52 2015 From: trebla at vex.net (Albert Y. C. Lai) Date: Wed, 28 Oct 2015 17:31:52 -0400 Subject: [Haskell-cafe] No warn on type in expression? In-Reply-To: <55592177-BBD2-4640-A92C-0B678CA54A02@gmail.com> References: <55592177-BBD2-4640-A92C-0B678CA54A02@gmail.com> Message-ID: <56313EC8.1030602@vex.net> On 2015-10-27 04:37 PM, amindfv at gmail.com wrote: > An expression like: > > x = 5 :: Int > > Fails with -Wall -Werror, with "Top-level binding with no type signature". I propose we don't warn on bindings whose entire expressions are typed. This cuts in half the line noise for trivial variable values. This will surprise you: module F where x = 5 :: Num a => a This does not make x polymorphic. Type annotation on RHS does not do the same thing as type signature for variable name. If you don't accept this, join the Haskell Prime committee or talk to someone who does. From marcin.jan.mrotek at gmail.com Wed Oct 28 21:45:57 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 28 Oct 2015 22:45:57 +0100 Subject: [Haskell-cafe] No warn on type in expression? In-Reply-To: <56313EC8.1030602@vex.net> References: <55592177-BBD2-4640-A92C-0B678CA54A02@gmail.com> <56313EC8.1030602@vex.net> Message-ID: Hello, Have a look at: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/other-type-extensions.html#scoped-type-variables TL;DR - pattern type signatures are not the same kind of an animal that declaration signatures are. This kind of an animal has already bitten me in the bottom, so I'm glad I can share the insight :) Best regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanmatthews1 at gmail.com Wed Oct 28 22:41:11 2015 From: seanmatthews1 at gmail.com (Sean Matthews) Date: Wed, 28 Oct 2015 23:41:11 +0100 Subject: [Haskell-cafe] installing GSL packages on Windows Message-ID: I'm currently trying to install the gsl packages (in particular hmatrix-gsl) for a Windows 7/32 system. I've been using a fairly stripped down version of the GHC for a while, but now that I'm trying to install packages like this, I'm running into problems. Anyway, I have installed pkg-config, etc. and I believe I've got the various bits of gsl installed. However cabal is still failing at attaching this to the appropriate haskell modules, at what looks to be very near the end, and suggstions for what I can try to get things to finish would be welcome. Below is the output as generated by cabal (this is the result of several iterations and systematic googling, but google seems to have run out on me). All suggestions, advice, etc. very welcome, Sean Matthews > cabal install hmatrix-gsl --extra-include-dirs="C:\Users\sematthews\My Software\gsl-1.15-dev-win32\include" --extra-lib-dirs="C:\Users\sematthews\My Software\gsl-1.15-dev-win32\lib" > cabal install hmatrix-gsl --extra-include-dirs="C:\Users\sematthews\My Software\gsl-1.15-dev-win32\include" --extra-lib-dirs="C:\Users\sematthews\My Software\gsl-1.15-dev-win32\lib" > Resolving dependencies... > Configuring hmatrix-gsl-0.17.0.0... > Building hmatrix-gsl-0.17.0.0... > Failed to install hmatrix-gsl-0.17.0.0 > Build log ( C:\Users\sematthews\AppData\Roaming\cabal\logs\hmatrix-gsl-0.17.0.0.log ): > Building hmatrix-gsl-0.17.0.0... > Preprocessing library hmatrix-gsl-0.17.0.0... > [ 1 of 17] Compiling Graphics.Plot ( src\Graphics\Plot.hs, dist\build\Graphics\Plot.o ) > [ 2 of 17] Compiling Numeric.GSL.Internal ( src\Numeric\GSL\Internal.hs, dist\build\Numeric\GSL\Internal.o ) > [ 3 of 17] Compiling Numeric.GSL.Integration ( src\Numeric\GSL\Integration.hs, dist\build\Numeric\GSL\Integration.o ) > [ 4 of 17] Compiling Numeric.GSL.Fourier ( src\Numeric\GSL\Fourier.hs, dist\build\Numeric\GSL\Fourier.o ) > [ 5 of 17] Compiling Numeric.GSL.Polynomials ( src\Numeric\GSL\Polynomials.hs, dist\build\Numeric\GSL\Polynomials.o ) > [ 6 of 17] Compiling Numeric.GSL.Minimization ( src\Numeric\GSL\Minimization.hs, dist\build\Numeric\GSL\Minimization.o ) > [ 7 of 17] Compiling Numeric.GSL.Root ( src\Numeric\GSL\Root.hs, dist\build\Numeric\GSL\Root.o ) > [ 8 of 17] Compiling Numeric.GSL.Fitting ( src\Numeric\GSL\Fitting.hs, dist\build\Numeric\GSL\Fitting.o ) > [ 9 of 17] Compiling Numeric.GSL.ODE ( src\Numeric\GSL\ODE.hs, dist\build\Numeric\GSL\ODE.o ) > [10 of 17] Compiling Numeric.GSL.Interpolation ( src\Numeric\GSL\Interpolation.hs, dist\build\Numeric\GSL\Interpolation.o ) > [11 of 17] Compiling Numeric.GSL.LinearAlgebra ( src\Numeric\GSL\LinearAlgebra.hs, dist\build\Numeric\GSL\LinearAlgebra.o ) > [12 of 17] Compiling Numeric.GSL.SimulatedAnnealing ( src\Numeric\GSL\SimulatedAnnealing.hs, dist\build\Numeric\GSL\SimulatedAnnealing.o ) > [13 of 17] Compiling Numeric.GSL.Vector ( src\Numeric\GSL\Vector.hs, dist\build\Numeric\GSL\Vector.o ) > [14 of 17] Compiling Numeric.GSL.IO ( src\Numeric\GSL\IO.hs, dist\build\Numeric\GSL\IO.o ) > [15 of 17] Compiling Numeric.GSL.Random ( src\Numeric\GSL\Random.hs, dist\build\Numeric\GSL\Random.o ) > [16 of 17] Compiling Numeric.GSL.Differentiation ( src\Numeric\GSL\Differentiation.hs, dist\build\Numeric\GSL\Differentiation.o ) > [17 of 17] Compiling Numeric.GSL ( src\Numeric\GSL.hs, dist\build\Numeric\GSL.o ) > In-place registering hmatrix-gsl-0.17.0.0... > setup-Simple-Cabal-1.22.4.0-i386-windows-ghc-7.10.2.exe: > 'C:\Users\sematthews\My Software\Haskell\bin\ghc-pkg.exe' exited with an > error: > hmatrix-gsl-0.17.0.0: Warning: haddock-interfaces: > C:\Users\SEMATT~1\AppData\Local\Temp\cabal-tmp-8196\hmatrix-gsl-0.17.0.0\dist\doc\html\hmatrix-gsl\hmatrix-gsl.haddock > doesn't exist or isn't a file > hmatrix-gsl-0.17.0.0: Warning: haddock-html: > C:\Users\SEMATT~1\AppData\Local\Temp\cabal-tmp-8196\hmatrix-gsl-0.17.0.0\dist\doc\html\hmatrix-gsl > doesn't exist or isn't a directory > hmatrix-gsl-0.17.0.0: library-dirs: /usr/local/lib is a relative path which > makes no sense (as there is nothing for it to be relative to). You can make > paths relative to the package database itself by using ${pkgroot}. (use > --force to override) > hmatrix-gsl-0.17.0.0: include-dirs: /usr/local/include is a relative path > which makes no sense (as there is nothing for it to be relative to). You can > make paths relative to the package database itself by using ${pkgroot}. (use > --force to override) > cabal: Error: some packages failed to install: > hmatrix-gsl-0.17.0.0 failed during the building phase. The exception was: > ExitFailure 1 -- Sean Matthews seanmatthews1 at gmail.com / +49 1515 800 1901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Wed Oct 28 23:19:27 2015 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 28 Oct 2015 16:19:27 -0700 Subject: [Haskell-cafe] GHC can't find DLL dependencies on Windows Message-ID: Never mind, I figured it out. Previously, I had been placing C:\msys64\mingw64\bin at the end of my user PATH. It turns out that my PATH was in fact on the DLL search path, but for some reason, an earlier directory on my PATH was causing problems. I can't exactly pinpoint what was causing the problem, but after moving C:\msys64\mingw64\bin to the start of my system PATH, I can run Haskell executables in PowerShell/cmd.exe without a problem. Ryan S. From ky3 at atamo.com Thu Oct 29 01:34:16 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Thu, 29 Oct 2015 08:34:16 +0700 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: On Wed, Oct 28, 2015 at 7:50 PM, Janis Voigtl?nder < janis.voigtlaender at gmail.com> wrote: > > Your message contained lots of category-theory-speak that wasn?t called > for. > Wait, what? You're alluding to my mention of F-algebras? Now I know that your discussion with Matteo that cited two papers is pertinent and also kinda off on the side. As we both know, those papers go far deeper into CT than F-algebras, which is like, baby stuff in comparison. Baby stuff that they are, F-algebras are nice because it's a theory of data where the folds fall out for free. It's a rock solid theory in a sea of nebulous generalizations about fold. That's why I mentioned them. Question: What is a fold of type ?(a -> a -> a) -> [a] -> a? that promises > to call its first parameter ?associatively?? > > Answer: It is a fold equivalent to a fold1 (left or right, it doesn?t > matter). > > No, it seems you haven?t understood the answer. At least, that was not the > answer. > Well, look. I thought otherwise, but I may be wrong. I frequently am. And if I am wrong, I want to be put right. Let's examine the facts. In an earlier response to Tom, you wrote: 'So, for the special case of non-empty lists, how about expressing the desired property as follows: "The function h must satisfy: for all associative f and all lists xs, it holds that h f xs = foldl1 f xs."' I thought impeccable the logic you used to arrive at this. Over two eta-contractions, I get h = foldl. The folds are monotyped, the lists finite, and so foldl = foldr. Putting it all together, finally: The property of the fold in question is that it is equivalent to a fold (left or right, it doesn't matter which). > ? > > 2015-10-28 13:41 GMT+01:00 Kim-Ee Yeoh : > >> On Sun, Oct 25, 2015 at 1:17 PM, Janis Voigtl?nder < >> janis.voigtlaender at gmail.com> wrote: >> >>> Kim-Ee, I think you are overcomplicating things >>> >> >> No. >> >> Matteo cited a paper on traversables and you added a rejoinder. So it >> wasn't me who introduced data abstraction. >> >> Also, OP explicitly asked about a fold "on a set of data". Only later, >> when requested for an example, did he give lists. >> >> In fact, the discussion of "arbitrary data structures" (in this thread in >>> general) distracts a lot from the properties under consideration, and from >>> even first finding out whether they are properties of foldLike or of f in >>> foldLike f. >>> >>> So, let's specialize. Let's consider only the case of non-empty lists. >>> >> >> And look at what we have: A definitive answer to OP's question: >> >> Question: What is a fold of type "(a -> a -> a) -> [a] -> a" that >> promises to call its first parameter "associatively"? >> >> Answer: It is a fold equivalent to a fold1 (left or right, it doesn't >> matter). >> >> That's nice. >> >> But is that all we can come up with? Does it really do justice to the >> original question? Viz. >> >> "Is there a name for a fold that promises to call a function such that >> only an associative function will always return the same result. Or in >> other words, it has the property that it promises to call a function >> "associatively" on a set of data?" >> >> The challenge becomes: >> >> * generalize the result to fearsomely complicated "arbitrary data >> structures" >> * answer the original question in a holistic spirit >> >> >> >> >> >>> Then, candidate functions for "foldlike functions" will be functions of >>> this type: >>> >>> foldLike : (a -> a -> a) -> [a] -> a >>> >>> Here are some candidates (I give only an equation for four element lists >>> in each case, but I assume everyone has enough imagination to see how these >>> could be extended to other lists in an intended way): >>> >>> foldLike1 f [a,b,c,d] = [] -- throws away stuff >>> foldLike2 f [a,b,c,d] = f a (f b (f c d)) -- we have all ancountered >>> this one >>> foldLike3 f [a,b,c,d] = f (f (f a b) c) d -- also looks familiar >>> foldLike4 f [a,b,c,d] = f (f a b) (f c d) -- that's a "new" one, but >>> looks good >>> foldLike5 f [a,b,c,d] = f a a -- probably not a very popular one >>> foldLike6 f [a,b,c,d] = f (f c a) (f b d) -- a reasonable one, for >>> example there's a Traversable instance that leads to this one; but still, >>> it's not one that Charles would like, I think >>> >>> So now we can ask which of these satisfy Charles's 1., 2., 3. points. >>> Can't we? >>> >>> There was: >>> >>> > 1. Promises to call f on all data (does not have any guarantees on >>> order) >>> >>> This is satisfied by foldLike2, foldLike3, foldLike4, and foldLike6, but >>> not by the others. >>> >>> > 2. Promises to call f on all data in order (like a left fold) >>> >>> This is satisfied by foldLike3, but not by the others. >>> >>> > 3. Promises to call f "associatively" (perhaps can be formalized as an >>> in order break down of the data into tree structures) >>> >>> This is satisfied by foldLike2, foldLike3, and foldLike4, but not by the >>> others. >>> >>> Since I am able to tell, for a given foldLike candidate, whether or not >>> it satisfies 3. (for example, I could specifically see that foldLike6 does >>> not satisfy 3., while it does satisfy 1.), it cannot be maintained that 3. >>> has no meaning. >>> >>> Note: Nothing in the above makes any assumptions about f. Whether or not >>> f is an associative function is irrelevant for what is asked here. >>> >>> >>> >>> >>> 2015-10-25 4:19 GMT+01:00 Kim-Ee Yeoh : >>> >>>> On Sun, Oct 25, 2015 at 1:12 AM, Janis Voigtl?nder < >>>> janis.voigtlaender at gmail.com> wrote: >>>> >>>>> It has already been established in this thread what Charles meant by 3. >>>>> >>>>> He meant that a fold-function that has the property he is after would >>>>> guarantee that it: >>>>> >>>>> a) takes all the content elements from a data structure, say x1,...,xn, >>>>> >>>>> b) builds an application tree with the to-be-folded, binary operation >>>>> f in the internal nodes of a binary tree, whose leafs, read from left to >>>>> right, form exactly the sequence x1,...,xn, >>>>> >>>>> c) evaluates that application tree. >>>>> >>>>> >>>> Isn't this what Charles meant by his 2nd property: >>>> >>>> > 2. Promises to call f on all data in order (like a left fold) >>>> >>>> What about his 3rd? >>>> >>>> Do you agree that what I describe above is a property of a given >>>>> fold-like function, not of the f handed to that fold-like function? >>>>> >>>> >>>> Before discussing a property of X, isnt it worth asking what X even >>>> means? >>>> >>>> The folds whose meanings are crystal clear are the arrows out of >>>> initial objects in the category of F-algebras. >>>> >>>> They are crystal clear because they couple as one with the data >>>> definition spelled out in full. >>>> >>>> In the quest for useful generalizations of catamorphisms, that coupling >>>> with the data definition continues to be assumed. >>>> >>>> Observe, for instance: >>>> >>>> > a) takes all the content elements from a data structure, say >>>> x1,...,xn, >>>> >>>> Does a foliar data structure have a canonical flattening out of its >>>> leaves? Are there symmetric canonicalizations? How is one selected over the >>>> others? >>>> >>>> Is the meaning of "all" referentially transparent? That turns out to be >>>> a subtle point, as this convo shows: >>>> >>>> >>>> http://haskell.1045720.n5.nabble.com/A-Proposed-Law-for-Foldable-tp5765339.html >>>> >>>> With the theory of F-algebras, we started with precise notions of data >>>> and folds came for free. >>>> >>>> But data can be overspecified. And also, the folds among swathes of >>>> data suggest useful generalizations. >>>> >>>> So now, a raft of proto-precise and necessarily psychological notions >>>> of Foldable waded in, and since then it's been fun playing sorting games >>>> with shape blocks and holes to squeeze them into. >>>> >>>> Fun is good. It's a stage in the journey to knowledge. >>>> >>>> >>>> And do you agree that what I describe above is a property that is >>>>> weaker than (and so, in particular different from) for example the property >>>>> "this fold-like function is foldl or foldr". >>>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> 2015-10-24 19:55 GMT+02:00 Kim-Ee Yeoh : >>>>> >>>>>> >>>>>> On Sun, Oct 25, 2015 at 12:42 AM, Matteo Acerbi < >>>>>> matteo.acerbi at gmail.com> wrote: >>>>>> >>>>>>> For what concerns question 3, I didn't understand the idea of >>>>>>> calling a function "associatively". >>>>>>> >>>>>> >>>>>> This. Associativity is a property of binary operators. It's not a >>>>>> property of the catamorphism 'calling' on a given binary operator. >>>>>> >>>>>> Also, when Charles writes: "Then it goes on to use f in "thisFold f >>>>>> [0,1,2]" like "f (1 (f 0 2))"" >>>>>> >>>>>> commutativity appears to raise its head. >>>>>> >>>>>> -- Kim-Ee >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendel at informatik.uni-tuebingen.de Thu Oct 29 05:53:29 2015 From: rendel at informatik.uni-tuebingen.de (Tillmann Rendel) Date: Thu, 29 Oct 2015 06:53:29 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: Message-ID: <5631B459.7090902@informatik.uni-tuebingen.de> Hi, Charles Durham wrote: > Is there a name for a fold that promises to call a function such that > only an associative function will always return the same result. Or in > other words, it has the property that it promises to call a function > "associatively" on a set of data? Semigroup homomorphism? Tillmann From janis.voigtlaender at gmail.com Thu Oct 29 06:27:05 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Thu, 29 Oct 2015 07:27:05 +0100 Subject: [Haskell-cafe] 'Associative' order of calling In-Reply-To: References: <20151023152157.GA25220@casa.casa> <20151023154903.GF16020@weber> Message-ID: > As we both know, those papers go far deeper into CT than F-algebras, which is like, baby stuff in comparison. Actually, one of the papers, the one I co-authored, does not go into category theory to any serious extent. I'd say to none extent at all, actually. Anyway, nothing of that is to say you are not "allowed" to bring CT into the discussion, of course. It just wasn't helpful to what was trying to be figured out. And as an aside, mention of F-algebras is not very relevant either *if* one tries to think about the Foldable class. That class is not about catamorphisms. Like, there isn't any F-algebra (for the base functor F of the Tree type constructor) in foldr : (a -> b -> b) -> b -> Tree a -> b. > In an earlier response to Tom, you wrote: > > 'So, for the special case of non-empty lists, how about expressing the desired property as follows: "The function h must satisfy: for all associative f and all lists xs, it holds that h f xs = foldl1 f xs."' > > I thought impeccable the logic you used to arrive at this. > > Over two eta-contractions, I get h = foldl. Are you sure you have read and respected all the forall-quantifiers in there? The statement "for all associative f and all lists xs, it holds that h f xs = foldl1 f xs" is *not* equivalent to the statement "for all f and all lists xs, it holds that h f xs = foldl1 f xs". The latter statement is equivalent (via eta-contractions) to "h = foldl", but the former isn't. Do I have to give a specific h to make this clearer? One which satisfies the first statement but is not equivalent to foldl or foldr. Actually, one was given already earlier in the conversation, to exactly the purpose of illuminating this whole point. 2015-10-29 2:34 GMT+01:00 Kim-Ee Yeoh : > On Wed, Oct 28, 2015 at 7:50 PM, Janis Voigtl?nder < > janis.voigtlaender at gmail.com> wrote: > >> >> Your message contained lots of category-theory-speak that wasn?t called >> for. >> > > > Wait, what? You're alluding to my mention of F-algebras? > > Now I know that your discussion with Matteo that cited two papers is > pertinent and also kinda off on the side. As we both know, those papers go > far deeper into CT than F-algebras, which is like, baby stuff in comparison. > > Baby stuff that they are, F-algebras are nice because it's a theory of > data where the folds fall out for free. It's a rock solid theory in a sea > of nebulous generalizations about fold. That's why I mentioned them. > > Question: What is a fold of type ?(a -> a -> a) -> [a] -> a? that promises >> to call its first parameter ?associatively?? >> >> Answer: It is a fold equivalent to a fold1 (left or right, it doesn?t >> matter). >> >> No, it seems you haven?t understood the answer. At least, that was not >> the answer. >> > > Well, look. I thought otherwise, but I may be wrong. I frequently am. And > if I am wrong, I want to be put right. Let's examine the facts. > > In an earlier response to Tom, you wrote: > > 'So, for the special case of non-empty lists, how about expressing the > desired property as follows: "The function h must satisfy: for all > associative f and all lists xs, it holds that h f xs = foldl1 f xs."' > > I thought impeccable the logic you used to arrive at this. > > Over two eta-contractions, I get h = foldl. > > The folds are monotyped, the lists finite, and so foldl = foldr. > > Putting it all together, finally: > > The property of the fold in question is that it is equivalent to a fold > (left or right, it doesn't matter which). > > > > > >> ? >> >> 2015-10-28 13:41 GMT+01:00 Kim-Ee Yeoh : >> >>> On Sun, Oct 25, 2015 at 1:17 PM, Janis Voigtl?nder < >>> janis.voigtlaender at gmail.com> wrote: >>> >>>> Kim-Ee, I think you are overcomplicating things >>>> >>> >>> No. >>> >>> Matteo cited a paper on traversables and you added a rejoinder. So it >>> wasn't me who introduced data abstraction. >>> >>> Also, OP explicitly asked about a fold "on a set of data". Only later, >>> when requested for an example, did he give lists. >>> >>> In fact, the discussion of "arbitrary data structures" (in this thread >>>> in general) distracts a lot from the properties under consideration, and >>>> from even first finding out whether they are properties of foldLike or of f >>>> in foldLike f. >>>> >>>> So, let's specialize. Let's consider only the case of non-empty lists. >>>> >>> >>> And look at what we have: A definitive answer to OP's question: >>> >>> Question: What is a fold of type "(a -> a -> a) -> [a] -> a" that >>> promises to call its first parameter "associatively"? >>> >>> Answer: It is a fold equivalent to a fold1 (left or right, it doesn't >>> matter). >>> >>> That's nice. >>> >>> But is that all we can come up with? Does it really do justice to the >>> original question? Viz. >>> >>> "Is there a name for a fold that promises to call a function such that >>> only an associative function will always return the same result. Or in >>> other words, it has the property that it promises to call a function >>> "associatively" on a set of data?" >>> >>> The challenge becomes: >>> >>> * generalize the result to fearsomely complicated "arbitrary data >>> structures" >>> * answer the original question in a holistic spirit >>> >>> >>> >>> >>> >>>> Then, candidate functions for "foldlike functions" will be functions of >>>> this type: >>>> >>>> foldLike : (a -> a -> a) -> [a] -> a >>>> >>>> Here are some candidates (I give only an equation for four element >>>> lists in each case, but I assume everyone has enough imagination to see how >>>> these could be extended to other lists in an intended way): >>>> >>>> foldLike1 f [a,b,c,d] = [] -- throws away stuff >>>> foldLike2 f [a,b,c,d] = f a (f b (f c d)) -- we have all ancountered >>>> this one >>>> foldLike3 f [a,b,c,d] = f (f (f a b) c) d -- also looks familiar >>>> foldLike4 f [a,b,c,d] = f (f a b) (f c d) -- that's a "new" one, but >>>> looks good >>>> foldLike5 f [a,b,c,d] = f a a -- probably not a very popular one >>>> foldLike6 f [a,b,c,d] = f (f c a) (f b d) -- a reasonable one, for >>>> example there's a Traversable instance that leads to this one; but still, >>>> it's not one that Charles would like, I think >>>> >>>> So now we can ask which of these satisfy Charles's 1., 2., 3. points. >>>> Can't we? >>>> >>>> There was: >>>> >>>> > 1. Promises to call f on all data (does not have any guarantees on >>>> order) >>>> >>>> This is satisfied by foldLike2, foldLike3, foldLike4, and foldLike6, >>>> but not by the others. >>>> >>>> > 2. Promises to call f on all data in order (like a left fold) >>>> >>>> This is satisfied by foldLike3, but not by the others. >>>> >>>> > 3. Promises to call f "associatively" (perhaps can be formalized as >>>> an in order break down of the data into tree structures) >>>> >>>> This is satisfied by foldLike2, foldLike3, and foldLike4, but not by >>>> the others. >>>> >>>> Since I am able to tell, for a given foldLike candidate, whether or not >>>> it satisfies 3. (for example, I could specifically see that foldLike6 does >>>> not satisfy 3., while it does satisfy 1.), it cannot be maintained that 3. >>>> has no meaning. >>>> >>>> Note: Nothing in the above makes any assumptions about f. Whether or >>>> not f is an associative function is irrelevant for what is asked here. >>>> >>>> >>>> >>>> >>>> 2015-10-25 4:19 GMT+01:00 Kim-Ee Yeoh : >>>> >>>>> On Sun, Oct 25, 2015 at 1:12 AM, Janis Voigtl?nder < >>>>> janis.voigtlaender at gmail.com> wrote: >>>>> >>>>>> It has already been established in this thread what Charles meant by >>>>>> 3. >>>>>> >>>>>> He meant that a fold-function that has the property he is after would >>>>>> guarantee that it: >>>>>> >>>>>> a) takes all the content elements from a data structure, say >>>>>> x1,...,xn, >>>>>> >>>>>> b) builds an application tree with the to-be-folded, binary operation >>>>>> f in the internal nodes of a binary tree, whose leafs, read from left to >>>>>> right, form exactly the sequence x1,...,xn, >>>>>> >>>>>> c) evaluates that application tree. >>>>>> >>>>>> >>>>> Isn't this what Charles meant by his 2nd property: >>>>> >>>>> > 2. Promises to call f on all data in order (like a left fold) >>>>> >>>>> What about his 3rd? >>>>> >>>>> Do you agree that what I describe above is a property of a given >>>>>> fold-like function, not of the f handed to that fold-like function? >>>>>> >>>>> >>>>> Before discussing a property of X, isnt it worth asking what X even >>>>> means? >>>>> >>>>> The folds whose meanings are crystal clear are the arrows out of >>>>> initial objects in the category of F-algebras. >>>>> >>>>> They are crystal clear because they couple as one with the data >>>>> definition spelled out in full. >>>>> >>>>> In the quest for useful generalizations of catamorphisms, that >>>>> coupling with the data definition continues to be assumed. >>>>> >>>>> Observe, for instance: >>>>> >>>>> > a) takes all the content elements from a data structure, say >>>>> x1,...,xn, >>>>> >>>>> Does a foliar data structure have a canonical flattening out of its >>>>> leaves? Are there symmetric canonicalizations? How is one selected over the >>>>> others? >>>>> >>>>> Is the meaning of "all" referentially transparent? That turns out to >>>>> be a subtle point, as this convo shows: >>>>> >>>>> >>>>> http://haskell.1045720.n5.nabble.com/A-Proposed-Law-for-Foldable-tp5765339.html >>>>> >>>>> With the theory of F-algebras, we started with precise notions of data >>>>> and folds came for free. >>>>> >>>>> But data can be overspecified. And also, the folds among swathes of >>>>> data suggest useful generalizations. >>>>> >>>>> So now, a raft of proto-precise and necessarily psychological notions >>>>> of Foldable waded in, and since then it's been fun playing sorting games >>>>> with shape blocks and holes to squeeze them into. >>>>> >>>>> Fun is good. It's a stage in the journey to knowledge. >>>>> >>>>> >>>>> And do you agree that what I describe above is a property that is >>>>>> weaker than (and so, in particular different from) for example the property >>>>>> "this fold-like function is foldl or foldr". >>>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2015-10-24 19:55 GMT+02:00 Kim-Ee Yeoh : >>>>>> >>>>>>> >>>>>>> On Sun, Oct 25, 2015 at 12:42 AM, Matteo Acerbi < >>>>>>> matteo.acerbi at gmail.com> wrote: >>>>>>> >>>>>>>> For what concerns question 3, I didn't understand the idea of >>>>>>>> calling a function "associatively". >>>>>>>> >>>>>>> >>>>>>> This. Associativity is a property of binary operators. It's not a >>>>>>> property of the catamorphism 'calling' on a given binary operator. >>>>>>> >>>>>>> Also, when Charles writes: "Then it goes on to use f in "thisFold f >>>>>>> [0,1,2]" like "f (1 (f 0 2))"" >>>>>>> >>>>>>> commutativity appears to raise its head. >>>>>>> >>>>>>> -- Kim-Ee >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djohnson.m at gmail.com Thu Oct 29 08:25:02 2015 From: djohnson.m at gmail.com (David Johnson) Date: Thu, 29 Oct 2015 03:25:02 -0500 Subject: [Haskell-cafe] Stripe-Haskell Updates ! Message-ID: *stripe-haskell 2.0* has been released on hackage. *The 2.0 release will entail the following:* - All types will now live in their own repository 'stripe-core' (for better use w/ ghcjs projects). - 'stripe-http-streams' is a specific http client backend for 'stripe-haskell' - Other backends (wreq, conduit, etc.) can be added. As always, pull requests welcome. - 'stripe-haskell' is now a virtual package that wraps 'stripe-http-streams' and 'stripe-core'. - We have a 'gitter' chat for our repo, to promote collaboration. - We now have a multi-ghc travis build that uses stack. - Jeremy Shaw has implemented a novel approach to the optional parameters problem using typeclasses. The docs will contain more information. - For existing stripe-haskell users version 2.0 is a breaking change, but it features a nicer interface due to Jeremy Shaw's changes. *Other notes:* - Existing 1.4 users will not be neglected. We can continue to submit patches up to 2.0. *Future goals:* - Migrate to servant-client ASAP. - Continue to beg Stripe for a machine readable specification that will relieve us from having to perform manual updates on subsequent API changes, and furthermore will allow us to fully take advantage of this wonderful service. Please respond here if you have questions, or visit our gitter at https://gitter.im/dmjio/stripe. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.drautzburg at web.de Thu Oct 29 09:01:49 2015 From: martin.drautzburg at web.de (martin) Date: Thu, 29 Oct 2015 10:01:49 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool Message-ID: <5631E07D.8090705@web.de> Hello all, I hope this is not a too silly question. It goes like this: Suppose I have a shape defined as (x,y,z) -> Bool how can I find a Point inside this shape? Obviously I could iterate through all possible x,y and z, but this appears very expensive. There may be no point at all at x=0. With brute force iteration I would have no clue that the False I am receiving with (0,1,1) is caused by x=0 and I may nedlessly try all combinations of y and z without ever receiving a True. Are there any alternative ways of finding points inside a shape? From anselm.scholl at tu-harburg.de Thu Oct 29 09:12:51 2015 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Thu, 29 Oct 2015 10:12:51 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: <5631E07D.8090705@web.de> References: <5631E07D.8090705@web.de> Message-ID: <5631E313.8040003@tu-harburg.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 You could try to use a data structure like a kd-tree, which can find the nearest neighbours to your point quite efficient. On 10/29/2015 10:01 AM, martin wrote: > Hello all, > > I hope this is not a too silly question. It goes like this: > > Suppose I have a shape defined as > > (x,y,z) -> Bool > > how can I find a Point inside this shape? Obviously I could iterate through all possible x,y and z, but this appears > very expensive. > > There may be no point at all at x=0. With brute force iteration I would have no clue that the False I am receiving with > (0,1,1) is caused by x=0 and I may nedlessly try all combinations of y and z without ever receiving a True. > > Are there any alternative ways of finding points inside a shape? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWMeMHAAoJEM0PYZBmfhoBcKUH/04/jSdP3660Ld1uWgK2P9BB iqAB4NnrRaCNbFNLSY6vNz1lFVm8p9ygxzZ4i+wfNbpa9V8tOvx2E2NJXaq/mLOr CDV9lS0LoQNWQCE41bH7QmEoK3ZiJjX1X0NolLpS2oBYhY1Jvwy/X8IUqoXAqZiu y+8CkExpJEL8dHmNXHwB4OmfRstRdcTumf/SVNhzwoHO+q+u8wz3d5PRSkCLSooB a5voFRdQpicfInzpW57+MHaQJtc1FtQ/+Ub4NQGh+rw5Npps/blQbvqgt/u1qcXL VwJqEonmF4T3NFxYAzfMR6rv/36MZcd39DK1+H2O5IrzIZXnXy007fw7irkiQ+0= =IIRy -----END PGP SIGNATURE----- From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu Oct 29 09:23:11 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 29 Oct 2015 09:23:11 +0000 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: <5631E07D.8090705@web.de> References: <5631E07D.8090705@web.de> Message-ID: <20151029092311.GB24042@weber> On Thu, Oct 29, 2015 at 10:01:49AM +0100, martin wrote: > I hope this is not a too silly question. It goes like this: > > Suppose I have a shape defined as > > (x,y,z) -> Bool > > how can I find a Point inside this shape? Obviously I could iterate through all possible x,y and z, but this appears > very expensive. There is no better way in general, so if you want to find points inside a shape you should use a different encoding of shapes. Tom From atzeus at gmail.com Thu Oct 29 09:23:35 2015 From: atzeus at gmail.com (Atze van der Ploeg) Date: Thu, 29 Oct 2015 10:23:35 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: <5631E313.8040003@tu-harburg.de> References: <5631E07D.8090705@web.de> <5631E313.8040003@tu-harburg.de> Message-ID: This representation ((x,y,z) _> bool) makes it very hard to find a point inside. Basically it does not give you any info: does the shape have area? What is it bounding box? Is it convex? Supposing x y and z are rationals (arbitrary precision), then all these questions are not computable. I suggest you use a different representation, such as a list of points for a polygon. On Oct 29, 2015 10:13 AM, "Jonas Scholl" wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > You could try to use a data structure like a kd-tree, which can find the > nearest neighbours to your point quite efficient. > > On 10/29/2015 10:01 AM, martin wrote: > > Hello all, > > I hope this is not a too silly question. It goes like > this: > > > Suppose I have a shape defined as > > (x,y,z) -> Bool > > how can I find > a Point inside this shape? Obviously I could iterate through all > possible x,y and z, but this appears > very expensive. > > There may be > no point at all at x=0. With brute force iteration I would have no clue > that the False I am receiving with > (0,1,1) is caused by x=0 and I may > nedlessly try all combinations of y and z without ever receiving a True. > > > Are there any alternative ways of finding points inside a shape? > > > _______________________________________________ > Haskell-Cafe mailing > list > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJWMeMHAAoJEM0PYZBmfhoBcKUH/04/jSdP3660Ld1uWgK2P9BB > iqAB4NnrRaCNbFNLSY6vNz1lFVm8p9ygxzZ4i+wfNbpa9V8tOvx2E2NJXaq/mLOr > CDV9lS0LoQNWQCE41bH7QmEoK3ZiJjX1X0NolLpS2oBYhY1Jvwy/X8IUqoXAqZiu > y+8CkExpJEL8dHmNXHwB4OmfRstRdcTumf/SVNhzwoHO+q+u8wz3d5PRSkCLSooB > a5voFRdQpicfInzpW57+MHaQJtc1FtQ/+Ub4NQGh+rw5Npps/blQbvqgt/u1qcXL > VwJqEonmF4T3NFxYAzfMR6rv/36MZcd39DK1+H2O5IrzIZXnXy007fw7irkiQ+0= > =IIRy > -----END PGP SIGNATURE----- > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Thu Oct 29 09:36:39 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Thu, 29 Oct 2015 10:36:39 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: <20151029092311.GB24042@weber> References: <5631E07D.8090705@web.de> <20151029092311.GB24042@weber> Message-ID: What if it is additionally known that the shape represented by (x,y,z) -> Bool has a closed, convex area (for example)? Most likely there are then techniques from algorithmic geometry that can find an inside point more efficiently than by iterating blindly through all coordinate triples. Am Donnerstag, 29. Oktober 2015 schrieb Tom Ellis : > On Thu, Oct 29, 2015 at 10:01:49AM +0100, martin wrote: > > I hope this is not a too silly question. It goes like this: > > > > Suppose I have a shape defined as > > > > (x,y,z) -> Bool > > > > how can I find a Point inside this shape? Obviously I could iterate > through all possible x,y and z, but this appears > > very expensive. > > There is no better way in general, so if you want to find points inside a > shape you should use a different encoding of shapes. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Thu Oct 29 09:41:20 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Thu, 29 Oct 2015 10:41:20 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: References: <5631E07D.8090705@web.de> <20151029092311.GB24042@weber> Message-ID: Or maybe not. :-) If nothing more is known, say, about the ratio of the shape's area to the whole region's area. Am Donnerstag, 29. Oktober 2015 schrieb Janis Voigtl?nder : > What if it is additionally known that the shape represented by (x,y,z) -> > Bool has a closed, convex area (for example)? Most likely there are then > techniques from algorithmic geometry that can find an inside point more > efficiently than by iterating blindly through all coordinate triples. > > Am Donnerstag, 29. Oktober 2015 schrieb Tom Ellis : > >> On Thu, Oct 29, 2015 at 10:01:49AM +0100, martin wrote: >> > I hope this is not a too silly question. It goes like this: >> > >> > Suppose I have a shape defined as >> > >> > (x,y,z) -> Bool >> > >> > how can I find a Point inside this shape? Obviously I could iterate >> through all possible x,y and z, but this appears >> > very expensive. >> >> There is no better way in general, so if you want to find points inside a >> shape you should use a different encoding of shapes. >> >> Tom >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerzy.karczmarczuk at unicaen.fr Thu Oct 29 10:04:48 2015 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 29 Oct 2015 11:04:48 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: References: <5631E07D.8090705@web.de> <20151029092311.GB24042@weber> Message-ID: <5631EF40.10101@unicaen.fr> "Martin" asks: > Suppose I have a shape defined as > (x,y,z) -> Bool > how can I find a Point inside this shape? Obviously I could iterate > through all possible x,y and z, but this appears > very expensive. Janis Voigtl?nder comments : > What if it is additionally known that the shape represented by (x,y,z) > -> Bool has a closed, convex area (for example)? Most likely there are > then techniques from algorithmic geometry that can find an inside > point more efficiently than by iterating blindly through all > coordinate triples. > > Am Donnerstag, 29. Oktober 2015 schrieb Tom Ellis : > > ... > There is no better way in general, so if you want to find points > inside a > shape you should use a different encoding of shapes. > You might discourage Martin from using his encoding, suggest using something different, nevertheless /*some people NEED implicit surfaces*/, useful for many purposes (e.g. for the ray tracing; polygonizing them may be horrible...) I don't understand what does it mean "find a point". ANY point? There is no "clever" solution for this yes/no relation. But people in image synthesis use more treatable representation: surf :: Point -> Real (e.g. a sphere = x^2+y^2+z^2-R^2, and not: x^2+y^2+z^2-R^2 < 0 . ) where, say, the interior is negative, exterior positive. Then with some initial, perhaps random steps, you may search with the aid of a moving simplex, or similar. And if the function is reasonably decent, gradient methods are good. This permits to find interesting points, such as barycenters or the surface itself. Jerzy Karczmarczuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsp at informatik.uni-kiel.de Thu Oct 29 10:22:38 2015 From: lsp at informatik.uni-kiel.de (lennart spitzner) Date: Thu, 29 Oct 2015 11:22:38 +0100 Subject: [Haskell-cafe] GHC can't find DLL dependencies on Windows In-Reply-To: References: Message-ID: <5631F36E.20200@informatik.uni-kiel.de> hi Ryan, As i fought the same battle recently, i will point out one related thing: If you plan to deploy your program, and copy the necessary dlls along with it, there can be a strange issue if you miss to copy some dependencies that are present (with a different version) on the target system. (presumably they were present due to a ghc install, but i have not investigated that part). The error was "The procedure entry point pthread_cond_timedwait_relative_np could not be located [..]" when trying to run the compiled executable. Fixed by including more of the msys/mingw64/bin dlls. I had tried to determine the dependencies with a different tool; maybe cygcheck does a better job so this won't arise. Just thought i'd let you know as i found this annoying to diagnose (and the googles don't help much). Lennart On 29/10/15 00:19, Ryan Scott wrote: > Never mind, I figured it out. Previously, I had been placing > C:\msys64\mingw64\bin at the end of my user PATH. It turns out that my > PATH was in fact on the DLL search path, but for some reason, an > earlier directory on my PATH was causing problems. I can't exactly > pinpoint what was causing the problem, but after moving > C:\msys64\mingw64\bin to the start of my system PATH, I can run > Haskell executables in PowerShell/cmd.exe without a problem. > > Ryan S. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > On 29/10/15 00:19, Ryan Scott wrote: > Never mind, I figured it out. Previously, I had been placing > C:\msys64\mingw64\bin at the end of my user PATH. It turns out that my > PATH was in fact on the DLL search path, but for some reason, an > earlier directory on my PATH was causing problems. I can't exactly > pinpoint what was causing the problem, but after moving > C:\msys64\mingw64\bin to the start of my system PATH, I can run > Haskell executables in PowerShell/cmd.exe without a problem. > > Ryan S. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From imantc at gmail.com Thu Oct 29 11:32:09 2015 From: imantc at gmail.com (Imants Cekusins) Date: Thu, 29 Oct 2015 12:32:09 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: <5631EF40.10101@unicaen.fr> References: <5631E07D.8090705@web.de> <20151029092311.GB24042@weber> <5631EF40.10101@unicaen.fr> Message-ID: > finding points inside a shape Any hints about how a point thus found would be used? if any such point is fit, why not make a ref point part of shape definition: define the shape as type Coord= (Int,Int,Int) type IsWithin=Coord ->Bool type Shape= (Coord, IsWithin) -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Thu Oct 29 12:10:13 2015 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Thu, 29 Oct 2015 13:10:13 +0100 Subject: [Haskell-cafe] 2nd CfP: Haskell in Leipzig (Germany) 2015 Message-ID: <56320CA5.3070802@htwk-leipzig.de> HaL-10 Haskell in Leipzig (December 4/5) http://nfa.imn.htwk-leipzig.de/HAL2015/ We are proud to present Joachim Breitner (nomeata) as our invited speaker. The submission deadline (November 2) is approaching! See you - Johannes Waldmann (PC chair) From roma at ro-che.info Thu Oct 29 12:23:45 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 29 Oct 2015 14:23:45 +0200 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: References: <5631E07D.8090705@web.de> <20151029092311.GB24042@weber> Message-ID: <56320FD1.3020306@ro-che.info> On 10/29/2015 11:36 AM, Janis Voigtl?nder wrote: > What if it is additionally known that the shape represented by (x,y,z) > -> Bool has a closed, convex area (for example)? Most likely there are > then techniques from algorithmic geometry that can find an inside point > more efficiently than by iterating blindly through all coordinate triples. It's easy to prove that this is not decidable (assuming we're talking about unbounded numbers, such as Data.Ratio.Rational, and not finite Double). Say you have an algorithm. Run it first on the empty space, and wait until it gives up after a finite number of probes. These probes all lie within some ball U. If you now insert your shape, however large, outside of the ball U, then the algorithm won't find it. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From janis.voigtlaender at gmail.com Thu Oct 29 12:45:53 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Thu, 29 Oct 2015 13:45:53 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: <56320FD1.3020306@ro-che.info> References: <5631E07D.8090705@web.de> <20151029092311.GB24042@weber> <56320FD1.3020306@ro-che.info> Message-ID: > It's easy to prove that this is not decidable I'm not sure what you mean by "this", but if you mean "to find a point in an infinitely large space by finitely many experiments", then of course it is not decidable, and I'm surprised you go to such length to prove it. :-) It is not in the original question as formulated (except as hints if you look for them), but let's assume the problem is that you have (x,y,z) -> Bool for x,y,z natural numbers below 100. And some of the 10^6 points are True, others False. Is there a better algorithm for finding a True point than blindly iterating through all 10^6 points? I suggested that yes, there might be, if the shape is known to be convex and a ratio is known of how much volume of the whole region it takes up. Consider, for example, that the ratio is 0.5. Then only one check suffices to find a point! 2015-10-29 13:23 GMT+01:00 Roman Cheplyaka : > On 10/29/2015 11:36 AM, Janis Voigtl?nder wrote: > > What if it is additionally known that the shape represented by (x,y,z) > > -> Bool has a closed, convex area (for example)? Most likely there are > > then techniques from algorithmic geometry that can find an inside point > > more efficiently than by iterating blindly through all coordinate > triples. > > It's easy to prove that this is not decidable (assuming we're talking > about unbounded numbers, such as Data.Ratio.Rational, and not finite > Double). > > Say you have an algorithm. Run it first on the empty space, and wait > until it gives up after a finite number of probes. These probes all lie > within some ball U. If you now insert your shape, however large, outside > of the ball U, then the algorithm won't find it. > > Roman > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Thu Oct 29 13:01:45 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 29 Oct 2015 15:01:45 +0200 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: References: <5631E07D.8090705@web.de> <20151029092311.GB24042@weber> <56320FD1.3020306@ro-che.info> Message-ID: <563218B9.7050805@ro-che.info> On 10/29/2015 02:45 PM, Janis Voigtl?nder wrote: >> It's easy to prove that this is not decidable > > I'm not sure what you mean by "this", but if you mean "to find a point > in an infinitely large space by finitely many experiments", then of > course it is not decidable, and I'm surprised you go to such length to > prove it. :-) I guess I was equally surprised to see you suggesting doing that! > It is not in the original question as formulated (except as hints if you > look for them), but let's assume the problem is that you have (x,y,z) -> > Bool for x,y,z natural numbers below 100. And some of the 10^6 points > are True, others False. Is there a better algorithm for finding a True > point than blindly iterating through all 10^6 points? > > I suggested that yes, there might be, if the shape is known to be convex > and a ratio is known of how much volume of the whole region it takes up. > > Consider, for example, that the ratio is 0.5. Then only one check > suffices to find a point! Now we are guessing, of course, but in my experience, when people casually talk about a shape in a 3-dimensional space without further clarification, they usually mean the 3d real Euclidean space or some approximation thereof. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From janis.voigtlaender at gmail.com Thu Oct 29 13:08:02 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Thu, 29 Oct 2015 14:08:02 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: <563218B9.7050805@ro-che.info> References: <5631E07D.8090705@web.de> <20151029092311.GB24042@weber> <56320FD1.3020306@ro-che.info> <563218B9.7050805@ro-che.info> Message-ID: > Now we are guessing, of course, but in my experience, when people > casually talk about a shape in a 3-dimensional space without further > clarification, they usually mean the 3d real Euclidean space or some > approximation thereof. As long as we talk about a bounded range (cube) from that space, I am actually willing to maintain my claim. (And the claim wouldn't make much sense without such bounding, because I talked about the ratio of the shape's volume vs. the range's volume.) The discreteness, the coordinates being natural numbers in a finite range, is not really important. Say we look at the 3d space spanned by (0,0,0) to (1,1,1) in real numbers. If there is a shape in there that is convex and takes up 0.5 of the volume, I can find a point belonging to it with a single query. If the ratio is 0.3 instead, what is the best querying strategy? And so on. 2015-10-29 14:01 GMT+01:00 Roman Cheplyaka : > On 10/29/2015 02:45 PM, Janis Voigtl?nder wrote: > >> It's easy to prove that this is not decidable > > > > I'm not sure what you mean by "this", but if you mean "to find a point > > in an infinitely large space by finitely many experiments", then of > > course it is not decidable, and I'm surprised you go to such length to > > prove it. :-) > > I guess I was equally surprised to see you suggesting doing that! > > > It is not in the original question as formulated (except as hints if you > > look for them), but let's assume the problem is that you have (x,y,z) -> > > Bool for x,y,z natural numbers below 100. And some of the 10^6 points > > are True, others False. Is there a better algorithm for finding a True > > point than blindly iterating through all 10^6 points? > > > > I suggested that yes, there might be, if the shape is known to be convex > > and a ratio is known of how much volume of the whole region it takes up. > > > > Consider, for example, that the ratio is 0.5. Then only one check > > suffices to find a point! > > Now we are guessing, of course, but in my experience, when people > casually talk about a shape in a 3-dimensional space without further > clarification, they usually mean the 3d real Euclidean space or some > approximation thereof. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Thu Oct 29 16:54:00 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Thu, 29 Oct 2015 12:54:00 -0400 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: References: <5631E07D.8090705@web.de> <20151029092311.GB24042@weber> <56320FD1.3020306@ro-che.info> <563218B9.7050805@ro-che.info> Message-ID: <56324F28.2010105@orlitzky.com> On 10/29/2015 09:08 AM, Janis Voigtl?nder wrote: > > Say we look at the 3d space spanned by (0,0,0) to (1,1,1) in real > numbers. If there is a shape in there that is convex and takes up 0.5 of > the volume, I can find a point belonging to it with a single query. > Better make that CLOSED and convex =) From erkokl at gmail.com Thu Oct 29 17:01:03 2015 From: erkokl at gmail.com (Levent Erkok) Date: Thu, 29 Oct 2015 10:01:03 -0700 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: <5631E07D.8090705@web.de> References: <5631E07D.8090705@web.de> Message-ID: This problem can be considered as an instance of the more general SAT problem, in which you're trying to find a satisfying assignment to a predicate. You might want to give that approach a try, though it does require changes in representation. Here's a *very* simple example: Prelude> :m Data.SBV Prelude Data.SBV> let f (x, y, z) = 0 .<= x &&& y .>= 2 &&& z .<= x+(y::SInteger) Prelude Data.SBV> sat f Satisfiable. Model: s0 = 0 :: Integer s1 = 2 :: Integer s2 = 2 :: Integer Your "f" is probably going to be much more complicated, but if you can afford to move to symbolic types, then SBV can bridge the gap and a SAT/SMT solver can give you the required points. Or tell you if there isn't any, like in the following example: Prelude Data.SBV> sat $ \x y -> x .> y &&& x .< (y::SInteger) Unsatisfiable -Levent. On Thu, Oct 29, 2015 at 2:01 AM, martin wrote: > Hello all, > > I hope this is not a too silly question. It goes like this: > > Suppose I have a shape defined as > > (x,y,z) -> Bool > > how can I find a Point inside this shape? Obviously I could iterate > through all possible x,y and z, but this appears > very expensive. > > There may be no point at all at x=0. With brute force iteration I would > have no clue that the False I am receiving with > (0,1,1) is caused by x=0 and I may nedlessly try all combinations of y and > z without ever receiving a True. > > Are there any alternative ways of finding points inside a shape? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janis.voigtlaender at gmail.com Thu Oct 29 18:26:19 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Thu, 29 Oct 2015 19:26:19 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: <56324F28.2010105@orlitzky.com> References: <5631E07D.8090705@web.de> <20151029092311.GB24042@weber> <56320FD1.3020306@ro-che.info> <563218B9.7050805@ro-che.info> <56324F28.2010105@orlitzky.com> Message-ID: 2015-10-29 17:54 GMT+01:00 Michael Orlitzky : > On 10/29/2015 09:08 AM, Janis Voigtl?nder wrote: > > > > Say we look at the 3d space spanned by (0,0,0) to (1,1,1) in real > > numbers. If there is a shape in there that is convex and takes up 0.5 of > > the volume, I can find a point belonging to it with a single query. > > > > Better make that CLOSED and convex =) > I guess I wouldn't call something without a border a "shape". So yes, closedness was assumed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.drautzburg at web.de Thu Oct 29 18:30:09 2015 From: martin.drautzburg at web.de (martin) Date: Thu, 29 Oct 2015 19:30:09 +0100 Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool In-Reply-To: <5631E07D.8090705@web.de> References: <5631E07D.8090705@web.de> Message-ID: <563265B1.2040100@web.de> I understand that with (x,y,z)->Bool there is not much I can do other than brute force. But I am not forced to use this representation. The only thing I'd rather not do, is enumerate all the points. I thought the reactive guys found ways to manipulate Time->a functions without having to enumerate all the possible (Time,a) occurrences. But there live is "easy", because the possible times only depend on the start time and the sampling frequency (I may be awfully mistaken here). I thought about doing similar things, but with more than one coordinate, i.e. Time and Space. With just one coordinate I can answer "what will be at Time=t", but with two coordinates, the answer will be a function of space. But I can also ask "what will be at position x" and the result will be a function of time. Now, that does not look too difficult. I can always convert (x,y,z)->Bool to (y,z)->Bool if I happen to know x. I looks like I have to work on step one of the Fenyman Problem Solution Method ("write down the problem"). Thanks again. Am 10/29/2015 um 10:01 AM schrieb martin: > Hello all, > > I hope this is not a too silly question. It goes like this: > > Suppose I have a shape defined as > > (x,y,z) -> Bool > > how can I find a Point inside this shape? Obviously I could iterate through all possible x,y and z, but this appears > very expensive. > > There may be no point at all at x=0. With brute force iteration I would have no clue that the False I am receiving with > (0,1,1) is caused by x=0 and I may nedlessly try all combinations of y and z without ever receiving a True. > > Are there any alternative ways of finding points inside a shape? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From r.wobben at home.nl Fri Oct 30 06:20:46 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 30 Oct 2015 07:20:46 +0100 Subject: [Haskell-cafe] what do I have to do exactlry with this exercises Message-ID: <56330C3E.6040601@home.nl> Hello, Im self studing Haskell with the Craft o ffunctional programmimg of Hutton. Now I see two exercises that I do not understand what is really the purpose here. The two exercises are : 4.21 Given a function f of type Integer -> Integer give a recursive definition of a function of type Integer -> Integer which on input n returns the maximum of the values f 0, f 1, ..., f n. You might find the max function defined in Section 3.4 useful. To test this function, add to your script a definition of some values of f thus: f 0 = 0 f 1 = 44 f 2 = 17 f _ = 0 and so on; then test your function at various values. 4.22 Given a function f of type Integer -> Integer give a recursive definition of a function of type Integer -> Bool which on input n returns True if one or more of the values f 0, f 1, ..., f n is zero and False otherwise. From sean.leather at gmail.com Fri Oct 30 06:35:34 2015 From: sean.leather at gmail.com (Sean Leather) Date: Fri, 30 Oct 2015 08:35:34 +0200 Subject: [Haskell-cafe] what do I have to do exactlry with this exercises In-Reply-To: <56330C3E.6040601@home.nl> References: <56330C3E.6040601@home.nl> Message-ID: On Fri, Oct 30, 2015 at 8:20 AM, Roelof Wobben wrote: > Im self studing Haskell with the Craft o ffunctional programmimg of Hutton. > > Now I see two exercises that I do not understand what is really the > purpose here. > Maybe a slight rewording of the instructions would help? (It helped me!) The two exercises are : > > 4.21 Given a function f of type Integer -> Integer give a recursive > definition of a > function of type Integer -> Integer which on input n returns the maximum > of the values f 0, f 1, ..., f n. [...] > Given: f :: Integer -> Integer Define: g :: Integer -> Integer g n = ... such that g is defined recursively. g n returns the maximum of f 0, f 1, ..., f n. 4.22 Given a function f of type Integer -> Integer give a recursive > definition of > a function of type Integer -> Bool which on input n returns True if one or > more of the values f 0, f 1, ..., f n is zero and False otherwise. > Try a similar rewording as above. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Oct 30 06:40:09 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 30 Oct 2015 07:40:09 +0100 Subject: [Haskell-cafe] what do I have to do exactlry with this exercises In-Reply-To: References: <56330C3E.6040601@home.nl> Message-ID: <563310C9.60809@home.nl> An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Fri Oct 30 06:46:08 2015 From: sean.leather at gmail.com (Sean Leather) Date: Fri, 30 Oct 2015 08:46:08 +0200 Subject: [Haskell-cafe] what do I have to do exactlry with this exercises In-Reply-To: <563310C9.60809@home.nl> References: <56330C3E.6040601@home.nl> <563310C9.60809@home.nl> Message-ID: On Fri, Oct 30, 2015 at 8:40 AM, Roelof Wobben wrote: > Op 30-10-2015 om 07:35 schreef Sean Leather: > > On Fri, Oct 30, 2015 at 8:20 AM, Roelof Wobben wrote: > >> Im self studing Haskell with the Craft o ffunctional programmimg of >> Hutton. >> >> Now I see two exercises that I do not understand what is really the >> purpose here. >> > > Maybe a slight rewording of the instructions would help? (It helped me!) > > The two exercises are : >> >> 4.21 Given a function f of type Integer -> Integer give a recursive >> definition of a >> function of type Integer -> Integer which on input n returns the maximum >> of the values f 0, f 1, ..., f n. [...] >> > > Given: > > f :: Integer -> Integer > > Define: > > g :: Integer -> Integer > g n = ... > > such that g is defined recursively. g n returns the maximum of f 0, f 1, > ..., f n. > > > Thanks, > > But is the maxium not always the last answer. > Indeed, it is not. So the max of g 1 = answer g1 ?? > The value of g 0 is f 0. The value of g 1 is either f 0 or f 1, whichever is greater. The value of g 2 is one of f 0, f 1, or f 2, whichever is greatest. And so on. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Oct 30 06:52:25 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 30 Oct 2015 07:52:25 +0100 Subject: [Haskell-cafe] what do I have to do exactlry with this exercises In-Reply-To: References: <56330C3E.6040601@home.nl> <563310C9.60809@home.nl> Message-ID: <563313A9.9030102@home.nl> An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Fri Oct 30 07:00:07 2015 From: sean.leather at gmail.com (Sean Leather) Date: Fri, 30 Oct 2015 09:00:07 +0200 Subject: [Haskell-cafe] what do I have to do exactlry with this exercises In-Reply-To: <563313A9.9030102@home.nl> References: <56330C3E.6040601@home.nl> <563310C9.60809@home.nl> <563313A9.9030102@home.nl> Message-ID: On Fri, Oct 30, 2015 at 8:52 AM, Roelof Wobben wrote: > Let's say f is a recursive function which calculates the fac. > > So f 0 = 0 > f1 = 1 > f2 = 2 > f3 = 6 > > so im my oponion g1 = the answer of f1 which is also the max > But recall the problem definition: 4.21 Given a function f of type Integer -> Integer give a recursive > definition of a > function of type Integer -> Integer which on input n returns the maximum > of the values f 0, f 1, ..., f n. It doesn't say anything about f, which means you are not allowed to make assumptions about the definition of f. f could be defined as: f :: Integer -> Integer f 42 = 100 f x = 0 Since you don't know anything about f, you must look at all values from f 0 to f n in order to find the maximum. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Oct 30 07:05:29 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 30 Oct 2015 08:05:29 +0100 Subject: [Haskell-cafe] what do I have to do exactlry with this exercises In-Reply-To: References: <56330C3E.6040601@home.nl> <563310C9.60809@home.nl> <563313A9.9030102@home.nl> Message-ID: <563316B9.5090600@home.nl> An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Oct 30 07:12:15 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 30 Oct 2015 09:12:15 +0200 Subject: [Haskell-cafe] haskell-ide repository name In-Reply-To: References: Message-ID: This post generated some discussion on the mailing list(s) [1],[2] and on reddit [3]. The straw poll [4] garnered (as of time of writing this mail) 138 votes, broken down as ghc-ide-engine 56 votes 41% ghc-ide-service 43 votes 31% haskides 19 votes 14% ghc-ide-daemon 16 votes 12% something else 4 votes 3% So it seems -ide-engine is the favourite In a bait-and-switch operation, I think it makes sense to keep the current "haskell-ide" prefix, and so rename it to haskell-ide-engine This has the advantages of a) The prefix is the same, so continuity is slightly better b) It does not mentally shut out any tooling constructed using other compilers/techniques, such as haskell-src-exts If anyone feels strongly that this is wrong, please let me know. Regards Alan [1] https://mail.haskell.org/pipermail/haskell-cafe/2015-October/121965.html [2] https://groups.google.com/forum/#!topic/haskell-ide/hI3MzXbwqTo [3] https://www.reddit.com/r/haskell/comments/3qh19i/rename_haskellide_project/ [4] http://strawpoll.me/5842105/r On Mon, Oct 26, 2015 at 11:06 PM, Alan & Kim Zimmerman wrote: > At the moment the repository/project is called haskell-ide > > This leads to the impression that it is an IDE. > > It is actually a backend/server to provide services for an IDE > > We are considering changing the name. > > The options are > > haskides / ghc-ide-daemon / ghc-ide-service / ghc-ide-engine > > Please cast your vote at http://strawpoll.me/5842105 > > Thanks > Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Fri Oct 30 07:13:09 2015 From: sean.leather at gmail.com (Sean Leather) Date: Fri, 30 Oct 2015 09:13:09 +0200 Subject: [Haskell-cafe] what do I have to do exactlry with this exercises In-Reply-To: <563316B9.5090600@home.nl> References: <56330C3E.6040601@home.nl> <563310C9.60809@home.nl> <563313A9.9030102@home.nl> <563316B9.5090600@home.nl> Message-ID: On Fri, Oct 30, 2015 at 9:05 AM, Roelof Wobben wrote: > Now I have to think about how to read the values of f 1 .. fn 2 . I think > I need 2 recursive function . One for g x and one for reading f1 or use a > list to store f 0 .. f n and then use maximum. There are different ways to solve the problem, certainly. I think this problem is asking you to do the recursion yourself rather than use existing recursive functions such as 'maximum' from the Prelude. I would assume you are allowed to define other functions to help you as needed. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.kholomiov at gmail.com Fri Oct 30 14:41:00 2015 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Fri, 30 Oct 2015 17:41:00 +0300 Subject: [Haskell-cafe] New release Csound-expression 4.9 is out Message-ID: *The 4.9.0 is out! New features:* csound-expression - Functions for creation of FM-synthesizers. We can create the whole graph of FM-units (with feedback). Check out the module Csound.Air.Fm - Support for Monosynth patches. See atMono in the module Csound.Air.Patch see the function atMono and atMonoSharp. - Easy to use Binaural panning. See the module Csound.Air.Pan It?s like: headPan :: (Sig, Sig) -> Sig -> Sig2headPan (azimuth, elevation) asig = (aleft, aright) the compiler can supply the right extra files by reading the header of .csd - Construction of patches for sound fonts (sfPatch, sfPatchHall). - Table of tables. We can create a table that contains tables. - Harmonic oscillators for subtractive synth: buz and gbuz (the functions are adapted from the Csound ones) - Reverbs for patches. It?s very easy to add a reverb to your patch (withSmallHall patch, withLargeHall patch, etc) - Some bug-fixes csound-catalog - Many mono-synth were added. You can use them with function atMono in place of atMidi. The mono versions of patches have suffix m. Like hammonOrganm or nightPadm. We can use it like this: > dac $ atMono nightPadm - SHARC instruments. SHARC db contains a FFT-samples for sustain notes. It includes many orchestra instruments. There are many new patches that use natural sounding timbres taken from the SHARC library. Check out functions soloSharc, padSharc, dreamSharc. We can use it like this: > dac $ atMidi $ padSharc shCello csound-sampler - Handy function withBpm allows to query current bpm with in the scope of expression. - Sampler mappers were generalized. - Char trigering functions are synchronized with bpm. Cheers! Anton ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.kholomiov at gmail.com Fri Oct 30 14:44:20 2015 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Fri, 30 Oct 2015 17:44:20 +0300 Subject: [Haskell-cafe] New release Csound-expression 4.9 is out In-Reply-To: References: Message-ID: As usual the library is available on Hackage: http://hackage.haskell.org/package/csound-expression The github repo is at https://github.com/spell-music/csound-expression Other useful libraries that go with csound-expression are csound-sampler, and csound-catalog: - csound-sampler - csound-catalog ? 2015-10-30 17:41 GMT+03:00 Anton Kholomiov : > *The 4.9.0 is out! New features:* > > csound-expression > > - > > Functions for creation of FM-synthesizers. We can create > the whole graph of FM-units (with feedback). Check out the module > Csound.Air.Fm > - > > Support for Monosynth patches. See atMono in the module > Csound.Air.Patch > see the function atMono and atMonoSharp. > - > > Easy to use Binaural panning. See the module Csound.Air.Pan > It?s like: > > headPan :: (Sig, Sig) -> Sig -> Sig2headPan (azimuth, elevation) asig = (aleft, aright) > > the compiler can supply the right extra files by reading the header of .csd > > - > > Construction of patches for sound fonts (sfPatch, sfPatchHall). > - > > Table of tables. We can create a table that contains tables. > - > > Harmonic oscillators for subtractive synth: buz and gbuz > (the functions are adapted from the Csound ones) > - > > Reverbs for patches. It?s very easy to add a reverb to your patch > (withSmallHall patch, withLargeHall patch, etc) > - > > Some bug-fixes > > csound-catalog > > - Many mono-synth were added. You can use them with function atMono > in place of atMidi. The mono versions of patches have suffix m. > Like hammonOrganm or nightPadm. We can use it like this: > > > dac $ atMono nightPadm > > > - SHARC instruments. SHARC db contains a FFT-samples for sustain notes. > It includes many orchestra instruments. There are many new patches that > use natural sounding timbres taken from the SHARC library. > Check out functions soloSharc, padSharc, dreamSharc. > > We can use it like this: > > > dac $ atMidi $ padSharc shCello > > csound-sampler > > - > > Handy function withBpm allows to query current bpm with in the scope > of expression. > - > > Sampler mappers were generalized. > - > > Char trigering functions are synchronized with bpm. > > Cheers! > Anton > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Oct 30 18:09:26 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 30 Oct 2015 20:09:26 +0200 Subject: [Haskell-cafe] haskell-ide repository name In-Reply-To: References: Message-ID: Ok the repository and IRC channel have both been changed to haskell-ide-engine. The timing is driven by wanting to get an accurate HCAR entry for the project. Regards Alan On Fri, Oct 30, 2015 at 9:12 AM, Alan & Kim Zimmerman wrote: > This post generated some discussion on the mailing list(s) [1],[2] and on > reddit [3]. > > The straw poll [4] garnered (as of time of writing this mail) 138 votes, > broken down as > > ghc-ide-engine 56 votes 41% > ghc-ide-service 43 votes 31% > haskides 19 votes 14% > ghc-ide-daemon 16 votes 12% > something else 4 votes 3% > > So it seems -ide-engine is the favourite > > In a bait-and-switch operation, I think it makes sense to keep the current > "haskell-ide" prefix, and so rename it to > > haskell-ide-engine > > This has the advantages of > > a) The prefix is the same, so continuity is slightly better > > b) It does not mentally shut out any tooling constructed using other > compilers/techniques, such as haskell-src-exts > > If anyone feels strongly that this is wrong, please let me know. > > Regards > Alan > > > [1] > https://mail.haskell.org/pipermail/haskell-cafe/2015-October/121965.html > [2] https://groups.google.com/forum/#!topic/haskell-ide/hI3MzXbwqTo > [3] > https://www.reddit.com/r/haskell/comments/3qh19i/rename_haskellide_project/ > [4] http://strawpoll.me/5842105/r > > > On Mon, Oct 26, 2015 at 11:06 PM, Alan & Kim Zimmerman < > alan.zimm at gmail.com> wrote: > >> At the moment the repository/project is called haskell-ide >> >> This leads to the impression that it is an IDE. >> >> It is actually a backend/server to provide services for an IDE >> >> We are considering changing the name. >> >> The options are >> >> haskides / ghc-ide-daemon / ghc-ide-service / ghc-ide-engine >> >> Please cast your vote at http://strawpoll.me/5842105 >> >> Thanks >> Alan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Fri Oct 30 19:02:57 2015 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 30 Oct 2015 20:02:57 +0100 (CET) Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool Message-ID: Martin, this may be impractical performance-wise, but Haskell offers magic data structures for searching. Have a look at Martin Escardo's blog post [1] on infinite search in finite time. There is a package on Hackage [2] implementing it. The `shapes` you get are compact, non-empty subsets of types. If you have a shape shape :: Data.Searchable.Set a then Data.Searchable.search (const True) shape will return some element of your shape. As far as I know nobody has ever used this data structure for solid geometry. You'd need to combine it with some implementation of exact reals [*] to have geometry in a product of closed intervals. A downside is that general intersections don't exist, since the shapes must be non-empty. But since images of searchable sets are searchable, you could define complicated shapes by starting with a simple one and distort it with a function. If your type of space is discrete, then the search function might resort to brute force enumeration if the shape was defined that way. -- Olaf [1] http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-finite-time/ [2] http://hackage.haskell.org/package/infinite-search [*] As far as I am aware there is no appropriate package on Hackage, but Haskell implementations exist in several theses. From capn.freako at gmail.com Fri Oct 30 20:03:49 2015 From: capn.freako at gmail.com (David Banas) Date: Fri, 30 Oct 2015 13:03:49 -0700 Subject: [Haskell-cafe] Determining the length of a Foldable Applicative. Message-ID: <9826E916-74D9-4FA8-B734-3CA984D9A069@gmail.com> Hi all, I thought I had a simple way to determine the ?length" (i.e. - number of elements in) of a Foldable Applicative container: import Prelude hiding (sum) import Data.Foldable (Foldable(..), sum) import Control.Applicative -- Calculate the "length" (i.e. - number of elements in) an Applicative container. app_len :: (Applicative f, Foldable f) => f a -> Int app_len = sum $ pure 1 but I didn?t: app_len_test.hs:9:11: Could not deduce (Foldable t0) arising from a use of ?sum? from the context (Applicative f, Foldable f) bound by the type signature for app_len :: (Applicative f, Foldable f) => f a -> Int at app_len_test.hs:8:12-52 The type variable ?t0? is ambiguous Note: there are several potential instances: instance Foldable ((,) a) -- Defined in ?Data.Foldable? instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) -- Defined in ?Data.Foldable? instance Foldable (Const m) -- Defined in ?Data.Foldable? ...plus four others In the expression: sum In the expression: sum $ pure 1 In an equation for ?app_len?: app_len = sum $ pure 1 app_len_test.hs:9:17: Could not deduce (Applicative t0) arising from a use of ?pure? from the context (Applicative f, Foldable f) bound by the type signature for app_len :: (Applicative f, Foldable f) => f a -> Int at app_len_test.hs:8:12-52 The type variable ?t0? is ambiguous Note: there are several potential instances: instance Data.Monoid.Monoid a => Applicative ((,) a) -- Defined in ?Control.Applicative? instance Applicative ((->) a) -- Defined in ?Control.Applicative? instance Control.Arrow.Arrow a => Applicative (Control.Arrow.ArrowMonad a) -- Defined in ?Control.Applicative? ...plus 14 others In the second argument of ?($)?, namely ?pure 1? In the expression: sum $ pure 1 In an equation for ?app_len?: app_len = sum $ pure 1 Can anyone help me understand what I?m missing? Thanks, and have a great weekend, -db From janis.voigtlaender at gmail.com Fri Oct 30 20:23:43 2015 From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=) Date: Fri, 30 Oct 2015 21:23:43 +0100 Subject: [Haskell-cafe] Determining the length of a Foldable Applicative. In-Reply-To: <9826E916-74D9-4FA8-B734-3CA984D9A069@gmail.com> References: <9826E916-74D9-4FA8-B734-3CA984D9A069@gmail.com> Message-ID: Maybe what you are missing is an argument to the app_len function? Am Freitag, 30. Oktober 2015 schrieb David Banas : > Hi all, > > I thought I had a simple way to determine the ?length" (i.e. - number of > elements in) of a Foldable Applicative container: > > import Prelude hiding (sum) > import Data.Foldable (Foldable(..), sum) > import Control.Applicative > > -- Calculate the "length" (i.e. - number of elements in) an > Applicative container. > app_len :: (Applicative f, Foldable f) => f a -> Int > app_len = sum $ pure 1 > > but I didn?t: > > app_len_test.hs:9:11: > Could not deduce (Foldable t0) arising from a use of ?sum? > from the context (Applicative f, Foldable f) > bound by the type signature for > app_len :: (Applicative f, Foldable f) => f a -> Int > at app_len_test.hs:8:12-52 > The type variable ?t0? is ambiguous > Note: there are several potential instances: > instance Foldable ((,) a) -- Defined in ?Data.Foldable? > instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) > -- Defined in ?Data.Foldable? > instance Foldable (Const m) -- Defined in ?Data.Foldable? > ...plus four others > In the expression: sum > In the expression: sum $ pure 1 > In an equation for ?app_len?: app_len = sum $ pure 1 > > app_len_test.hs:9:17: > Could not deduce (Applicative t0) arising from a use of ?pure? > from the context (Applicative f, Foldable f) > bound by the type signature for > app_len :: (Applicative f, Foldable f) => f a -> Int > at app_len_test.hs:8:12-52 > The type variable ?t0? is ambiguous > Note: there are several potential instances: > instance Data.Monoid.Monoid a => Applicative ((,) a) > -- Defined in ?Control.Applicative? > instance Applicative ((->) a) -- Defined in ?Control.Applicative? > instance Control.Arrow.Arrow a => > Applicative (Control.Arrow.ArrowMonad a) > -- Defined in ?Control.Applicative? > ...plus 14 others > In the second argument of ?($)?, namely ?pure 1? > In the expression: sum $ pure 1 > In an equation for ?app_len?: app_len = sum $ pure 1 > > Can anyone help me understand what I?m missing? > > Thanks, and have a great weekend, > -db > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Fri Oct 30 20:41:34 2015 From: trebla at vex.net (Albert Y. C. Lai) Date: Fri, 30 Oct 2015 16:41:34 -0400 Subject: [Haskell-cafe] MonadFix wiki confusion In-Reply-To: References: <5629439E.6070000@vex.net> Message-ID: <5633D5FE.4020306@vex.net> On 2015-10-22 11:29 PM, Samuel R?dal wrote: > I agree that the only laziness that's needed is to not evaluate s, and > making the tree strict in the original code doesn't cause that as the > tuple is still lazy. I just thought the article could be a bit more > explicit about that to avoid confusion. Tomorrow I'm going to make this change: delete the strict version of BTree, and just say that the only laziness needed is the laziness in s, and that "$! s" breaks it. From david.feuer at gmail.com Fri Oct 30 21:42:56 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 30 Oct 2015 17:42:56 -0400 Subject: [Haskell-cafe] Determining the length of a Foldable Applicative. In-Reply-To: <9826E916-74D9-4FA8-B734-3CA984D9A069@gmail.com> References: <9826E916-74D9-4FA8-B734-3CA984D9A069@gmail.com> Message-ID: You don't need the Applicative context. In fact, in the latest version of the library, length is a member of the Foldable class, but even for older versions, you can define length :: Foldable f => f a -> Int Does limiting yourself that way help guide you to a correct solution? On Fri, Oct 30, 2015 at 4:03 PM, David Banas wrote: > Hi all, > > I thought I had a simple way to determine the ?length" (i.e. - number of elements in) of a Foldable Applicative container: > > import Prelude hiding (sum) > import Data.Foldable (Foldable(..), sum) > import Control.Applicative > > -- Calculate the "length" (i.e. - number of elements in) an Applicative container. > app_len :: (Applicative f, Foldable f) => f a -> Int > app_len = sum $ pure 1 > > but I didn?t: > > app_len_test.hs:9:11: > Could not deduce (Foldable t0) arising from a use of ?sum? > from the context (Applicative f, Foldable f) > bound by the type signature for > app_len :: (Applicative f, Foldable f) => f a -> Int > at app_len_test.hs:8:12-52 > The type variable ?t0? is ambiguous > Note: there are several potential instances: > instance Foldable ((,) a) -- Defined in ?Data.Foldable? > instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) > -- Defined in ?Data.Foldable? > instance Foldable (Const m) -- Defined in ?Data.Foldable? > ...plus four others > In the expression: sum > In the expression: sum $ pure 1 > In an equation for ?app_len?: app_len = sum $ pure 1 > > app_len_test.hs:9:17: > Could not deduce (Applicative t0) arising from a use of ?pure? > from the context (Applicative f, Foldable f) > bound by the type signature for > app_len :: (Applicative f, Foldable f) => f a -> Int > at app_len_test.hs:8:12-52 > The type variable ?t0? is ambiguous > Note: there are several potential instances: > instance Data.Monoid.Monoid a => Applicative ((,) a) > -- Defined in ?Control.Applicative? > instance Applicative ((->) a) -- Defined in ?Control.Applicative? > instance Control.Arrow.Arrow a => > Applicative (Control.Arrow.ArrowMonad a) > -- Defined in ?Control.Applicative? > ...plus 14 others > In the second argument of ?($)?, namely ?pure 1? > In the expression: sum $ pure 1 > In an equation for ?app_len?: app_len = sum $ pure 1 > > Can anyone help me understand what I?m missing? > > Thanks, and have a great weekend, > -db > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From kane at kane.cx Fri Oct 30 21:56:29 2015 From: kane at kane.cx (David Kraeutmann) Date: Fri, 30 Oct 2015 22:56:29 +0100 Subject: [Haskell-cafe] Determining the length of a Foldable Applicative. In-Reply-To: <9826E916-74D9-4FA8-B734-3CA984D9A069@gmail.com> References: <9826E916-74D9-4FA8-B734-3CA984D9A069@gmail.com> Message-ID: <5633E78D.9000702@kane.cx> Your types don't match here, but you have the right idea. 'sum' won't be enough. Take a look at the definition of sum: > sum :: (Foldable t, Num a) => t a -> a > sum = getSum . foldMap Sum That won't work, since that requires '(Num a)'. We just want to count 1 up whenever we map an element. Try doing something with const and Sum. (Forgot to reply to list) On 10/30/2015 9:03 PM, David Banas wrote: > Hi all, > > I thought I had a simple way to determine the ?length" (i.e. - number of elements in) of a Foldable Applicative container: > > import Prelude hiding (sum) > import Data.Foldable (Foldable(..), sum) > import Control.Applicative > > -- Calculate the "length" (i.e. - number of elements in) an Applicative container. > app_len :: (Applicative f, Foldable f) => f a -> Int > app_len = sum $ pure 1 > > but I didn?t: > > app_len_test.hs:9:11: > Could not deduce (Foldable t0) arising from a use of ?sum? > from the context (Applicative f, Foldable f) > bound by the type signature for > app_len :: (Applicative f, Foldable f) => f a -> Int > at app_len_test.hs:8:12-52 > The type variable ?t0? is ambiguous > Note: there are several potential instances: > instance Foldable ((,) a) -- Defined in ?Data.Foldable? > instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) > -- Defined in ?Data.Foldable? > instance Foldable (Const m) -- Defined in ?Data.Foldable? > ...plus four others > In the expression: sum > In the expression: sum $ pure 1 > In an equation for ?app_len?: app_len = sum $ pure 1 > > app_len_test.hs:9:17: > Could not deduce (Applicative t0) arising from a use of ?pure? > from the context (Applicative f, Foldable f) > bound by the type signature for > app_len :: (Applicative f, Foldable f) => f a -> Int > at app_len_test.hs:8:12-52 > The type variable ?t0? is ambiguous > Note: there are several potential instances: > instance Data.Monoid.Monoid a => Applicative ((,) a) > -- Defined in ?Control.Applicative? > instance Applicative ((->) a) -- Defined in ?Control.Applicative? > instance Control.Arrow.Arrow a => > Applicative (Control.Arrow.ArrowMonad a) > -- Defined in ?Control.Applicative? > ...plus 14 others > In the second argument of ?($)?, namely ?pure 1? > In the expression: sum $ pure 1 > In an equation for ?app_len?: app_len = sum $ pure 1 > > Can anyone help me understand what I?m missing? > > Thanks, and have a great weekend, > -db > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4291 bytes Desc: S/MIME Cryptographic Signature URL: From capn.freako at gmail.com Sat Oct 31 02:11:50 2015 From: capn.freako at gmail.com (David Banas) Date: Fri, 30 Oct 2015 19:11:50 -0700 Subject: [Haskell-cafe] Determining the length of a Foldable Applicative. In-Reply-To: <5633E55C.3040006@kane.cx> References: <9826E916-74D9-4FA8-B734-3CA984D9A069@gmail.com> <5633E55C.3040006@kane.cx> Message-ID: <4E77E350-9F00-47DB-B9C8-3774A66603DF@gmail.com> Thanks to all, whom responded to this! With your help, I found my way to this, which seems to work correctly: app_len :: (Foldable f) => f a -> Int app_len = foldl' (flip ((+) . const 1)) 0 -db On Oct 30, 2015, at 2:47 PM, David Kraeutmann wrote: > Your types don't match here, but you have the right idea. > > 'sum' won't be enough. Take a look at the definition of sum: > >> sum :: (Foldable t, Num a) => t a -> a >> sum = getSum . foldMap Sum > > That won't work, since that requires '(Num a)'. > > We just want to count 1 up whenever we map an element. > Try doing something with const and Data.Monoid.Sum. > > > On 10/30/2015 9:03 PM, David Banas wrote: >> Hi all, >> >> I thought I had a simple way to determine the ?length" (i.e. - number of elements in) of a Foldable Applicative container: >> >> import Prelude hiding (sum) >> import Data.Foldable (Foldable(..), sum) >> import Control.Applicative >> >> -- Calculate the "length" (i.e. - number of elements in) an Applicative container. >> app_len :: (Applicative f, Foldable f) => f a -> Int >> app_len = sum $ pure 1 >> >> but I didn?t: >> >> app_len_test.hs:9:11: >> Could not deduce (Foldable t0) arising from a use of ?sum? >> from the context (Applicative f, Foldable f) >> bound by the type signature for >> app_len :: (Applicative f, Foldable f) => f a -> Int >> at app_len_test.hs:8:12-52 >> The type variable ?t0? is ambiguous >> Note: there are several potential instances: >> instance Foldable ((,) a) -- Defined in ?Data.Foldable? >> instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) >> -- Defined in ?Data.Foldable? >> instance Foldable (Const m) -- Defined in ?Data.Foldable? >> ...plus four others >> In the expression: sum >> In the expression: sum $ pure 1 >> In an equation for ?app_len?: app_len = sum $ pure 1 >> >> app_len_test.hs:9:17: >> Could not deduce (Applicative t0) arising from a use of ?pure? >> from the context (Applicative f, Foldable f) >> bound by the type signature for >> app_len :: (Applicative f, Foldable f) => f a -> Int >> at app_len_test.hs:8:12-52 >> The type variable ?t0? is ambiguous >> Note: there are several potential instances: >> instance Data.Monoid.Monoid a => Applicative ((,) a) >> -- Defined in ?Control.Applicative? >> instance Applicative ((->) a) -- Defined in ?Control.Applicative? >> instance Control.Arrow.Arrow a => >> Applicative (Control.Arrow.ArrowMonad a) >> -- Defined in ?Control.Applicative? >> ...plus 14 others >> In the second argument of ?($)?, namely ?pure 1? >> In the expression: sum $ pure 1 >> In an equation for ?app_len?: app_len = sum $ pure 1 >> >> Can anyone help me understand what I?m missing? >> >> Thanks, and have a great weekend, >> -db >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > From r.wobben at home.nl Sat Oct 31 10:16:06 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 31 Oct 2015 11:16:06 +0100 Subject: [Haskell-cafe] testing for exceptions Message-ID: <563494E6.4070508@home.nl> Hello, I have made this exercise which can be found at the Craft of Functional Programming book. -- exercise 32 -- Suppose we have to raise 2 to the power n. If n is even, 2*m say, then -- 2n = 22*m = (2m)2 -- If n is odd, 2*m+l say, then -- 2n = 22*m+l = (2n)2*2 -- Give a recursive function to compute 2n which uses these insights. f2 :: Integer -> Integer f2 n | n < 0 = error "This will only run for positive numbers" | n == 0 = 1 | even n = f2 ( n `div` 2) ^ 2 | odd n = (f2 ( n `div` 2) ^ 2) * 2 Now I have to make Hunit tests for it, But is there a way I can test if the error message is shown when a negative number is being used ? Roelof From joachifm at fastmail.fm Sat Oct 31 10:37:18 2015 From: joachifm at fastmail.fm (joachifm at fastmail.fm) Date: Sat, 31 Oct 2015 11:37:18 +0100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: <563494E6.4070508@home.nl> References: <563494E6.4070508@home.nl> Message-ID: <1446287838.1397577.425280905.106DE77C@webmail.messagingengine.com> On Sat, Oct 31, 2015, at 11:16 AM, Roelof Wobben wrote: > [...] > But is there a way I can test if the error message is shown when a > negative number is being used ? Something like (untested) ``` import qualified Control.Exception as E isErrorCall :: String -> a -> IO Bool isErrorCall s x = (E.evaluate x >> return False) `E.catch` (\(E.ErrorCall e) -> return $ e == s) myTest = isErrorCall "This will only run for positive numbers" . f2 {- >> myTest (-1) = return True >> myTest 100 = return False -} ``` HTH, Joachim From dedgrant at gmail.com Sat Oct 31 10:40:45 2015 From: dedgrant at gmail.com (Darren Grant) Date: Sat, 31 Oct 2015 21:40:45 +1100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: <563494E6.4070508@home.nl> References: <563494E6.4070508@home.nl> Message-ID: Unfrotunately the answer to this is not simple: http://stackoverflow.com/questions/4243117/how-to-catch-and-ignore-a-call-to-the-error-function 'error' more or less terminates the program in an unreasonable way. It would be preferable for f2 to result in a type that can contain the error result to be parsed. Cheers, Darren On Oct 31, 2015 21:16, "Roelof Wobben" wrote: > Hello, > > I have made this exercise which can be found at the Craft of Functional > Programming book. > > -- exercise 32 > > -- Suppose we have to raise 2 to the power n. If n is even, 2*m say, then > -- 2n = 22*m = (2m)2 > -- If n is odd, 2*m+l say, then > -- 2n = 22*m+l = (2n)2*2 > -- Give a recursive function to compute 2n which uses these insights. > > f2 :: Integer -> Integer > f2 n > | n < 0 = error "This will only run for positive numbers" > | n == 0 = 1 > | even n = f2 ( n `div` 2) ^ 2 > | odd n = (f2 ( n `div` 2) ^ 2) * 2 > > > Now I have to make Hunit tests for it, > > But is there a way I can test if the error message is shown when a > negative number is being used ? > > Roelof > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Oct 31 10:46:15 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 31 Oct 2015 11:46:15 +0100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: References: <563494E6.4070508@home.nl> Message-ID: <56349BF7.1000604@home.nl> Op 31-10-2015 om 11:40 schreef Darren Grant: > > Unfrotunately the answer to this is not simple: > > http://stackoverflow.com/questions/4243117/how-to-catch-and-ignore-a-call-to-the-error-function > > 'error' more or less terminates the program in an unreasonable way. > > It would be preferable for f2 to result in a type that can contain the > error result to be parsed. > > Cheers, > Darren > > Oke, So I have to change the type of f2. To what do I have to change it to make it testable. Roelof From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Oct 31 11:04:05 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 31 Oct 2015 11:04:05 +0000 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: <56349BF7.1000604@home.nl> References: <563494E6.4070508@home.nl> <56349BF7.1000604@home.nl> Message-ID: <20151031110405.GA1670@weber> On Sat, Oct 31, 2015 at 11:46:15AM +0100, Roelof Wobben wrote: > Op 31-10-2015 om 11:40 schreef Darren Grant: > > > >Unfrotunately the answer to this is not simple: > > > >http://stackoverflow.com/questions/4243117/how-to-catch-and-ignore-a-call-to-the-error-function > > > >'error' more or less terminates the program in an unreasonable way. > > > >It would be preferable for f2 to result in a type that can contain > >the error result to be parsed. > > So I have to change the type of f2. > > To what do I have to change it to make it testable. For example, Integer -> Maybe Integer From dedgrant at gmail.com Sat Oct 31 11:04:42 2015 From: dedgrant at gmail.com (Darren Grant) Date: Sat, 31 Oct 2015 22:04:42 +1100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: <56349BF7.1000604@home.nl> References: <563494E6.4070508@home.nl> <56349BF7.1000604@home.nl> Message-ID: I'd expect most Haskellers to recommend something like, f2 :: Integer -> Either Integer ErrorString where ErrorString is some specific error value type. (String may suffice for you.) This is a safe general solution, but there are many potentially more specific possibilities that might make your program simpler depending on how this function relates to the context it will be used in. Cheers, Darren On Oct 31, 2015 21:46, "Roelof Wobben" wrote: > Op 31-10-2015 om 11:40 schreef Darren Grant: > >> >> Unfrotunately the answer to this is not simple: >> >> >> http://stackoverflow.com/questions/4243117/how-to-catch-and-ignore-a-call-to-the-error-function >> >> 'error' more or less terminates the program in an unreasonable way. >> >> It would be preferable for f2 to result in a type that can contain the >> error result to be parsed. >> >> Cheers, >> Darren >> >> >> > > Oke, > > So I have to change the type of f2. > > To what do I have to change it to make it testable. > > Roelof > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vandijk.roel at gmail.com Sat Oct 31 11:10:47 2015 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Sat, 31 Oct 2015 12:10:47 +0100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: References: <563494E6.4070508@home.nl> <56349BF7.1000604@home.nl> Message-ID: Small nitpick, but I would generally put the "exception" or "error" in the Left part of an Either and a correct result in the Right part. This has some advantages. 1 - Right is right as opposed to wrong. Easy to remember mnemonic. 2 - It fits neatly with the Monad (Either e) instance. Roelof, a nice exercise is to first implement your f2 function with the Integer -> Maybe Integer type and then with Integer -> Either String Integer. If you realize that both Monad Maybe and Monad (Either e) you can use almost the same code. 2015-10-31 12:04 GMT+01:00 Darren Grant : > I'd expect most Haskellers to recommend something like, > > f2 :: Integer -> Either Integer ErrorString > > where ErrorString is some specific error value type. (String may suffice > for you.) > > This is a safe general solution, but there are many potentially more > specific possibilities that might make your program simpler depending on > how this function relates to the context it will be used in. > > Cheers, > Darren > On Oct 31, 2015 21:46, "Roelof Wobben" wrote: > >> Op 31-10-2015 om 11:40 schreef Darren Grant: >> >>> >>> Unfrotunately the answer to this is not simple: >>> >>> >>> http://stackoverflow.com/questions/4243117/how-to-catch-and-ignore-a-call-to-the-error-function >>> >>> 'error' more or less terminates the program in an unreasonable way. >>> >>> It would be preferable for f2 to result in a type that can contain the >>> error result to be parsed. >>> >>> Cheers, >>> Darren >>> >>> >>> >> >> Oke, >> >> So I have to change the type of f2. >> >> To what do I have to change it to make it testable. >> >> Roelof >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Oct 31 12:27:16 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 31 Oct 2015 13:27:16 +0100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: References: <563494E6.4070508@home.nl> <56349BF7.1000604@home.nl> Message-ID: <5634B3A4.9060507@home.nl> An HTML attachment was scrubbed... URL: From dedgrant at gmail.com Sat Oct 31 12:44:39 2015 From: dedgrant at gmail.com (Darren Grant) Date: Sat, 31 Oct 2015 23:44:39 +1100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: <5634B3A4.9060507@home.nl> References: <563494E6.4070508@home.nl> <56349BF7.1000604@home.nl> <5634B3A4.9060507@home.nl> Message-ID: You're very close. Take a look at the even clause: Let (k :: Integer), and consider how the type of the expression producing the error, Just (f2Maybe k) differs from the type of the expression, (f2Maybe k) Cheers, Darren On Sat, Oct 31, 2015 at 11:27 PM, Roelof Wobben wrote: > Op 31-10-2015 om 12:10 schreef Roel van Dijk: > > Small nitpick, but I would generally put the "exception" or "error" in the > Left part of an Either and a correct result in the Right part. > > This has some advantages. > 1 - Right is right as opposed to wrong. Easy to remember mnemonic. > 2 - It fits neatly with the Monad (Either e) instance. > > Roelof, a nice exercise is to first implement your f2 function with the Integer > -> Maybe Integer type and then with Integer -> Either String Integer. > If you realize that both Monad Maybe and Monad (Either e) you can use > almost the same code. > > 2015-10-31 12:04 GMT+01:00 Darren Grant : > >> I'd expect most Haskellers to recommend something like, >> >> f2 :: Integer -> Either Integer ErrorString >> >> where ErrorString is some specific error value type. (String may suffice >> for you.) >> >> This is a safe general solution, but there are many potentially more >> specific possibilities that might make your program simpler depending on >> how this function relates to the context it will be used in. >> >> Cheers, >> Darren >> On Oct 31, 2015 21:46, "Roelof Wobben" wrote: >> >>> Op 31-10-2015 om 11:40 schreef Darren Grant: >>> >>>> >>>> Unfrotunately the answer to this is not simple: >>>> >>>> >>>> http://stackoverflow.com/questions/4243117/how-to-catch-and-ignore-a-call-to-the-error-function >>>> >>>> 'error' more or less terminates the program in an unreasonable way. >>>> >>>> It would be preferable for f2 to result in a type that can contain the >>>> error result to be parsed. >>>> >>>> Cheers, >>>> Darren >>>> >>>> >>>> >>> > > Here my try for the Maybe > > > f2Maybe :: Integer -> Maybe Integer > f2Maybe n > | n > 0 = Nothing > | n == 0 = Just 1 > | even n = Just (f2Maybe ( n `div` 2) ^ 2) > | odd n = Just ((f2Maybe ( n `div` 2) ^ 2) * 2) > > > But it will not compile , the clauses for even and odd do not work. > > Both maybe and either are not explained in the first 4 chapter of the > Craft book. > > Roelof > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Oct 31 13:08:34 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 31 Oct 2015 14:08:34 +0100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: References: <563494E6.4070508@home.nl> <56349BF7.1000604@home.nl> <5634B3A4.9060507@home.nl> Message-ID: <5634BD52.20604@home.nl> Op 31-10-2015 om 13:44 schreef Darren Grant: > You're very close. Take a look at the even clause: Let (k :: Integer), > and consider how the type of the expression producing the error, > > Just (f2Maybe k) > > differs from the type of the expression, > > (f2Maybe k) > > Cheers, > Darren > Just (f2Maybe k) is type Maybe (Maybe Integer) f2Maybe k is type Maybe Integer But when I change the code to this : f2Maybe :: Integer -> Maybe Integer f2Maybe n | n > 0 = Nothing | n == 0 = Just 1 | even n = f2Maybe ( n `div` 2) ^ 2 | odd n = (f2Maybe ( n `div` 2) ^ 2) * 2 Then I see this error message : No instance for (Num (Maybe Integer)) arising from a use of ?^? In the expression: f2Maybe (n `div` 2) ^ 2 In an equation for ?f2Maybe?: f2Maybe n | n > 0 = Nothing | n == 0 = Just 1 | even n = f2Maybe (n `div` 2) ^ 2 | odd n = (f2Maybe (n `div` 2) ^ 2) * 2 Failed, modules loaded: none. No instance for (Num (Maybe Integer)) arising from a use of ?^? In the expression: f2Maybe (n `div` 2) ^ 2 In an equation for ?f2Maybe?: f2Maybe n | n > 0 = Nothing | n == 0 = Just 1 | even n = f2Maybe (n `div` 2) ^ 2 | odd n = (f2Maybe (n `div` 2) ^ 2) * 2 Failed, modules loaded: none. No instance for (Num (Maybe Integer)) arising from a use of ?^? In the expression: f2Maybe (n `div` 2) ^ 2 In an equation for ?f2Maybe?: f2Maybe n | n > 0 = Nothing | n == 0 = Just 1 | even n = f2Maybe (n `div` 2) ^ 2 | odd n = (f2Maybe (n `div` 2) ^ 2) * 2 Failed, modules loaded: none. From vandijk.roel at gmail.com Sat Oct 31 13:56:47 2015 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Sat, 31 Oct 2015 14:56:47 +0100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: <5634BD52.20604@home.nl> References: <563494E6.4070508@home.nl> <56349BF7.1000604@home.nl> <5634B3A4.9060507@home.nl> <5634BD52.20604@home.nl> Message-ID: You are even closer now! What the type checker is trying to tell you is that it doesn't know how to raise Maybe Integer to some power. You apply the ^ operator to two values, f2Maybe (n `div` 2) and 2. Let us give them names: let a = f2Maybe (n `div` 2) :: Maybe Integer b = 2 :: Int in a ^ b You see that the type of a is Maybe Integer. What does this mean? There are only 2 cases to consider. You have Just an integer or you have Nothing. You can use the case construct to write the code for both cases. f2Maybe :: Integer -> Maybe Integer f2Maybe n | n > 0 = Nothing | n == 0 = Just 1 | even n = case f2Maybe (n `div` 2) of Just x -> Nothing -> | odd n = case f2Maybe (n `div` 2) of Just x -> Nothing -> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Sat Oct 31 14:09:00 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Sat, 31 Oct 2015 15:09:00 +0100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: References: <563494E6.4070508@home.nl> Message-ID: I think you misinterpreted that answer. As far as I'm aware, `error` (except in its type) is no less reasonable than other exceptions, and you can catch it in IO. So as long as you run a test in IO, you can test for the call to `error` (as Joachim showed in another reply). Regards, Erik On 31 October 2015 at 11:40, Darren Grant wrote: > Unfrotunately the answer to this is not simple: > > http://stackoverflow.com/questions/4243117/how-to-catch-and-ignore-a-call-to-the-error-function > > 'error' more or less terminates the program in an unreasonable way. > > It would be preferable for f2 to result in a type that can contain the error > result to be parsed. > > Cheers, > Darren > > On Oct 31, 2015 21:16, "Roelof Wobben" wrote: >> >> Hello, >> >> I have made this exercise which can be found at the Craft of Functional >> Programming book. >> >> -- exercise 32 >> >> -- Suppose we have to raise 2 to the power n. If n is even, 2*m say, then >> -- 2n = 22*m = (2m)2 >> -- If n is odd, 2*m+l say, then >> -- 2n = 22*m+l = (2n)2*2 >> -- Give a recursive function to compute 2n which uses these insights. >> >> f2 :: Integer -> Integer >> f2 n >> | n < 0 = error "This will only run for positive numbers" >> | n == 0 = 1 >> | even n = f2 ( n `div` 2) ^ 2 >> | odd n = (f2 ( n `div` 2) ^ 2) * 2 >> >> >> Now I have to make Hunit tests for it, >> >> But is there a way I can test if the error message is shown when a >> negative number is being used ? >> >> Roelof >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From dedgrant at gmail.com Sat Oct 31 14:39:26 2015 From: dedgrant at gmail.com (Darren Grant) Date: Sun, 1 Nov 2015 01:39:26 +1100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: References: <563494E6.4070508@home.nl> Message-ID: Good clarification. Cheers, Darren On Nov 1, 2015 01:09, "Erik Hesselink" wrote: > I think you misinterpreted that answer. As far as I'm aware, `error` > (except in its type) is no less reasonable than other exceptions, and > you can catch it in IO. So as long as you run a test in IO, you can > test for the call to `error` (as Joachim showed in another reply). > > Regards, > > Erik > > On 31 October 2015 at 11:40, Darren Grant wrote: > > Unfrotunately the answer to this is not simple: > > > > > http://stackoverflow.com/questions/4243117/how-to-catch-and-ignore-a-call-to-the-error-function > > > > 'error' more or less terminates the program in an unreasonable way. > > > > It would be preferable for f2 to result in a type that can contain the > error > > result to be parsed. > > > > Cheers, > > Darren > > > > On Oct 31, 2015 21:16, "Roelof Wobben" wrote: > >> > >> Hello, > >> > >> I have made this exercise which can be found at the Craft of Functional > >> Programming book. > >> > >> -- exercise 32 > >> > >> -- Suppose we have to raise 2 to the power n. If n is even, 2*m say, > then > >> -- 2n = 22*m = (2m)2 > >> -- If n is odd, 2*m+l say, then > >> -- 2n = 22*m+l = (2n)2*2 > >> -- Give a recursive function to compute 2n which uses these insights. > >> > >> f2 :: Integer -> Integer > >> f2 n > >> | n < 0 = error "This will only run for positive numbers" > >> | n == 0 = 1 > >> | even n = f2 ( n `div` 2) ^ 2 > >> | odd n = (f2 ( n `div` 2) ^ 2) * 2 > >> > >> > >> Now I have to make Hunit tests for it, > >> > >> But is there a way I can test if the error message is shown when a > >> negative number is being used ? > >> > >> Roelof > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachifm at fastmail.fm Sat Oct 31 16:18:18 2015 From: joachifm at fastmail.fm (joachifm at fastmail.fm) Date: Sat, 31 Oct 2015 17:18:18 +0100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: References: <563494E6.4070508@home.nl> Message-ID: <1446308298.1723186.425412425.590D6D91@webmail.messagingengine.com> The ability to express non-termination is a feature, not a bug. If the program truly cannot produce a useful result for some input, it should crash, the earlier the better. Wrapping the return value ONLY to make a non-total program *appear* total is kind of ugly (and commits you to a potentially inappropriate/nonsensical model for the problem at hand). It is cleaner to either constrain the input to values you're prepared to deal with or crash when the implicit invariant is violated. From r.wobben at home.nl Sat Oct 31 16:43:37 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 31 Oct 2015 17:43:37 +0100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: References: <563494E6.4070508@home.nl> <56349BF7.1000604@home.nl> <5634B3A4.9060507@home.nl> <5634BD52.20604@home.nl> Message-ID: <5634EFB9.8000606@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Oct 31 17:32:43 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 31 Oct 2015 18:32:43 +0100 Subject: [Haskell-cafe] testing for exceptions In-Reply-To: <5634EFB9.8000606@home.nl> References: <563494E6.4070508@home.nl> <56349BF7.1000604@home.nl> <5634B3A4.9060507@home.nl> <5634BD52.20604@home.nl> <5634EFB9.8000606@home.nl> Message-ID: <5634FB3B.3070806@home.nl> An HTML attachment was scrubbed... URL: From simon at joyful.com Sat Oct 31 21:38:13 2015 From: simon at joyful.com (Simon Michael) Date: Sat, 31 Oct 2015 14:38:13 -0700 Subject: [Haskell-cafe] ANN: hledger-0.27, with more console power Message-ID: <3219334D-DCCF-4E2C-B64F-120D3D0752F9@joyful.com> I'm pleased to announce hledger 0.27! What is it ? hledger is a cross-platform program for tracking money, time, or any other commodity, using double-entry accounting and a simple, editable file format. It can also read CSV or timelog files, and export CSV. It provides command-line, curses and web interfaces, and aims to be a reliable, practical tool for daily use. It is inspired by and largely compatible with ledger(1). What's new ? This release introduces hledger-ui, a new curses-style interface that I'm quite pleased with (not yet available on Windows). Built on vty and the new brick library, it lets you review account balances and transactions with fewer keystrokes and less effort. Ledger users with compatible journal files may also find this useful. hledger can now report current value based on market prices (hurrah); wide characters are displayed properly; regular expression account aliases are fast; and unix man pages are provided. You can see all changes and bugfixes at http://hledger.org/release-notes#hledger-0.27 . Release contributors: Simon Michael, Carlos Lopez-Camey. How to get it ? hledger can be installed with cabal or stack - see http://hledger.org/download for guidance. If you'd like to contribute Windows or Mac binaries, please get in touch. Happy Hallowe'en! -Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: