- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Looking for feedback on my beginner's Haskell resource
by Olaf Klinke 03 Nov '18

03 Nov '18

This guide would be a perfect fit for literate Haskell [1]. It is a file format where you mix markup (e.g. LaTeX) and Haskell, so the file can be interpreted either way. In a nutshell, your html content becomes Haskell comments or the Haskell becomes <code> blocks in html. In that way, your readers could just load your document into ghci and play with it. Not sure whether html is supported out of the box, though. You might need to pass the .lhs file through pandoc [2] or another tool. Can anyone clarify/help on this? Cheers, Olaf [1] https://wiki.haskell.org/Literate_programming [2] https://groups.google.com/forum/#!topic/hakyll/lFfHAk2nxbs

1 0

Get number of fields for non-record ADTs using Data type class?
by Markus Läll 03 Nov '18

03 Nov '18

Dear list, Is it possible te get the number of fields for data constructors for a plain ADT, i.e something with no record fields? E.g for data T = A Int Double | B String (Maybe String) it would give 2 for both `A` and `B`. For a record it's possible using the `constrFields` function from Data.Data. I was trying to follow this tutorial by Christopher Done https://chrisdone.com/posts/data-typeable, and I feel that it must be possible somehow to get these numbers with the gmap*/gfold* functions, but the use of them is over my head at the moment. Best, -- Markus Läll

3 5

Re: [Haskell-cafe] 2018 State of Haskell Survey
by Doug McIlroy 03 Nov '18

03 Nov '18

The survey didn't work for me in either Internet Explorer or Microsoft Edge: In IE an attempt to scroll a pull-down "Add an option" menu would dismiss the menu. In ME the same menus needed a scroll bar, but the bar was missing. Doug McIlroy

1 0

2018 State of Haskell Survey
by Jasper Van der Jeugt 02 Nov '18

02 Nov '18

Hi all, (apologies if you receive multiple copies of this email) We are running a 2018 State of Haskell Survey here: https://airtable.com/shr8G4RBPD9T6tnDf If you have some time to spare, please submit a response. This goes a long way in helping the community. The survey closes on the 15th of November. This survey is co-sponsored by Haskell.org and Haskell Weekly, but I'd like to give credit where credit is due, so I'll add that Taylor Fausak did almost all of the hard work -- thanks a lot! Kind regards Jasper Van der Jeugt on behalf of the Haskell.org committee

2 1

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 28 Oct '18

28 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 28 Oct '18

28 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 25 Oct '18

25 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