- Haskell-Cafe - Haskell.org

Intention to Take Over adblock2privoxy Hackage Package
by Steven Smith 30 Oct '18

30 Oct '18

Dear Haskell Cafe, I’m writing to publicly state my intention to take over the adblock2privoxy Hackage package: http://hackage.haskell.org/package/adblock2privoxy <http://hackage.haskell.org/package/adblock2privoxy> using the forked github repo at: https://github.com/essandess/adblock2privoxy <https://github.com/essandess/adblock2privoxy> I have been unable to contact the package’s creator/maintainer at the email provided, and the original repo <https://projects.zubr.me/wiki/adblock2privoxy> has not been updated for several years. I forked this project about a year and a half ago, and since then have addressed <https://github.com/essandess/adblock2privoxy/commits/master> many issues and incorporated feedback and fixed from the github community, including compilation with the most recent GHC compiler. I am following up on a suggestion made here to publish the latest version in Hackage, following the procedure to take over a package: https://github.com/essandess/adblock2privoxy/pull/29#issue-215776931 <https://github.com/essandess/adblock2privoxy/pull/29#issue-215776931> https://wiki.haskell.org/Taking_over_a_package <https://wiki.haskell.org/Taking_over_a_package> My Hackage username is essandess. Sincerely, Steve

1 0

Call For Workshop Proposals
by Sam Tobin-Hochstadt 30 Oct '18

30 Oct '18

CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming August 18 - 23, 2019 Berlin, Germany https://icfp19.sigplan.org/ The 24th ACM SIGPLAN International Conference on Functional Programming will be held in Berlin, Germany on August 18-23, 2019. 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 symposiums) to be affiliated with ICFP 2019 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 August 18th (the day before ICFP) and 22-23th of August (the two days after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: November 25, 2018 Notification of acceptance: December 23, 2018 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 2019 workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019(a)googlegroups.com by November 25, 2018. (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 23, 2018, 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/icfp2019-files/icfp19-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 2019 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Jennifer Hackett (University of Nottingham) Workshop Co-Chair: Christophe Scholliers (University of Ghent) General Chair: Derek Dreyer (MPI-SWS) Program Chair: François Potier (Inria) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019(a)googlegroups.com

1 0

ANN: Major releases of 'fltkhs-themes' and 'fltkhs' for nice looking, portable native GUIs
by aditya siram 29 Oct '18

29 Oct '18

I'm happy to announce two major releases: fltkhs-themes [1] : a drop-in replacement to FLTKHS [2] with a vastly better looking UX [3] . The small but growing showcase app should hopefully give a better feel for it. And to help you get started with your own project there is a starter app [7] and a lot more documentation [8]. fltkhs[2]: the underlying GUI binding to FLTK which after nearly 6 months of continuous work has been overhauled with a ton of bug fixes and shoring up of the API (fixing leaks, making types more precise via newtypes etc.) and new features have been added including new widgets and out-of-the-box HiDPI and SVG support (which fltkhs-themes relies on heavily for nicer widgets). All the starter kits and demo packages have been updated to this version. If you need help migrating an existing app to the new API feel free to send email to the address on Hackage page or hit me up on Twitter. There a lot more documentation on installation and getting started in the Hackage docs [4]. As always if you have any problems please open an issue on fltkhs [5], fltkhs-themes or any of my other repos. Hopefully these releases help you make Haskell native GUI apps that are fast, portable, easy to install/deploy, and nice looking! [1] http://hackage.haskell.org/package/fltkhs-themes [2] http://hackage.haskell.org/package/fltkhs [3] https://github.com/deech/fltkhs-themes-demo#screenshots [4] http://hackage.haskell.org/package/fltkhs/docs/Graphics-UI-FLTK-LowLevel-FL… [5] https://github.com/deech/fltkhs/issues [6] https://github.com/deech/fltkhs-themes/issues [7] https://github.com/deech/fltkhs-light-theme-skeleton [8] http://hackage.haskell.org/package/fltkhs-themes/docs/Graphics-UI-FLTK-Them…

1 0

Munich Haskell Meeting, 2018-10-30 @ 19:30
by Leah Neukirchen 29 Oct '18

29 Oct '18

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, October 30 at Augustiner-Gaststätte Rumpler at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html 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-2018/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

1 0

mfix for a nested monad
by Benjamin Redelings 26 Oct '18

26 Oct '18

