- Haskell-Cafe - Haskell.org

Coverage icon on hackage
by Ivan Perez 07 May '22

07 May '22

Hi all, What analysis does the hackage server run to determine the coverage level of, or rating given to, a particular package? For example, for one package it is showing this icon: https://img.shields.io/static/v1?label=Coverage&message=32%&color=red What does that actually mean? The build log states: Code Coverage expressions 32% (224/684) booleanguards 100% (0/0) conditions 20% (1/5) qualifiers 100% (0/0) alternatives 27% (5/18) local declarations 40% (6/15) top-level declarations 32% (29/90) Is it possible to see details of how hackage is arriving to these conclusion, and to replicate these results locally? Thanks, Ivan

3 4

[ANN] mtl-2.3
by Emily Pillmore 07 May '22

07 May '22

Hello Everyone, mtl-2.3 has been released. This release marks the first major version for the library in a long time, and addresses some longstanding issues that have taken years to fix. As a result, this will be a *breaking update* for many. Please review the following changelog notes: * Added instances for Control.Monad.Trans.Writer.CPS and Control.Monad.Trans.RWS.CPS from transformers 0.5.6 and add Control.Monad.Writer.CPS and Control.Monad.RWS.CPS. * Control.Monad.Cont now re-exports evalCont and evalContT. * Add tryError , withError , handleError , and mapError to Control.Monad.Error.Class , and re-export from Control.Monad.Except. * Remove Control.Monad.List and Control.Monad.Error. * Remove instances of deprecated ListT and ErrorT. * Remove re-exports of Error. * Add instances for Control.Monad.Trans.Accum and Control.Monad.Trans.Select ( http://control.monad.trans.select/ ). * Require GHC 8.6 or higher, and cabal-install 3.0 or higher. * Require transformers-0.5.6 or higher. * Add Control.Monad.Accum for the MonadAccum type class, as well as the LiftingAccum deriving helper. * Add Control.Monad.Select ( http://control.monad.select/ ) for the MonadSelect type class, as well as the LiftingSelect deriving helper. A big thank you to all contributors and commentators, and a special thanks to Koz for picking up maintenance so swiftly. Happy hacking, Emily

2 1

Re: [Haskell-cafe] data/newtype examples
by Olaf Klinke 06 May '22

06 May '22

> Dear Cafe - > > > I wanted a quick example (for teaching) > that shows a difference between data and newtype. > > What examples do you use? > I'm interested both in simple ones, > and confusing/obfuscated ones. Perhaps on the obscure side: I like to play with different implementations of Void. Let the students demonstrate that newtype Void = Void Void contains only one element whereas data Void = Void Void contains infinitely many elements that can be distinguished by pattern matching. Also consider data Void = Void !Void. Is this observably different from the Void newtype? Since you will have to explain lifting, you can also demonstrate that(,) is not the categorical product. Olaf

1 0

GHC proposal for ImplicitQualifiedImport
by Tristan Cacqueray 06 May '22

06 May '22

Dear Café, I've proposed a new language extensions to enable implicit imports, so that a qualified name can be used without adding an import declaration: https://github.com/ghc-proposals/ghc-proposals/pull/500 Would such an extension makes your life better? I value your feedback, so let me know what you think! Kind Regards, -Tristan

1 0

Was simplified subsumption worth it for industry Haskell programmers?
by pareto optimal 06 May '22

06 May '22

I originally posted on Reddit and the thread contains much debate and discussion. I'm concerned the views of the mailing list and likely ghc devs might not be as represented there or discourse, so i'm also copying it here. Copy-paste of post: Warning: Long post tl;dr - simplified subsumption seems to make common code I write in industry clunky for no good reason in lots of places - Are others concerned with motivating what seem like "pointless lambdas" to new hires or students for simple tasks? - Are there more real world advantages that make these frequent annoyances worth it? - How is quicklook impredicativity useful in industry? The biggest advantage seems to be that laziness is more predictable. However looking at [commits fixing simplified subsumption errors on github](https://github.com/search?q=simplified+subsumption+language%3Ahaske… I see very common patterns in industry Haskell now need an explicit lambda for "reasons" such as: readFreqSumFile :: (MonadSafe m) => FilePath -> m (FreqSumHeader, Producer FreqSumEntry m ()) - readFreqSumFile file = readFreqSumProd $ withFile file ReadMode PB.fromHandle + readFreqSumFile file = readFreqSumProd $ withFile file ReadMode (\h -> PB.fromHandle h) and: - toOrders <- asks _pdfConfToOrder + toOrders <- asks (\r -> _pdfConfToOrder r) And this typical use of id is no longer valid: instance MonadOrvilleControl IO where - liftWithConnection = id - liftFinally = id + liftWithConnection ioWithConn = ioWithConn + liftFinally ioFinally = ioFinally On my $work codebase that means hundreds of changes that make our code worse with seemingly no benefit. This case is addressed in the proposal, but seems to handwave this as: > The benefit, in terms of programming convenience, is small. >From my perspective while updating my codebase, it certainly doesn't feel that way. >From the persective of onboarding new Haskell hires, it doesn't feel simpler. I envision a future teaching session like: > student: This code looks correct but I get an error that means nothing to me of error: • Couldn't match type: b0 -> b0 with: forall q. q -> q Expected: p -> forall q. q -> q Actual: p -> b0 -> b0 • In the first argument of ‘g’, namely ‘f’ In the expression: g f In an equation for ‘h’: h = g f | | h = g f | ^ > me: Ah, that's because of something called simplified subsumption which we'll cover much later. > me: For now, just know putting it in an explicit lambda fixes it when you notice a compile error like that. > me: Now lets try to move past that and get back to basic file reading and writing > student: oookkkay? (feeling unsure, disillusioned about Haskell requiring pointless ceremony and being overly complex for no seeming benefit) Being a fan of and proponent of Haskell I think: If this complication is being added, surely something is made possible in return that gives more value. This led me to [the proposal](https://github.com/ghc-proposals/ghc-proposals/blob/master/propos… and I found with simplified subsumption: - Laziness characteristics and semantics of programs will be changed less, which I infer will lead to more predictable performance - I assume that simplifying a compiler step like this will speed up compile times and reduce space usage - Quick look impredicativity seems to be the real driving reason behind simplified subsumption and somehow makes dealing with very polymorphic code easier At this point my thought is: > Making highly polymorphic code simpler to write that isn't as typical in industry Haskell code in ways I can't determine without great effort was valued over "small incoveniences" that I'll run into daily But, still wanting to give the benefit of the doubt I dive face first into [The proposal for Quicklook impredicativity](https://github.com/ghc-proposals/ghc-proposals/blob/master…. Reading the whole thing, I still cannot ground this concept in real world terms that may effect me or that I could take advantage of. So, I go to the paper [A quick look at impredicativity](https://www.microsoft.com/en-us/research/publication/a-qui… and start reading many things I don't fully understand. Running out of energy, I start skimming and finally find some examples in section 10 APPLICATIONS. I see an example with gZipWithM that I still don't understand. Further down I see reference to pieces of code updated in Streamly that take advantage of quick look polymorphism and wonder why the real world example wasn't included and explained. So, i'm left frustrated with "simplified" subsumption and posting here for help answering: - Are others in the same boat? - Are there advantages i'm not seeing? - Can we use my reflection to improve industry/academic communication? And finally, any revant commentary surrounding this I may be oblivious to. Thanks!

5 5

data/newtype examples
by Johannes Waldmann 06 May '22

06 May '22

Dear Cafe - I wanted a quick example (for teaching) that shows a difference between data and newtype. You'd think that `newtype` makes things more strict, so we'd see more exceptions. Then try the following, and try to guess the semantics beforehand: ghci> data D = D Bool ghci> case D undefined of D x -> () ghci> case undefined of D x -> () ghci> newtype N = N Bool ghci> case N undefined of N x -> () ghci> case undefined of N x -> () What examples do you use? I'm interested both in simple ones, and confusing/obfuscated ones. Yes I know I can ghci> seq (D undefined) () () ghci> seq (N undefined) () *** Exception: Prelude.undefined but that `seq` is extra magic that needs to be explained. Well, perhaps I should. To show that I've done some homework here: the primary source of truth is the Haskell Language Report (well hidden at the bottomest end of https://www.haskell.org/documentation/) and it uses (in 4.2.3 Datatype Renamings) the concept of "equivalent to bottom". Then 6.2 Strict Evaluation shows how to test that with `seq` (without mentioning newtype, and that's fine since the Report is not a tutorial). This suggests that `seq` is really the way to go here. There are examples for data/newtype/case combined in 3.17.2 Informal Semantics of Pattern Matching but they distinguish between newtype N = N Bool and data D = D !Bool (with a bang). - J.W.

2 1

Deadline extension CfP: FMBC 2022 - 4th International Workshop on Formal Methods for Blockchains
by Zaynah Dargaye 04 May '22

04 May '22

FMBC 2022 Deadline Extension Call for Papers [ Please distribute, apologies for multiple postings. ] ======================================================================== 4rd International Workshop on Formal Methods for Blockchains (FMBC) - Deadline Extension Call https://fmbc.gitlab.io/2022 August 11, 2022, Haifa, Israel Co-located with The Federated Logic Conference 2022 (FLoC 22 -- https://www.floc2022.org/) as a satellite workshop of the 34th International Conference on Computer-Aided Verification (CAV 2022 -- http://i-cav.org/2022/) ----------------------------------------------------------------- Important dates --------------------- Abstract submission: May 3, 2022, *May 10, 2022* Full paper submission: May 10, 2022 *May 17, 2022* Notification: June 15, 2022 Camera-ready: July 13, 2022 Workshop: August 11, 2022 Deadlines are Anywhere on Earth -- https://en.wikipedia.org/wiki/Anywhere_on_Earth. ---------------------- ---------------------- TOPICS OF INTEREST --------------------- Blockchains are decentralized transactional ledgers that rely on cryptographic hash functions for guaranteeing the integrity of the stored data. Participants on the network reach agreement on what valid transactions are through consensus algorithms. Blockchains may also provide support for Smart Contracts. Smart Contracts are scripts of an ad-hoc programming language that are stored in the Blockchain and that run on the network. They can interact with the ledger’s data and update its state. These scripts can express the logic of possibly complex contracts between users of the Blockchain. Thus, Smart Contracts can facilitate the economic activity of Blockchain participants. With the emergence and increasing popularity of cryptocurrencies such as Bitcoin and Ethereum, it is now of utmost importance to have strong guarantees of the behavior of Blockchain software. These guarantees can be brought by using Formal Methods. Indeed, Blockchain software encompasses many topics of computer science where using Formal Methods techniques and tools are relevant: consensus algorithms to ensure the liveness and the security of the data on the chain, programming languages specifically designed to write Smart Contracts, cryptographic protocols, such as zero-knowledge proofs, used to ensure privacy, etc. This workshop is a forum to identify theoretical and practical approaches of formal methods for Blockchain technology. Topics include, but are not limited to: * Formal models of Blockchain applications or concepts * Formal methods for consensus protocols * Formal methods for Blockchain-specific cryptographic primitives or protocols * Design and implementation of Smart Contract languages * Verification of Smart Contracts ---------------------- ---------------------- SUBMISSION --------------------- Submit original manuscripts (not published or considered elsewhere) with a page limit of 12 pages for full papers and Systemization of Knowledge (SoK) papers, and 6 pages for short papers, and 2 pages for tool papers (excluding bibliography and short appendix of up to 5 additional pages). Alternatively you may also submit an extended abstract of up to 3 pages (including bibliography) summarizing your ongoing work in the area of formal methods and blockchain. Authors of selected extended abstracts are invited to give a short lightning talk. Submission link: https://easychair.org/conferences/?conf=fmbc2022 Authors are encouraged to use LaTeX and prepare their submissions according to the instructions and styling guides for OASIcs provided by Dagstuhl. Instructions for authors: https://submission.dagstuhl.de/series/details/5#author At least one author of an accepted paper is expected to present the paper at the workshop as a registered participant. -------------------- -------------------- PROCEEDINGS ------------------- All submissions will be peer-reviewed by at least three members of the program committee for quality and relevance. Accepted regular papers (full and short papers) will be included in the workshop proceedings. ---------------------- ---------------------- INVITED SPEAKER --------------------- Massimo Bartoletti, Professor, Università degli Studi di Cagliari, Italy ---------------------- ---------------------- PROGRAM COMMITTEE --------------------- PC CO-CHAIRS * Zaynah Dargaye (Nomadic Labs, France) (zaynah.dargaye(a)nomadic-labs.com) * Clara Schneidewind (MPI-SP, Germany) (clara.schneidewind(a)mpi-sp.org) PC MEMBERS Wolfgang Ahrendt (Chalmers University of Technology, Sweden) Leonardo Alt (Ethereum Foundation, Germany) Lacramioara Astefanoaei (Nomadic Labs, France) Roberto Blanco (MPI-SP, Germany) Joachim Breitner (Germany) Achim Brucker (University of Exeter, UK) Ethan Cecchetti (University of Maryland, USA) Manuel Chakravarty (IOHK & Tweag, Netherlands) Jing Chen (Algorand Inc, USA) Jérémie Decouchant (TU Delft, Netherlands) Antonella Del Pozzo (Université Paris-Saclay & CEA & List, France) Dana Drachsler Cohen (Technion, Israel) Cezara Dragoi (INRIA & ENS & CNRS & PSL, France) Ansgar Fehnker (Twente, Netherlands) Dominik Harz (Interlay & Imperial College London, UK) Lars Hupel (INNOQ, Germany) Igor Konnov (Informal Systems, Austria) Paul Laforgue (Nomadic Labs, France) Julian Nagele (Bank of America, USA) Russel O’Connor (Blockstream) Maria Potop-Butucaru (LIP6, France) Albert Rubio (Complutense University of Madrid, Spain) César Sanchez (IMDEA, Spain) Sun Meng (Peking University, China) Simon Thompson (IO Global, UK) Josef Widder (Informal Systems, Austria)

1 0

Journal of Functional Programming - Call For PhD Abstracts
by Graham Hutton 03 May '22

03 May '22

Dear all, 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, open access, 200+ published to date, deadline 31st May 2022. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st May 2022 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, twice per year 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 <graham.hutton(a)nottingham.ac.uk> by 31st May 2022. 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 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) 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 contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

GHC 9.4.1-alpha1 now available
by Ben Gamari 01 May '22

01 May '22

The GHC developers are happy to announce the availability of the first alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.1-alpha1 This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - ... and much more We would like to thank Microsoft Azure, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

SPLASH 2022 Final Call for Workshop Proposals
by Andreea Costea 29 Apr '22

29 Apr '22

======================================================================== SPLASH 2022 Call for Workshops The ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity December 5-10, 2022, Auckland, New Zealand https://2022.splashcon.org/track/splash-2022-Workshops ======================================================================== We encourage proposals for workshops on any topic relevant to SPLASH. If there is a topic that you feel passionate about, and want to connect with others who have similar interests, submit a workshop proposal! We more than welcome new, and unconventional ideas for workshop formats. The following suggestions are a starting point: - Conference-style workshops allow participants to present their work to other domain experts. The smaller and more focused setting of a workshop allows for Q&A sessions and facilitates discussions. Presentations of work-in-progress are welcome. - Retreats act as a platform for experts to gather to tackle issues of a predetermined research agenda. Retreats are highly interactive and goal-oriented, allowing participants to address open challenges, explore new and uncharted ideas. - Agenda-setting workshops provide a forum for experts to determine a research agenda for a sub-field. - Other common activities at workshops include poster sessions, hands-on practical work, and focus groups. Workshops that include the presentation of research papers and that implement a SIGPLAN-approved selection process may archive proceedings in the ACM Digital Library. The workshop chairs will provide advice on achieving this for those interested. Workshop applications will be considered until **May 01, 2022**, or until all slots are allocated. We will also entertain requests for workshops to be held in remote or hybrid modes. ## Workshop Proposal Submission Visit the submission link for the workshop proposal form and for more information on requirements and the evaluation process. To submit a workshop proposal, you will need to login to http://conf.research.org. ## Important Deadlines - The deadline for proposal submission for all workshops is **May 01, 2022** - The deadline for paper/abstract submission for all workshops is **September 01, 2022** - The early registration deadline for SPLASH is **TBD**. Before the SPLASH early registration deadline, all workshops must a) send out accept/reject notifications, and b) publish a draft schedule on the SPLASH website. For workshops with proceedings published in the ACM Digital Library, **TBD** is the camera-ready deadline. Therefore, you should plan to notify authors several days before this date, so that they have time for revisions. **TBD** dates will be announced as soon as the SPLASH dates they are dependent on are decided. ## Questions Please [email the workshop co-chairs](mailto:workshops@splashcon.org) with any questions. ## Submission Link https://bit.ly/splash2022w ## Organizing Committee - Mehdi Bagherzadeh, Oakland University, USA - Raffi Khatchadourian, CUNY Hunter College, USA

1 0