Hi, I'm trying to implement mfix for a monad that is nested inside another monad. I came up with the following logic for how to implement this, but I suspect there are some things I'm missing. My conclusion is that I want interpret (MFix f) = mfix (interpret.f) Does this seem right? Has this situation been discussed somewhere? -BenRI P.S. Here's what I mean by the monad being nested in another monad. Let's say that the monad M2 has interpreter i2, with type i2 :: M2 a -> M1 a and then M1 is the other monad, and has interpreter i1: i1 :: M1a -> a I suppose that the nesting is really a nesting of interpreters. P.P.S. I came up with some equational reasoning for how to treat mfix in the i2 interpreter. (a) For some interpreters `i`, it makes sense to require i (mfix f) = let x = (i . f) x in x (b) I want the composition of interpreters (i1.i2) to act like (a) above: (i1 . i2) (mfix f) = let x = (i1 . i2 . f) x in x (c) Rearranging, and then substituting using (a): i1 (i2 (mfix f)) = let x = i1 . (i2 . f) x in x = i1 (mfix (i2 . f)) (d) Therefore, we could set i2 (mfix f) = mfix (i2 . f) I'm probably going to make a `data` declaration for M2 so I could actually write i2 (Mfix f) = mfix (i2 . f) -BenRI

2 1

Re: [Haskell-cafe] Impossible types [was [Haskell-prime]: A question about run-time errors when class members are undefined]
by Anthony Clayden 25 Oct '18

25 Oct '18

Transferring from https://mail.haskell.org/pipermail/haskell-prime/2018-October/004396.html On Sat, 13 Oct 2018 at 4:04 AM, <camarao(a)dcc.ufmg.br> wrote: > > Consider for example: > > class F a b where f:: a → b > class X a where x:: a > fx = f x > > The type of fx, (F a b, X a) ⇒ b, should not be ambiguous: in > distinct contexts, fx can have distinct types (if ambiguity, and > 'improvement', are as defined below). [See the -prime message for the "defined below".] I'm just not seeing why you think any Haskell should accept that. What value could inhabit `fx` except bottom? And indeed no Haskell does accept it, not even GHC with all sorts of nasty extensions switched on, including `AllowAmbiguousTypes`. GHC will accept class `F` with a Functional Dependency `b -> a`, but still I can't 'poke' any value into the `x` argument to `f` in the equation for `fx`. Note: agreeing with this view can lead to far-reaching consequences, e.g. > support of > overloaded record fields [1,Section 7], ... There are other ways to support overloaded/duplicate record fields, without doing this much violence to the type system. Look at the `HasField` class using Functional Dependencies, in Adam Gundry's work. polymonads [2] etc. > Note that's from a Trac ticket asking for 'dysfunctional' Functional Dependencies. There's a long discussion from the type-inference brains trust coming to no discernable conclusion as to whether it's broken type safety. (Catching incoherence in the Core lint typecheck is not a good look.) a) You've not shown any detailed working of how your proposal gives the type improvement required without also descending into incoherence. b) The combination of Functional Dependencies+Overlapping Instances+Undecidable Instances might be able to cover just enough, but not too much of the requirements (which were never made clear). See my worked examples on that ticket -- some of which are really quite scary. See some of Oleg's work on his ftp site with multi-directional FunDeps and overlaps to achieve injectivity. To try to tame the scariness while still supporting enough power, see the suggestion here https://ghc.haskell.org/trac/ghc/ticket/15632 > Further examples can be discussed I have yet to see a convincing use case (from the very lengthy discussions) which couldn't be handled already in GHC. I agree the combination of extensions in GHC (including its bogus consistency check/Trac #10675) can give alarming surprises; but they don't quite break type safety. but this example conveys the > main idea that ambiguity should be changed; unlike the example > of (show . read), no type annotation can avoid ambiguity of > polymorphic fx in current Haskell. Since `fx` is not accepted in current Haskell, whether you can put a type annotation seems beside the point. AntC [1] Optional Type Classes for Haskell, Rodrigo Ribeiro, Carlos Camarão, Lucília Figueiredo, Cristiano Vasconcellos, SBLP'2016 (20th Brazilian Symposium on Programming Languages), Marília, SP, September 19-23, 2016. [2] https://github.com/carlos1camarao/ghc-proposals/blob/d81c1f26298961ac635ce0…

2 2

property testing with context
by Ben Franksen 25 Oct '18

25 Oct '18

Hi everyone it seems to be the season for new variations on the "property testing" theme, so I would like to chime in... not to announce a new library, sadly, but with a rough idea how the existing ones could perhaps be improved, based on practical experience in Darcs. The problem I have is that there is a tension between (a) stating a property in a clear and simple way, so its code doubles as a formal specification and (b) writing the property in such a way that when it fails, the reported value(s) give enough information about the context to be useful for finding the cause of the problem. Let me give an example to demonstrate what I mean. There is a simple law that says if a sequential pair of patches A;B commutes to B';A' then B';A' commutes back to A;B. In code this looks (more or less) like this: prop_recommute :: Commute p => (p :> p) wA wB -> Bool prop_recommute (x:>y) | Just (y':>x') <- commute (x:>y) = case commute (y':>x')of Just (x'':>y'') -> x==x'' && y==y'' Nothing -> False | otherwise = True This is a bit more verbose than the informal spec but still quite readable. Now suppose this property fails. So quickcheck reports the counter example pair (X:>Y) for some X and Y. But that isn't too useful in itself. We'd like to know a bit more: * did the second commute fail? * or did it succeed but x/=x'' or y/=y''? * and in the latter case, which of the two? So in practice our property code looks more like this: prop_recommute :: (ShowPatch p, Commute p) => (p :> p) wA wB -> Bool prop_recommute (x :> y) | Just (y' :> x') <- commute (x :> y) = case commute (y' :> x') of Nothing -> failed (redText "failed, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x') Just (x'' :> y'') -> if y'' /= y then failed (redText "y'' =/\\= y failed, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x' $$ redText "x''" $$ displayPatch x'' $$ redText ":> y''" $$ displayPatch y'') else if x'' /= x then failed (redText "x'' /= x, where x" $$ displayPatch x $$ redText ":> y" $$ displayPatch y $$ redText "y'" $$ displayPatch y' $$ redText ":> x'" $$ displayPatch x' $$ redText "x''" $$ displayPatch x'' $$ redText ":> y''" $$ displayPatch y'') else True | otherwise = True Now this code tells us exactly what went wrong when the property fails but it is ugly and repetitive and the additional code obscures the simple logical content. So this is no longer quite as suitable for a (human readable) formal spec. I wonder if displaying (1) all relevant contextual variables and (2) "where in the code it fails" could be automated away, somehow. I guess this is not trivial and may require syntactic analysis, so perhaps expecting a /library/ to solve the problem is unrealistic, except perhaps by using Template Haskell. I'd also go with a separate tool that extracts properties from a module and enriches them with code that displays the additional information. Tackling this problem might be an interesting theme for a master thesis... ;-) Cheers Ben

4 7

Has twidge stopped working?
by Rider of Giraffes 24 Oct '18

24 Oct '18

Greetings, New on the list, apologies if I break any traditions. Sent here from https://github.com/jgoerzen/twidge/wiki with the question in the header. I sent a tweet via twidge on Oct 22, but since then nothing has got through. Has twidge stopped working? Has Twitter made yet another change to the API, this one incompatible? All assistance and advice welcome. Thank you. -- I don't suffer from stress - I'm a carrier.

2 1

Re: [Haskell-cafe] property testing with context
by Olaf Klinke 24 Oct '18

24 Oct '18

Ben, the solution might be simple: Don't express the property as an atomic function (a -> Bool). This reminds me a bit of the Cutty-Howard correspondence, only that proofs are replaced by counterexamples. A testing library should have an operator for each of the logical connectives, where - a counterexample to True is never found - a counterexample to False is () - a counterexample to (not x) is an example for x - a counterexample to (x && y) is either a counterexample to x or a counterexample to y, whichever is found first - a counterexample to (x || y) is a pair of counterexamples to both x and y - a counterexample to (x ==> y) is an example for x together with a counterexample for y Then, if you build your property out of smaller properties and the connectives above, the counterexample-finder would be able to inform you which part of the property failed. I'm pretty sure at least one of the testing libraries has a system like this. Cheers, Olaf

2 1

ANN: Yampa-0.12 and yampa-test (QuickCheck-based FRP testing)
by Ivan Perez 22 Oct '18

22 Oct '18

Dear all, I am please to announce version 0.12 of Yampa! Yampa is a mature and robust FRP implementation that has been used to create mobile, desktop, and web games and applications, including commercial mobile games available on iTunes and Google Play, and open source games that use devices like wiimotes and kinect [1-2]. This version comes with an accompanying library, yampa-test, which includes QuickCheck-based testing with LTL-based signal predicates. These features are described in the ICFP 2017 paper "Testing and Debugging Functional Reactive Programming" [3]. Thanks to Christina Zeller for reporting bugs. Both libraries can be found here: http://hackage.haskell.org/package/Yampa http://hackage.haskell.org/package/yampa-test This version has been tested against all major GHC versions from 7.6 to 8.6. Some legacy code has been deprecated, which has triggered a major version bump (0.12). I would expect all projects that use Yampa to work by, at most, adapting the version constraints in the cabal files. New versions of Yampa will present a simpler API, better documentation and benchmarks [4]. As always, contributions are welcome. There are a number of issues on the github page that are particularly suitable for beginners [5]. Happy Haskelling! Ivan [1] https://github.com/ivanperez-keera/Yampa#other-examples [2] https://haskell.games [3] https://dl.acm.org/citation.cfm?id=3110246 [4] https://github.com/ivanperez-keera/Yampa/milestones [5] https://github.com/ivanperez-keera/Yampa/labels/help%20wanted

1 0