From ben at well-typed.com Sun May 1 23:17:01 2022 From: ben at well-typed.com (Ben Gamari) Date: Sun, 01 May 2022 19:17:01 -0400 Subject: [Haskell-cafe] GHC 9.4.1-alpha1 now available Message-ID: <87h768alnr.fsf@smart-cactus.org> 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-cases.rst [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From Graham.Hutton at nottingham.ac.uk Tue May 3 10:39:54 2022 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Tue, 3 May 2022 10:39:54 +0000 Subject: [Haskell-cafe] Journal of Functional Programming - Call For PhD Abstracts Message-ID: 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 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. From zaynah.dargaye at nomadic-labs.com Wed May 4 13:20:51 2022 From: zaynah.dargaye at nomadic-labs.com (Zaynah Dargaye) Date: Wed, 4 May 2022 15:20:51 +0200 Subject: [Haskell-cafe] Deadline extension CfP: FMBC 2022 - 4th International Workshop on Formal Methods for Blockchains Message-ID: 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 at nomadic-labs.com) * Clara Schneidewind (MPI-SP, Germany) (clara.schneidewind at 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at mailbox.org Wed May 4 16:31:35 2022 From: amindfv at mailbox.org (amindfv at mailbox.org) Date: Wed, 4 May 2022 09:31:35 -0700 Subject: [Haskell-cafe] cabal v2 global install status Message-ID: I'm very comfortable using cabal's `v2-` nix-style local builds at home and at work, but on a personal machine at home I've clung to `v1-install` because I _really_ like the ability to choose which packages are available in a simple `ghci` session. For a long time that's been impossible or painful with the `v2-` commands. What's the status these days? I'm particularly interested in how it works for packages that only exist locally without a Hackage server. (Please note that while I'm open to hearing that it's impossible or only possible with workarounds/hacks, I'm not particularly looking for a discussion on whether it's "wrong" to want this feature.) Thanks! Tom From fa-ml at ariis.it Wed May 4 16:42:53 2022 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 4 May 2022 18:42:53 +0200 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: References: Message-ID: Il 04 maggio 2022 alle 09:31 amindfv--- via Haskell-Cafe ha scritto: > I'm very comfortable using cabal's `v2-` nix-style local builds at home and at work, but on a personal machine at home I've clung to `v1-install` because I _really_ like the ability to choose which packages are available in a simple `ghci` session. > > For a long time that's been impossible or painful with the `v2-` commands. What's the status these days? I'm particularly interested in how it works for packages that only exist locally without a Hackage server. Does cabal new-install --lib do what you want? —F From amindfv at mailbox.org Wed May 4 16:56:12 2022 From: amindfv at mailbox.org (amindfv at mailbox.org) Date: Wed, 4 May 2022 09:56:12 -0700 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: References: Message-ID: On Wed, May 04, 2022 at 06:42:53PM +0200, Francesco Ariis wrote: > Il 04 maggio 2022 alle 09:31 amindfv--- via Haskell-Cafe ha scritto: > > I'm very comfortable using cabal's `v2-` nix-style local builds at home and at work, but on a personal machine at home I've clung to `v1-install` because I _really_ like the ability to choose which packages are available in a simple `ghci` session. > > > > For a long time that's been impossible or painful with the `v2-` commands. What's the status these days? I'm particularly interested in how it works for packages that only exist locally without a Hackage server. > > Does > > cabal new-install --lib > > do what you want? I don't know; in the past it hasn't, and I wanted to see what the current recommendations are before going down a long and potentially incorrect path. Cheers, Tom From lists at richarde.dev Wed May 4 17:10:24 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 4 May 2022 17:10:24 +0000 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: References: Message-ID: <010f0180900d2dc7-3355fde8-c476-4f3c-a7e6-f332cdf57774-000000@us-east-2.amazonses.com> I have found that cabal v2-install --lib has not worked for me in this use case. Instead, I use https://github.com/phadej/cabal-extras/tree/master/cabal-env, which despite being somewhat old at this point, works beautifully for the use-case Tom describes. Richard > On May 4, 2022, at 12:56 PM, amindfv--- via Haskell-Cafe wrote: > > On Wed, May 04, 2022 at 06:42:53PM +0200, Francesco Ariis wrote: >> Il 04 maggio 2022 alle 09:31 amindfv--- via Haskell-Cafe ha scritto: >>> I'm very comfortable using cabal's `v2-` nix-style local builds at home and at work, but on a personal machine at home I've clung to `v1-install` because I _really_ like the ability to choose which packages are available in a simple `ghci` session. >>> >>> For a long time that's been impossible or painful with the `v2-` commands. What's the status these days? I'm particularly interested in how it works for packages that only exist locally without a Hackage server. >> >> Does >> >> cabal new-install --lib >> >> do what you want? > > I don't know; in the past it hasn't, and I wanted to see what the current recommendations are before going down a long and potentially incorrect path. > > Cheers, > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Thu May 5 09:50:01 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Thu, 5 May 2022 05:50:01 -0400 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: <010f0180900d2dc7-3355fde8-c476-4f3c-a7e6-f332cdf57774-000000@us-east-2.amazonses.com> References: <010f0180900d2dc7-3355fde8-c476-4f3c-a7e6-f332cdf57774-000000@us-east-2.amazonses.com> Message-ID: I concur with Tom's feeling and the fact that v2-install --lib has not always worked well for me. I kept around this error message from one of my sessions about 1/2y ago: Properties.hs:2:1: error: Ambiguous module name ‘Language.Copilot’: it was found in multiple packages: copilot-3.5 copilot-3.5 I spent hours and never figured out 1) what was going on or 2) how to select which copilot version I meant... :S The v1-style and, in particular, v1-sandbox, v1-install, and v1-exec, were great and, when combined, afforded the flexibility you were mentioning. The fact that they executed in a local environment, leaving everything else on the machine unaffected, and *with all packages in the sandbox enabled* in ghci/ghc by default, was intuitive and pleasant to work with. This made my job as a dev and maintainer so much easier. I've routinely worked with very large packages (some take 1h or more to compile). Being able to completely remove packages pertaining to one project (rm .cabal-sandbox) leaving everything else unaffected --just by virtue of the fact that that's where things were stored-- was an absolute game changer. Being able to run ghc/ghci on a package compiled with specific flags or changes, and knowing I was picking the right version just because of the location i was running ghci in, was incredibly simple to work with. It made installation of Haskell packages for newbies easier too: create a sandbox. mess around in it, and if you want to start over, just erase .cabal-sandbox. Done! All your other projects remain unaffected. There's no need to use advanced cabal commands or learn about how cabal chooses to store things in $HOME/.cabal. I know it may sound like a bit of a detour from your original request, but I think it isn't. If we had this back, we could have steps close to the old: cabal v1-sandbox init cabal v1-install cabal v1-exec -- ghci -hide-package which would give you the flexibility you were asking for. (sandboxes also had `v1-sandbox add-source` so you could let the sandbox know where to pick packages in your local drive from.) Cabal v2 has some --store argument to keep things local. It doesn't always work as expected (especially when installing tools), but I think it's because it has not been used as much. This workflow (installing packages in a store in the project directory) should be not just supported, but *encouraged*. Keeping all changes local *should be the default*. Experts, and those who want to optimize installation times, avoid re-compilation, those who know how to navigate $HOME/.cabal if need be, etc., can then choose to share that installation directory across projects and use $HOME/.cabal instead (or whatever else they want). But that's a conscious choice made by an expert who understands the choice. If we keep things local with --store, all we'd need is a way to run (v2-exec) ghc/ghci/whatever with all packages in the current environment available/enabled and you'd be very close to what you were asking for. Ivan On Wed, 4 May 2022 at 13:15, Richard Eisenberg wrote: > I have found that cabal v2-install --lib has not worked for me in this use > case. > > Instead, I use > https://github.com/phadej/cabal-extras/tree/master/cabal-env, which > despite being somewhat old at this point, works beautifully for the > use-case Tom describes. > > Richard > > On May 4, 2022, at 12:56 PM, amindfv--- via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > > On Wed, May 04, 2022 at 06:42:53PM +0200, Francesco Ariis wrote: > > Il 04 maggio 2022 alle 09:31 amindfv--- via Haskell-Cafe ha scritto: > > I'm very comfortable using cabal's `v2-` nix-style local builds at home > and at work, but on a personal machine at home I've clung to `v1-install` > because I _really_ like the ability to choose which packages are available > in a simple `ghci` session. > > For a long time that's been impossible or painful with the `v2-` commands. > What's the status these days? I'm particularly interested in how it works > for packages that only exist locally without a Hackage server. > > > Does > > cabal new-install --lib > > do what you want? > > > I don't know; in the past it hasn't, and I wanted to see what the current > recommendations are before going down a long and potentially incorrect path. > > Cheers, > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From power.walross at gmail.com Thu May 5 10:28:37 2022 From: power.walross at gmail.com (Fendor) Date: Thu, 5 May 2022 12:28:37 +0200 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: References: <010f0180900d2dc7-3355fde8-c476-4f3c-a7e6-f332cdf57774-000000@us-east-2.amazonses.com> Message-ID: <7f8f87be-252f-d6e4-ff3f-bb1443a4beb0@gmail.com> Hi! Ivan Perez wrote: > It made installation of Haskell packages for newbies easier too: create a sandbox. mess around in it, and if you want to start over, just erase .cabal-sandbox. Done! Just chiming saying that I dont agree with this. I don't know a single person from my personal life who managed to use the sandbox successfully. Quite contrary, personally, I used to be a flaming stack advocate because I was never able to use cabal for anything. From my point of view, cabal's sandbox was a weird mess that was hard to understand. Also, stateful mutations seem much more complicated and error-prone to me. Ivan Perez wrote: > the fact that v2-install --lib has not always worked well for me. I agree that `v2-install -lib` is a terrible interface, but cabal-env shows how we can implement the desired functionality quite beautifully, avoiding as much as stateful changes as possible. Ivan Perez wrote: > This workflow (installing packages in a store in the project directory) should be not just supported, but /encouraged/. Keeping all changes local /should be the default/. I don't think this should be the default, in my opinion optimising the installation times, etc... is, especially for newcomers, what we usually want. You yourself said that you use this on very large projects, so, isn't it more reasonable to make experts jump through the extra hoop, e.g. by using cabal-env, to get the workflow you want? Best regards, Fendor -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at mailbox.org Thu May 5 19:02:04 2022 From: amindfv at mailbox.org (amindfv at mailbox.org) Date: Thu, 5 May 2022 12:02:04 -0700 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: References: <010f0180900d2dc7-3355fde8-c476-4f3c-a7e6-f332cdf57774-000000@us-east-2.amazonses.com> Message-ID: On Thu, May 05, 2022 at 05:50:01AM -0400, Ivan Perez wrote: > This workflow (installing packages in > a store in the project directory) should be not just supported, but > *encouraged*. Keeping all changes local *should be the default*. Experts, > and those who want to optimize installation times, avoid re-compilation, > those who know how to navigate $HOME/.cabal if need be, etc., can then > choose to share that installation directory across projects and use > $HOME/.cabal instead (or whatever else they want). But that's a conscious > choice made by an expert who understands the choice. I'm actually coming from a bit of the opposite perspective. :) I'm pretty happy, overall, with `cabal new-repl`, `cabal new-build`, etc. What I miss is the ability to have global installs. More specifically, I want to *pay all my costs at install time*. I'm okay with futzing with package dependencies, etc. (e.g. resolving conflicts in transitive dependencies) when installing a new package, but once I've paid that cost I want to be able to simply run `ghci` and have my curated set of packages available to me. I don't want to have to `mkdir foo ; cd foo ; cabal init ; $EDITOR cabal.project ; cabal new-repl` just to run a simple one-liner in ghci. I also like being able to write quick scripts and run them with `runghc` without creating an entire project for each and every one. Cheers, Tom From allbery.b at gmail.com Thu May 5 19:11:39 2022 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 5 May 2022 15:11:39 -0400 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: References: <010f0180900d2dc7-3355fde8-c476-4f3c-a7e6-f332cdf57774-000000@us-east-2.amazonses.com> Message-ID: Cabal has a script capability, although it's poorly documented. For one-liners, there is `cabal repl --build-depends='...'. Not ideal, perhaps, but works well enough for me. On Thu, May 5, 2022 at 3:06 PM amindfv--- via Haskell-Cafe wrote: > > On Thu, May 05, 2022 at 05:50:01AM -0400, Ivan Perez wrote: > > This workflow (installing packages in > > a store in the project directory) should be not just supported, but > > *encouraged*. Keeping all changes local *should be the default*. Experts, > > and those who want to optimize installation times, avoid re-compilation, > > those who know how to navigate $HOME/.cabal if need be, etc., can then > > choose to share that installation directory across projects and use > > $HOME/.cabal instead (or whatever else they want). But that's a conscious > > choice made by an expert who understands the choice. > > I'm actually coming from a bit of the opposite perspective. :) > > I'm pretty happy, overall, with `cabal new-repl`, `cabal new-build`, etc. What I miss is the ability to have global installs. More specifically, I want to *pay all my costs at install time*. I'm okay with futzing with package dependencies, etc. (e.g. resolving conflicts in transitive dependencies) when installing a new package, but once I've paid that cost I want to be able to simply run `ghci` and have my curated set of packages available to me. I don't want to have to `mkdir foo ; cd foo ; cabal init ; $EDITOR cabal.project ; cabal new-repl` just to run a simple one-liner in ghci. I also like being able to write quick scripts and run them with `runghc` without creating an entire project for each and every one. > > Cheers, > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com From johannes.waldmann at htwk-leipzig.de Fri May 6 07:19:00 2022 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Fri, 6 May 2022 09:19:00 +0200 Subject: [Haskell-cafe] data/newtype examples Message-ID: <1415df4d-d109-ebab-0a76-32ec866748f4@htwk-leipzig.de> 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. From lists at richarde.dev Fri May 6 13:46:06 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Fri, 6 May 2022 13:46:06 +0000 Subject: [Haskell-cafe] data/newtype examples In-Reply-To: <1415df4d-d109-ebab-0a76-32ec866748f4@htwk-leipzig.de> References: <1415df4d-d109-ebab-0a76-32ec866748f4@htwk-leipzig.de> Message-ID: <010f0180999ed9ab-0e555117-6d15-4592-bed0-11046aa1235f-000000@us-east-2.amazonses.com> Hi Johannes, Fun examples. For me, the key insight that allowed me to anticipate behaviors here is that Haskell's `case` is lazy. That is, `case undefined of _ -> ()` will evaluate to `()`. Instead, certain patterns force the scrutinee, but it's really the *patterns* that do this forcing, not the `case` itself. In light of this observation -- and knowing that newtypes are completely erased at runtime -- you can then predict the behavior of these examples. (I won't say more, so as not to spoil the fun of experimenting for others.) If you're teaching these examples, you may also want to consider `data S = S !Bool`, whose behavior in these is different from both D and N. Richard > On May 6, 2022, at 3:19 AM, Johannes Waldmann wrote: > > 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. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From pareto.optimal at mailfence.com Fri May 6 19:34:06 2022 From: pareto.optimal at mailfence.com (pareto optimal) Date: Fri, 6 May 2022 21:34:06 +0200 (CEST) Subject: [Haskell-cafe] Was simplified subsumption worth it for industry Haskell programmers? Message-ID: <1697146634.1691463.1651865646719@ichabod.co-bxl> 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%3Ahaskell&type=commits) 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/proposals/0287-simplify-subsumption.rst) 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/proposals/0274-quick-look-impredicativity.rst). 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-quick-look-at-impredicativity/) 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! -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri May 6 19:41:01 2022 From: david.feuer at gmail.com (David Feuer) Date: Fri, 6 May 2022 15:41:01 -0400 Subject: [Haskell-cafe] Was simplified subsumption worth it for industry Haskell programmers? In-Reply-To: <1697146634.1691463.1651865646719@ichabod.co-bxl> References: <1697146634.1691463.1651865646719@ichabod.co-bxl> Message-ID: Simplified subsumption also makes linear types quite painful, since you can't just use something of type x %1-> y when you need something of type x -> y. On Fri, May 6, 2022, 3:36 PM pareto optimal via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > 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%3Ahaskell&type=commits) > 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/proposals/0287-simplify-subsumption.rst) > 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/proposals/0274-quick-look-impredicativity.rst > ). > > 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-quick-look-at-impredicativity/) > 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! > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben.astud at gmail.com Fri May 6 19:42:18 2022 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Fri, 6 May 2022 15:42:18 -0400 Subject: [Haskell-cafe] Was simplified subsumption worth it for industry Haskell programmers? In-Reply-To: <1697146634.1691463.1651865646719@ichabod.co-bxl> References: <1697146634.1691463.1651865646719@ichabod.co-bxl> Message-ID: <02e3bd20-ea1f-0457-8d90-8251e430634e@gmail.com> I have nothing to say about the topic you propose on here. But to avoid having a fractured discussion, let's us all agree to answer on that reddit thread instead of this mail thread. Otherwise some good arguments will be repeated. -- Rubén. (pgp: 1E88 3AC4 89EB FA22) On 06-05-22 15:34, pareto optimal via Haskell-Cafe wrote: > 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%3Ahaskell&type=commits) 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/proposals/0287-simplify-subsumption.rst) 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/proposals/0274-quick-look-impredicativity.rst). > > 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-quick-look-at-impredicativity/) 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! > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From raoknz at gmail.com Fri May 6 21:03:50 2022 From: raoknz at gmail.com (Richard O'Keefe) Date: Sat, 7 May 2022 09:03:50 +1200 Subject: [Haskell-cafe] Was simplified subsumption worth it for industry Haskell programmers? In-Reply-To: <02e3bd20-ea1f-0457-8d90-8251e430634e@gmail.com> References: <1697146634.1691463.1651865646719@ichabod.co-bxl> <02e3bd20-ea1f-0457-8d90-8251e430634e@gmail.com> Message-ID: This sounds interesting, but I don't have time to wade through reddit. Aut mailing list aut nihil. On Sat, 7 May 2022 at 07:48, Ruben Astudillo wrote: > I have nothing to say about the topic you propose on here. But to avoid > having a fractured discussion, let's us all agree to answer on that reddit > thread instead of this mail thread. Otherwise some good arguments will be > repeated. > > -- > Rubén. (pgp: 1E88 3AC4 89EB FA22) > > On 06-05-22 15:34, pareto optimal via Haskell-Cafe wrote: > > 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%3Ahaskell&type=commits) > 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/proposals/0287-simplify-subsumption.rst) > 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/proposals/0274-quick-look-impredicativity.rst > ). > > > > 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-quick-look-at-impredicativity/) > 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! > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jclites at mac.com Fri May 6 21:09:59 2022 From: jclites at mac.com (Jeff Clites) Date: Fri, 6 May 2022 14:09:59 -0700 Subject: [Haskell-cafe] Was simplified subsumption worth it for industry Haskell programmers? In-Reply-To: References: Message-ID: Does someone have a link to the thread handy? Jeff > On May 6, 2022, at 2:06 PM, Richard O'Keefe wrote: > >  > This sounds interesting, but I don't have time to wade through > reddit. Aut mailing list aut nihil. > >> On Sat, 7 May 2022 at 07:48, Ruben Astudillo wrote: >> I have nothing to say about the topic you propose on here. But to avoid >> having a fractured discussion, let's us all agree to answer on that reddit >> thread instead of this mail thread. Otherwise some good arguments will be >> repeated. >> >> -- >> Rubén. (pgp: 1E88 3AC4 89EB FA22) >> >> On 06-05-22 15:34, pareto optimal via Haskell-Cafe wrote: >> > 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%3Ahaskell&type=commits) 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/proposals/0287-simplify-subsumption.rst) 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/proposals/0274-quick-look-impredicativity.rst). >> > >> > 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-quick-look-at-impredicativity/) 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! >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben.astud at gmail.com Fri May 6 21:16:43 2022 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Fri, 6 May 2022 17:16:43 -0400 Subject: [Haskell-cafe] Was simplified subsumption worth it for industry Haskell programmers? In-Reply-To: References: Message-ID: On 06-05-22 17:09, Jeff Clites via Haskell-Cafe wrote: > Does someone have a link to the thread handy? -- Rubén. (pgp: 1E88 3AC4 89EB FA22) From olf at aatal-apotheke.de Fri May 6 22:02:05 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sat, 07 May 2022 00:02:05 +0200 Subject: [Haskell-cafe] data/newtype examples Message-ID: > 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 From tdecacqu at redhat.com Fri May 6 22:01:24 2022 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Fri, 06 May 2022 22:01:24 +0000 Subject: [Haskell-cafe] GHC proposal for ImplicitQualifiedImport Message-ID: <87wneyl3rf.tristanC@fedora> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From ivanperezdominguez at gmail.com Sat May 7 17:29:29 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sat, 7 May 2022 13:29:29 -0400 Subject: [Haskell-cafe] Coverage icon on hackage Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Sat May 7 18:39:45 2022 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 7 May 2022 20:39:45 +0200 Subject: [Haskell-cafe] Coverage icon on hackage In-Reply-To: References: Message-ID: Hi Ivan, Was that icon just a part of a README? If not, could you give a link? In any case, people at the #hackage Matrix/IRC channel may know about any plans to add that (#hackage is a shared room for Hackage and related topics such as ghcup, cabal, Stackage-Hackage interoperation, etc.; all are welcome). Cheers, Mikolaj On Sat, May 7, 2022 at 7:31 PM Ivan Perez wrote: > 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 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Sat May 7 18:56:40 2022 From: tikhon at jelv.is (Tikhon Jelvis) Date: Sat, 7 May 2022 11:56:40 -0700 Subject: [Haskell-cafe] Coverage icon on hackage In-Reply-To: References: Message-ID: Looks like it's built into Hackage and not just in the Readme. The bytestring package is a good example with several badges including code coverage; if you click the "Build | InstallOK" badge, you get a more detailed report. https://hackage.haskell.org/package/bytestring On Sat, May 7, 2022 at 11:46 AM Mikolaj Konarski wrote: > Hi Ivan, > > Was that icon just a part of a README? If not, could you > give a link? > > In any case, people at the #hackage Matrix/IRC channel may > know about any plans to add that (#hackage is a shared room > for Hackage and related topics such as ghcup, cabal, > Stackage-Hackage interoperation, etc.; all are welcome). > > Cheers, > Mikolaj > > On Sat, May 7, 2022 at 7:31 PM Ivan Perez > wrote: > >> 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 >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Sat May 7 19:15:06 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sat, 7 May 2022 15:15:06 -0400 Subject: [Haskell-cafe] Coverage icon on hackage In-Reply-To: References: Message-ID: Hi Mikolaj For an example, see the badges at: https://hackage.haskell.org/package/bytestring/ And the info at: https://hackage.haskell.org/package/bytestring-0.11.3.1/reports/1 As Tikhon says, the badges are not part of the README. They are inserted by hackage. Ivan On Sat, 7 May 2022 at 14:56, Tikhon Jelvis wrote: > Looks like it's built into Hackage and not just in the Readme. The > bytestring package is a good example with several badges including code > coverage; if you click the "Build | InstallOK" badge, you get a more > detailed report. > > https://hackage.haskell.org/package/bytestring > > On Sat, May 7, 2022 at 11:46 AM Mikolaj Konarski > wrote: > >> Hi Ivan, >> >> Was that icon just a part of a README? If not, could you >> give a link? >> >> In any case, people at the #hackage Matrix/IRC channel may >> know about any plans to add that (#hackage is a shared room >> for Hackage and related topics such as ghcup, cabal, >> Stackage-Hackage interoperation, etc.; all are welcome). >> >> Cheers, >> Mikolaj >> >> On Sat, May 7, 2022 at 7:31 PM Ivan Perez >> wrote: >> >>> 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 >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Sat May 7 20:37:58 2022 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Sat, 07 May 2022 20:37:58 +0000 Subject: [Haskell-cafe] [ANN] mtl-2.3 Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at glitchbra.in Sat May 7 23:28:52 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Sun, 8 May 2022 01:28:52 +0200 Subject: [Haskell-cafe] [ANN] mtl-2.3 In-Reply-To: References: Message-ID: Congratulations to the new MTL maintainers! Le 07/05/2022 à 22:37, Emily Pillmore a écrit : > 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 > |. > * 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 |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 > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Sat May 7 23:30:46 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sat, 7 May 2022 19:30:46 -0400 Subject: [Haskell-cafe] Coverage icon on hackage In-Reply-To: References: Message-ID: I've made some progress. If I'm not mistaken, Hackage is running the tests with coverage enabled [1], it's then running hpc to analyze program coverage [2], that's being included in the report [3-5]. I think it would be very useful for package maintainers and devs to be able to replicate what the hackage server does in a docker image, not just for coverage, but for everything. One of my packages is showing that the tests fail [6]; I suspect it's due to a bug in cabal [7], but the report on hackage does not help me understand what went wrong. Ivan [1] https://github.com/haskell/hackage-server/blob/b4ea1c73ba85f24985259fd1df4664747ceb0159/exes/BuildClient.hs#L641 [2] https://github.com/haskell/hackage-server/blob/b4ea1c73ba85f24985259fd1df4664747ceb0159/exes/BuildClient.hs#L613-L630 [3] https://github.com/haskell/hackage-server/blob/b4ea1c73ba85f24985259fd1df4664747ceb0159/exes/BuildClient.hs#L576 [4] https://github.com/haskell/hackage-server/blob/b4ea1c73ba85f24985259fd1df4664747ceb0159/src/Distribution/Server/Features/BuildReports/BuildReport.hs#L277-L295 [5] https://github.com/haskell/hackage-server/blob/9637bd45ba8c321bb9a938c47a15c014dc8bdd88/src/Distribution/Server/Features/BuildReports.hs#L344-L345 [6] https://hackage.haskell.org/package/copilot-core-3.9 [7] https://github.com/haskell/cabal/issues/6440 On Sat, 7 May 2022 at 15:15, Ivan Perez wrote: > Hi Mikolaj > > For an example, see the badges at: > https://hackage.haskell.org/package/bytestring/ > > And the info at: > https://hackage.haskell.org/package/bytestring-0.11.3.1/reports/1 > > As Tikhon says, the badges are not part of the README. They are inserted > by hackage. > > Ivan > > > On Sat, 7 May 2022 at 14:56, Tikhon Jelvis wrote: > >> Looks like it's built into Hackage and not just in the Readme. The >> bytestring package is a good example with several badges including code >> coverage; if you click the "Build | InstallOK" badge, you get a more >> detailed report. >> >> https://hackage.haskell.org/package/bytestring >> >> On Sat, May 7, 2022 at 11:46 AM Mikolaj Konarski >> wrote: >> >>> Hi Ivan, >>> >>> Was that icon just a part of a README? If not, could you >>> give a link? >>> >>> In any case, people at the #hackage Matrix/IRC channel may >>> know about any plans to add that (#hackage is a shared room >>> for Hackage and related topics such as ghcup, cabal, >>> Stackage-Hackage interoperation, etc.; all are welcome). >>> >>> Cheers, >>> Mikolaj >>> >>> On Sat, May 7, 2022 at 7:31 PM Ivan Perez >>> wrote: >>> >>>> 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 >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view archives go to: >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> Only members subscribed via the mailman list are allowed to post. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Mon May 9 11:07:26 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Mon, 9 May 2022 07:07:26 -0400 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: References: <010f0180900d2dc7-3355fde8-c476-4f3c-a7e6-f332cdf57774-000000@us-east-2.amazonses.com> Message-ID: Hi, I'd love to know more about that script capability, if you can spare the time to explain a bit. It can be a separate thread or via private email if that may be noise in the conversation. All the best, Ivan On Thu, 5 May 2022 at 15:11, Brandon Allbery wrote: > Cabal has a script capability, although it's poorly documented. > > For one-liners, there is `cabal repl --build-depends='...'. Not ideal, > perhaps, but works well enough for me. > > On Thu, May 5, 2022 at 3:06 PM amindfv--- via Haskell-Cafe > wrote: > > > > On Thu, May 05, 2022 at 05:50:01AM -0400, Ivan Perez wrote: > > > This workflow (installing packages in > > > a store in the project directory) should be not just supported, but > > > *encouraged*. Keeping all changes local *should be the default*. > Experts, > > > and those who want to optimize installation times, avoid > re-compilation, > > > those who know how to navigate $HOME/.cabal if need be, etc., can then > > > choose to share that installation directory across projects and use > > > $HOME/.cabal instead (or whatever else they want). But that's a > conscious > > > choice made by an expert who understands the choice. > > > > I'm actually coming from a bit of the opposite perspective. :) > > > > I'm pretty happy, overall, with `cabal new-repl`, `cabal new-build`, > etc. What I miss is the ability to have global installs. More specifically, > I want to *pay all my costs at install time*. I'm okay with futzing with > package dependencies, etc. (e.g. resolving conflicts in transitive > dependencies) when installing a new package, but once I've paid that cost I > want to be able to simply run `ghci` and have my curated set of packages > available to me. I don't want to have to `mkdir foo ; cd foo ; cabal init ; > $EDITOR cabal.project ; cabal new-repl` just to run a simple one-liner in > ghci. I also like being able to write quick scripts and run them with > `runghc` without creating an entire project for each and every one. > > > > Cheers, > > Tom > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Mon May 9 11:12:41 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Mon, 9 May 2022 07:12:41 -0400 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: References: <010f0180900d2dc7-3355fde8-c476-4f3c-a7e6-f332cdf57774-000000@us-east-2.amazonses.com> Message-ID: > What I miss is the ability to have global installs. More specifically, I want to *pay all my costs at install time*. I'm okay with futzing with package dependencies, etc. Currently, the cabal dir is "global" (for all packages from one user), but installation is somehow local (non-interference between projects, allegedly). With sandboxes, the cabal dir is local (for this exclusive project/directory, although easily customizable), but installation is global (there's just one package DB). You pay all costs of figuring out a good plan ahead of time (the package DB must be consistent), but once you are there, there's just one of each, so it was "safe" to expose them all. > I also like being able to write quick scripts and run them with `runghc` without creating an entire project for each and every one. Same. I find the possibility of running GHC/ghci with all packages enabled in a local dir extremely useful for scripting purposes, and just generally to develop. Ivan On Thu, 5 May 2022 at 15:02, amindfv at mailbox.org wrote: > On Thu, May 05, 2022 at 05:50:01AM -0400, Ivan Perez wrote: > > This workflow (installing packages in > > a store in the project directory) should be not just supported, but > > *encouraged*. Keeping all changes local *should be the default*. Experts, > > and those who want to optimize installation times, avoid re-compilation, > > those who know how to navigate $HOME/.cabal if need be, etc., can then > > choose to share that installation directory across projects and use > > $HOME/.cabal instead (or whatever else they want). But that's a conscious > > choice made by an expert who understands the choice. > > I'm actually coming from a bit of the opposite perspective. :) > > I'm pretty happy, overall, with `cabal new-repl`, `cabal new-build`, etc. > What I miss is the ability to have global installs. More specifically, I > want to *pay all my costs at install time*. I'm okay with futzing with > package dependencies, etc. (e.g. resolving conflicts in transitive > dependencies) when installing a new package, but once I've paid that cost I > want to be able to simply run `ghci` and have my curated set of packages > available to me. I don't want to have to `mkdir foo ; cd foo ; cabal init ; > $EDITOR cabal.project ; cabal new-repl` just to run a simple one-liner in > ghci. I also like being able to write quick scripts and run them with > `runghc` without creating an entire project for each and every one. > > Cheers, > Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.cardwell at extrema.is Mon May 9 11:25:53 2022 From: travis.cardwell at extrema.is (Travis Cardwell) Date: Mon, 9 May 2022 20:25:53 +0900 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: References: <010f0180900d2dc7-3355fde8-c476-4f3c-a7e6-f332cdf57774-000000@us-east-2.amazonses.com> Message-ID: Hi Ivan, Here is some information about Cabal's script functionality: https://cabal.readthedocs.io/en/3.4/cabal-commands.html#cabal-v2-run Cheers, Travis On Mon, May 9, 2022 at 8:09 PM Ivan Perez wrote: > > Hi, > > I'd love to know more about that script capability, if you can spare the time to explain a bit. > > It can be a separate thread or via private email if that may be noise in the conversation. > > All the best, > > Ivan > > On Thu, 5 May 2022 at 15:11, Brandon Allbery wrote: >> >> Cabal has a script capability, although it's poorly documented. >> >> For one-liners, there is `cabal repl --build-depends='...'. Not ideal, >> perhaps, but works well enough for me. >> >> On Thu, May 5, 2022 at 3:06 PM amindfv--- via Haskell-Cafe >> wrote: >> > >> > On Thu, May 05, 2022 at 05:50:01AM -0400, Ivan Perez wrote: >> > > This workflow (installing packages in >> > > a store in the project directory) should be not just supported, but >> > > *encouraged*. Keeping all changes local *should be the default*. Experts, >> > > and those who want to optimize installation times, avoid re-compilation, >> > > those who know how to navigate $HOME/.cabal if need be, etc., can then >> > > choose to share that installation directory across projects and use >> > > $HOME/.cabal instead (or whatever else they want). But that's a conscious >> > > choice made by an expert who understands the choice. >> > >> > I'm actually coming from a bit of the opposite perspective. :) >> > >> > I'm pretty happy, overall, with `cabal new-repl`, `cabal new-build`, etc. What I miss is the ability to have global installs. More specifically, I want to *pay all my costs at install time*. I'm okay with futzing with package dependencies, etc. (e.g. resolving conflicts in transitive dependencies) when installing a new package, but once I've paid that cost I want to be able to simply run `ghci` and have my curated set of packages available to me. I don't want to have to `mkdir foo ; cd foo ; cabal init ; $EDITOR cabal.project ; cabal new-repl` just to run a simple one-liner in ghci. I also like being able to write quick scripts and run them with `runghc` without creating an entire project for each and every one. >> > >> > Cheers, >> > Tom >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> >> >> >> -- >> brandon s allbery kf8nh >> allbery.b at gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ivanperezdominguez at gmail.com Mon May 9 11:40:43 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Mon, 9 May 2022 07:40:43 -0400 Subject: [Haskell-cafe] cabal v2 global install status In-Reply-To: <7f8f87be-252f-d6e4-ff3f-bb1443a4beb0@gmail.com> References: <010f0180900d2dc7-3355fde8-c476-4f3c-a7e6-f332cdf57774-000000@us-east-2.amazonses.com> <7f8f87be-252f-d6e4-ff3f-bb1443a4beb0@gmail.com> Message-ID: On Thu, 5 May 2022 at 06:30, Fendor wrote: > Hi! > Ivan Perez wrote: > [...] > > I don't know a single person from my personal life who managed to use the > sandbox successfully. > Then nice to meet you! I have been using sandboxes successfully since before they were in cabal (there was a package that implemented this feature before). It's saved me countless hours of development time. I still use older versions of cabal specifically for this feature. > Quite contrary, personally, I used to be a flaming stack advocate because > I was never able to use cabal for anything. > I'm not going to go into details here so the thread is not derailed. We can take that offline. I will just say that I never found the features in stack a good approach from a development or maintainer point of view, and stack is banned from any project I have any say in. The only package I ever found difficult to install without stack was Hakyll (IIRC), and it was easier to just use something else. I have yet to find something I can install with stack with a one liner that I cannot install with apt-get/cabal in an equally simple way. > From my point of view, cabal's sandbox was a weird mess that was hard to > understand. Also, stateful mutations seem much more complicated and > error-prone to me. > I imagine you may not care at this point, but I'd be happy to hear more via private message. For me, cabal sandboxes were pretty simple to use. > > Ivan Perez wrote: > > the fact that v2-install --lib has not always worked well for me. > > I agree that `v2-install -lib` is a terrible interface, but cabal-env > shows how we can implement the desired functionality quite beautifully, > avoiding as much as stateful changes as possible. > > Ivan Perez wrote: > > This workflow (installing packages in a store in the project directory) > should be not just supported, but *encouraged*. Keeping all changes local *should > be the default*. > > I don't think this should be the default, in my opinion optimising the > installation times, etc... is, especially for newcomers, what we usually > want. > You yourself said that you use this on very large projects, so, isn't it > more reasonable to make experts jump through the extra hoop, e.g. by using > cabal-env, to get the workflow you want? > I absolutely disagree. Users want, first and foremost, that it works **well**. There are too many instances in which 1) I package won't install without errors and 2) a package won't UPGRADE without errors. This is true for all languages. I've lost count of the amount of times I've found myself having to reinstall all JS or Ruby packages on my machine because I didn't know what was wrong and the original instructions no longer worked for an upgrade. Having a shared DB is great when things go well, but it ABSOLUTE sucks when they don't. Keeping the package DB local contains the damage when things go wrong. A newcomer, and often-times an experienced user, won't know how to fix issues (with cabal commands or just by going into the directory). I don't know if it's still the case but, IIRC, up until not long ago, it was not possible to erase one particular package/project db from the new cabal's shared dir. That means it's an ever-growing directory and, once a user screws things up bad installing a project, they can't undo that mistake. There was no Ctrl+Z. But there's almost always a simple and easy fix for all problems cabal: rm -rf $HOME/.cabal (or rm -rf .cabal-sandbox). If your packages are local (sandboxed), the complexity of re-installing is linear to the packages in that project. If your cabal dir is shared, the complexity of re-installing is linear to the packages in ALL projects. We are lowering the best-case installation cost at the expense of increasing the worst-time installation cost (and losing more fine-grained control). Packages will break. Cabal will break. Users don't know these tools well because they are complex and change often. Let's first get things right, then make them stable, then make them fast. Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshchia at gmail.com Mon May 9 17:18:32 2022 From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=) Date: Tue, 10 May 2022 01:18:32 +0800 Subject: [Haskell-cafe] [direct-sqlite] Package takeover Message-ID: Hi all, I tried to contact the author of https://hackage.haskell.org/package/direct-sqlite via github issues and direct email 27 days ago about taking over the package but have not received a response. I would like to take over as maintainer for the package and would also welcome co-maintainers. Josh Chia -------------- next part -------------- An HTML attachment was scrubbed... URL: From W.S.Swierstra at uu.nl Tue May 10 07:13:53 2022 From: W.S.Swierstra at uu.nl (Swierstra, W.S. (Wouter)) Date: Tue, 10 May 2022 07:13:53 +0000 Subject: [Haskell-cafe] Full professorships at Utrecht University Message-ID: Utrecht University is currently recruiting four full professors in Computing Science. The exact research areas are not fixed -- but I'd love to see applications from the functional programming community: https://www.uu.nl/en/organisation/working-at-utrecht-university/jobs/4-full-professors-in-information-and-computing-sciences-08-10-fte # Job description The Department of Information and Computing Sciences (ICS) is nationally and internationally renowned for its fundamental and applied research in computer science and information science. In our constantly changing (digital) society, we are continually looking for new, realistic ways to push the boundaries of both science and societal application. We contribute to innovative information technologies through the development and application of new concepts, theories, algorithms, and software methods. With our expertise, we nourish a wide range of interdisciplinary and societal collaboration initiatives. The Department has grown significantly in the past years. Due to this growth and the upcoming retirement of some of our professors we envisage having appointed eight new full professors by the end of 2024 in the following fields of expertise: software systems (preferably in software production, and software and information security), artificial intelligence and data science (preferably in machine learning, responsible AI, and natural Language processing) and interaction (preferably in data-driven interaction). We are now actively searching to fill four positions. Since we aim to continue to increase the participation of women in Information and Computing Sciences (both students and staff), we wish to appoint at least two female full professors. Additionally, we have one position open that is not tied to any specific area, exclusively reserved for female candidates, a Westerdijk chair*. In Software Systems, we have research groups on Software Technology, Software Technology for Teaching and Learning, Software Production, and Business Process Management and Analytics. We lead the research masters on Computing Science and Business Informatics, and co-lead the bachelors Informatics and Information Science. We engage closely with industry and public sector partners to study the development and adoption of software technology and software production methods. In Artificial Intelligence & Data Science, we have research groups on Intelligent Systems, Data Intensive Systems, Data Mining, and Natural Language Processing. We lead the multidisciplinary research master in Artificial Intelligence and Data Science, and co-lead the Applied Data Science master and Artificial Intelligence bachelor. We closely collaborate with the public sector and companies, for example in our National Police Lab AI and AI & Mobility Lab. We also work closely with other disciplines, for example in the university's Human Centered AI and Applied Data Science focus areas. In Interaction Technology, we have research groups on Human Centered Computing, Game and Media Technology, Social and Affective Computing, and Visualisation and Graphics. We lead the Research Masters on Game & Media Technology and Human-Computer Interaction, and co-lead the Bachelor Information Science. Our state-of-the-art facilities include a Human-Centered Computing lab for prototyping interactive systems and conducting user studies and a Motion Capture and Virtual Reality Lab with full body motion capture equipment. We co-lead the multidisciplinary AI & Media and AI & Healthy Living labs and the Center for Game Research. As a full professor you are a committed, internationally acknowledged and leading scientist with expertise in one of the areas of Information and Computing Science. Your ambition is to lead the further development of research, the quality of education (both in teaching and curriculum development) and the achievement of societal impact in the field of information and computing sciences. You seek internal and external (interdisciplinary) collaboration and acquire funding for research, developing new research collaborations and new application areas. You are an inspiring educator with enthusiasm for teaching. Alongside you will take a leading role in your field of expertise, you also play an important role in creating a workplace that is supportive, socially safe and inclusive, further enhancing scientific integrity and working together towards open science. You have a clear view of how to achieve this as a leading staff member. The Department provides a dynamic, informal and international work environment. Our approach is characterized by a connected, open, and can-do spirit that stimulates personal initiative and curiosity. You are a team player who encourages taking ownership and create value while sharing your knowledge both internally and across the wider (global) community. If you are excited to actively participate and collaborate in shaping our developing department, we invite you to apply. It is important that when you apply, you make clear where and how you see that your expertise fits the overall research and education portfolio of the department, including the relationship with (future) external stakeholders. *A Westerdijk chair is a position especially installed to be occupied by a female professor. It is named after Johanna Westerdijk, appointed at Utrecht University in 1917 as the first female full professor in the Netherlands. # Qualifications We are looking for new colleagues to complement our team at an academic as well as a personal level, who fit well with the following qualifications: a PhD in Computer Science, Information Science or another relevant discipline; an internationally acknowledged research line with a strong publication track record on original research of high impact; an active player in international scientific communities; experience in and a personal view on how to lead a group of scientists and create and sustain a supportive, collaborative and inclusive work environment; demonstrated ability to acquire external funding for research and innovation; driven to explore and forge new collaborations in- and outside academia; enthusiasm for education and experience with student supervision, ability to teach in BSc and MSc programmes; experience in and aspiration for further development of courses and programmes. # Offer a tenured position as full professor; a full-time gross salary ranging from €5,864 to €8,539 in scale H2 at full professor level; benefits including an 8% holiday bonus and an 8.3% end-of-year bonus; a pension scheme, partially paid parental leave, and flexible employment conditions based on the Collective Labour Agreement (cao) Dutch Universities; a starting package that is negotiable and depends on what is necessary to give you a running start in the department; assistance in finding housing and, if applicable, help with finding employment for a partner and schools for children; in addition to the employment conditions laid down in the CAO for Dutch Universities, Utrecht University has a number of its own arrangements. For example, there are agreements on professional development, leave arrangements and sports. We also give you the opportunity to expand your terms of employment via the Employment Conditions Selection Model. This is how we like to encourage you to continue to grow. # About the organisation At the Faculty of Science, there are 6 departments to make a fundamental connection with: Biology, Chemistry, Information and Computing Sciences, Mathematics, Pharmaceutical Sciences, and Physics. Each of these is made up of distinct institutes that work together to focus on answering some of humanity’s most pressing problems. More fundamental still are the individual research groups – the building blocks of our ambitious scientific projects. Utrecht University is a friendly and ambitious university at the heart of an ancient city. We love to welcome new scientists to our city – a thriving cultural hub that is consistently rated as one of the world’s happiest cities. We are renowned for our innovative interdisciplinary research and our emphasis on inspirational research and excellent education. We are equally well-known for our informal atmosphere and the can-do mentality of our people. This lively and inspiring academic environment attracts professors, researchers and PhD candidates from all over the globe, making both the University and the Faculty of Science a vibrant international and wonderfully diverse community. # Additional information If you have specific questions regarding the positions or the department, please email them to Professor Johan Jeuring (Head of Department) or Professor Judith Masthoff (Director of Research) at j.t.jeuring at uu.nl/ j.f.m.masthoff at uu.nl. If you are interested in reading more about the development of our department, we can provide you with a copy of our summarized organizational development plan. You can send your request to a.bonsma at uu.nl. Do you have a question about the application procedure? Please send an email to science.recruitment at uu.nl # Apply https://ssl1.peoplexs.com/Peoplexs22/CandidatesPortalNoLogin/ApplicationForm.cfm?PortalID=4124&VacatureID=1188880 Everyone deserves to feel at home at our university. We welcome employees with a wide variety of backgrounds and perspectives. Please enclose: your motivation letter; your full academic curriculum vitae, including a list of publications; your vision on research and education. If this specific opportunity isn’t for you, but you know others who may be interested, please forward this vacancy to them. The application deadline is 1 July 2022. From lysxia at gmail.com Tue May 10 15:33:36 2022 From: lysxia at gmail.com (Li-yao Xia) Date: Tue, 10 May 2022 11:33:36 -0400 Subject: [Haskell-cafe] BX 2022 - Final Call For Papers (deadline 14 May) In-Reply-To: References: Message-ID: # Tenth International Workshop on Bidirectional Transformations (BX 2022) ## Important Dates - Paper submission: 14 May, 2022 - Author notification: 28 May, 2022 - Workshop: 8 July 2022, Nantes, France Part of STAF 2022 (5-8 July): https://staf2022.univ-nantes.io/ BX 2022 homepage: http://bx-community.wikidot.com/bx2022:home ## Overview Bidirectional transformations (BX) are a mechanism for maintaining the consistency between two or more related (and heterogeneous) sources of information (e.g., relational databases, software models and code, or any other artefacts following standard or domain-specific formats). The strongest argument in favour of BX is its ability to provide a synchronization mechanism that is guaranteed to be correct by construction. BX has been attracting a wide range of research areas and communities, with prominent presence at top conferences in several different fields (namely databases, programming languages, software engineering, and graph transformation). Nowadays, the fast-growing complexity of software- or data-intensive systems has forced industry and academia to use and investigate different development techniques to manage the many different aspects of the systems. Researchers are actively investigating the use of bidirectional approaches to tackle a diverse set of challenges with various applications including model-driven software development, visualization with direct manipulation, big data, databases, domain-specific languages, serializers, and data transformation, integration and exchange. BX 2022 is a dedicated venue for BX in all relevant fields and is part of a workshop series that was created in order to promote cross-disciplinary research and awareness in the area. As such, since its beginning in 2012, the workshop has rotated between venues in different fields. Papers for BX 2022 can be submitted on EasyChair: https://www.easychair.org/conferences/?conf=bx2022 ## Topics The aim of the workshop is to bring together researchers and practitioners, established and new, interested in bx from different perspectives, including but not limited to: - bidirectional programming languages and frameworks - software development with BX - data and model synchronization - view updating - inter-model consistency analysis and repair - data/schema (or model/metamodel) co-evolution - coupled software/model transformations - inversion of transformations and data exchange mappings - domain-specific languages for BX - analysis and classification of requirements for BX - bridging the gap between formal concepts and application scenarios - analysis of efficiency of transformation algorithms and benchmarks - model-driven and model-based approaches - survey and comparison of BX technologies - case studies and tool support - applications and experiences of adopting BX in the real world ## Categories of Submissions Five categories of submissions are considered: 1. Full Research Papers (13-15 pages) - in-depth presentations of novel concepts and results - applications of bx to new domains - survey papers providing novel comparisons between existing bx technologies and approaches, case studies 2. Tool Papers (7-8 pages) - guideline papers presenting best practices for employing a specific bx approach (with a specific tool) - presentation of new tools or substantial improvements to existing ones - qualitative and/or quantitative comparisons of applying different bx approaches and tools 3. Experience Report (7-8 pages) - sharing experiences and lessons learned with bx tools/frameworks/languages - how bx is used in (research/industrial/educational) projects 4. Short Papers (5 pages) - work in progress - small focused contributions - position papers and research perspectives - critical questions and challenges for bx 5. Talk Proposals (2 pages) - proposed lectures about topics of interest for bx - existing work representing relevant contributions for bx - promising contributions that are not mature enough to be proposed as papers of the other categories ## Submission guidelines Papers should use the new CEUR-ART style, single column, available as an Overleaf page or as a zip archive: https://www.overleaf.com/read/gwhxnqcghhdt http://ceur-ws.org/Vol-XXX/CEURART.zip and must be submitted via EasyChair: https://www.easychair.org/conferences/?conf=bx2022 If your submission is not a Full Research Paper, please include the intended submission category in the Title field of EasyChair’s submission form. Tool papers, experience reports and short papers will be mapped to the short paper category in CEUR (having between 5-9 standard pages, 1 standard page = 2500 characters), whereas full research papers will be mapped to the regular paper category in CEUR (having at least 10 standard pages). The bibliography is excluded from the page limits. All papers are expected to be self-contained and well-written. Tool papers are not expected to present novel scientific results, but to document artifacts of interest and share bx experience/best practices with the community. Experience papers are expected to report on lessons learnt from applying bx approaches, languages, tools, and theories to practical application case studies. Talk proposals are encouraged to provoke interesting discussion at the workshop and will not be held to the same standard of maturity as regular papers; short papers contain focused results, positions or perspectives that can be presented in full in just a few pages, and that correspondingly contain fewer results and that therefore might not be competitive in the full paper category. We strongly encourage authors to ensure that any (variants of) examples are present in the bx example repository at the time of submission, and, for tool papers, to allow for reproducibility with minimal effort, either via a virtual machine (e.g., via Share) or a dedicated website with relevant artifacts and tool access. All papers will be peer-reviewed by at least three members of the program committee. If a submission is accepted, at least one author is expected to participate in the workshop to present it. Authors of accepted tool paper submissions are also expected to be available to demonstrate their tool at the event. ## Proceedings The workshop proceedings (in a STAF 2022 joint volume for workshops), including all accepted papers (except talk proposals), shall be submitted after the conference to CEUR-WS.org for online publication. Pre-prints of all papers will be available via the workshop website at the beginning of the conference. In case of questions, please contact the PC chairs at bx2022 at easychair.org. Best regards, Li-yao Xia, Vadim Zaytsev, Xiao He From dcsarpi at nus.edu.sg Thu May 12 03:06:14 2022 From: dcsarpi at nus.edu.sg (Arpita Dutta) Date: Thu, 12 May 2022 03:06:14 +0000 Subject: [Haskell-cafe] Call for Reviewers APLAS 2022 Artifact Evaluation Committee Message-ID: Dear all; The /20th Asian Symposium on Programming Languages and Systems/ (APLAS'22) is going to be holding its first /Artifact Evaluation Committee/ (AEC). The artifact evaluation process aims to promote, share, and catalogue the research artifacts of papers accepted to the APLAS research track. We are looking for motivated researchers at all academic stages (PhD Students, Researchers, Lecturers, & Professors) to join us on the inaugural APLAS'22 AEC. The self-nomination form is available at: https://forms.gle/rJREG9DiFQHegZmD9 To nominate other people please use the following form: https://forms.gle/KFiQYLjELMsEjGLp8 ​ As a committee member your primary responsibility will be to review artifacts submitted by authors of accepted papers and ensure that the artifact is a faithful representation of the accepted paper's results. This will involve interacting with some tooling provided by the authors, check if the results of the main paper are consistent with the claims in the paper and are also reproducible for researchers to come. APLAS will use a three-phase artifact review process: Kick-The-Tyres; Review the Artifact; and Iron-out-the-Wrinkles. Reviewing guidance for committee members will be made available once the committee has been formed. We will close nominations on: Friday 08 July 2022 (AOE) and notify the selected committee members on: Friday 15 July 2022 (AOE) We expect most of the reviewing process to be performed between 22nd August 2022 and 19th September 2022. We expect each artifact to take around eight hours to review and we will look to assign each reviewer three to four reviews. For each artifact we will assign a Lead Reviewer to lead the reviewing process. Salient information about the reviewing process can be found online: ​ https://2022.splashcon.o​rg/tr​ack/aplas-2022-aec#Reviewer-Information Come join us to improve the quality of research in our field! Thanks​ Arpita Dutta and Jan de Muijnck-Hughes APLAS'22 AEC Co-Chairs. This call was adapted from the PLDI'22 AEC Call for Nominations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Thu May 12 15:27:47 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 12 May 2022 17:27:47 +0200 Subject: [Haskell-cafe] profiling cpu usage of concurrent program Message-ID: <82ca2236c16b62215a55844088c16d5d92f31e61.camel@aatal-apotheke.de> Dear Café, I have a network application of which I would like to know which parts are responsible for the majority of CPU usage. Conventional GHC profiling does not quite work here, because 1. +RTS -p shows that the program spends most of its *time* idling, where cost centers of interest are so insignificant that the precision of %time in the .prof format make it impossible to determine the relative execution time of selected cost centers. The Wiki [1] suggests the -P option. 2. Even ThreadScope (haven't tried yet) may show me only what's expected: The work is done in worker threads. I am not so much concerned about the level of concurrency or parallelism, but which parts occupy the cpu. I ran the program with +RTS -P and sorted the output by ticks. Naturally, functions like threadDelay and liftIO come at the top. But these all stand for waiting IO actions. As first approximation, I might ignore these and consider the remainder. Is that a valid approach? Is there a profiler that measures something like CPU cycles per cost center? Should I turn to ghc-events-analyze [2]? Or perf? Execution time is not critical (as long as the queue is emptied faster than data is flowing in) but maxing out the computing resources may become critical because it mandates more expensive hardware. I've been pitching Haskell to my bosses by promising better performance (compared to Python). Appropriate profiling seems essential to keep that promise. Olaf [1] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html#compiler-options-for-profiling [2] https://hackage.haskell.org/package/ghc-events-analyze From W.S.Swierstra at uu.nl Fri May 13 12:53:54 2022 From: W.S.Swierstra at uu.nl (Swierstra, W.S. (Wouter)) Date: Fri, 13 May 2022 12:53:54 +0000 Subject: [Haskell-cafe] Final call for participation: Advanced Functional Programming Summer School in Utrecht Message-ID: # Call for Participation SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING Utrecht, the Netherlands, 04 July – 08 July 2022 http://www.afp.school **Please register before June 17th ** ## ABOUT The Advanced Functional Programming summer school has been running for more than ten years. We aim to educate aspiring Haskell programmers beyond the basic material covered by many textbooks. After running remotely for the past two years, we're thrilled to announce that this year's edition will take place on site in Utrecht. We are monitoring the pandemic closely - and will make contingency plans if we cannot meet in person; at the moment, we do not have plans for remote participation. The lectures will cover several more advanced topics regarding the theory and practice of Haskell programming, including topics such as: * lambda calculus; * monads and monad transformers; * lazy evaluation; * generalized algebraic data types; * type families and type-level programming; * concurrency and parallelism. The summer school consists of a mix of lectures, labs, and a busy social program. ## LECTURERS Utrecht staff: * Gabriele Keller * Trevor McDonell * Wouter Swierstra ## PREREQUISITES We expect students to have a basic familiarity with Haskell already. You should be able to write recursive functions over algebraic data types, such as lists and trees. There is a great deal of material readily available that covers this material. If you've already started learning Haskell and are looking to take your functional programming skills to the next level, this is the course for you. ## DATES **Registration deadline: June 17th, 2022** School: 04 July – 08 July 2022 ## COSTS 750 euro - Profession registration only 250 euro - Student registration fee 200 euro - Housing fee We will charge a registration fee of 750 euros (or 250 euros for students) to cover our expenses. If this is problematic for you for any reason at all, please email the organisers and we can try to offer you a discounted rate or a fee waiver. We have a limited number of scholarships or discounts available for students that would not be able to attend otherwise, especially for women and under-represented minorities. ## FURTHER INFORMATION Further information, including instructions on how to register, is available on our website: http://www.afp.school From ruben.astud at gmail.com Fri May 13 16:19:10 2022 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Fri, 13 May 2022 12:19:10 -0400 Subject: [Haskell-cafe] Haskellers needed @ Superrare Labs Message-ID: <7a8ca05c-b977-1fbe-2a80-0234a1ddf484@gmail.com> Hello haskell-cafe . I have been working with SuperRare Labs for more than a year and they are looking to grow the team! I know the feelings of the community about NFTs and Blockchains. Those arguments have been said (and said better!) for example on the haskell sub-reddit. Still, I think there are neat pieces of technology on our backend and we have a good work environment where we can do some neat engineering. SuperRare labs is a US based company with US level compensation, fully remote (I am Chilean and I feel in-the-loop). Technology wise we are into Haskell, GraphQL (template haskell interop), `extensible`-records, Postgresql and hs-web3[0]. If any of those technologies interest you, _please_ send a message at the forms at greenhouse[1], in particular on the backend engineer role. Also, send me a private email so we can chat, answer your questions and/or see ways to speed up the process. [0]: [1]: -- Rubén. (pgp: 1E88 3AC4 89EB FA22) From simon at joyful.com Mon May 16 22:52:25 2022 From: simon at joyful.com (Simon Michael) Date: Mon, 16 May 2022 12:52:25 -1000 Subject: [Haskell-cafe] ANN: haskell-links.org - searchable links db Message-ID: <2151D4D2-3820-4B18-AAE9-671FDA7F95B5@joyful.com> Hello Haskell friends, Recently I said this on reddit: > There's no way these very frequent reddit and chat requests for learning materials can capture all the existing resources. There are too many, and folks who know where they are get burned out reposting them. There have been many attempts to gather them, haskell.org/documentation being the most obvious, but none of them have fully succeeded. We could really do with some more systematic, scalable (crowd-sourced, lightweight) approach. Then I experimented and set up https://haskell-links.org . This is version 1, providing: - A searchable read-only view of the Haskell links collected by lambdabot, the popular #haskell IRC bot. - A redirector/link shortener/memory aid, for jumping to any of these links via their short ID. Eg: https://haskell-links.org/doc https://haskell-links.org/books https://haskell-links.org/ghc-guide - Collected links to other Haskell search tools, making this a fast way to get to anywhere in Haskelldom. After contemplation and discussion on #haskell, I believe version 2 should allow web editing and use its own database. But I wanted to share this one as it's a nice simple setup. I hope you might find useful ! Help is welcome, see README. Best, -Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Tue May 17 07:05:23 2022 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Tue, 17 May 2022 07:05:23 +0000 Subject: [Haskell-cafe] Assistant Professorships in Nottingham Message-ID: <7C836F2B-992A-4CB0-8B89-E8F82F6F5474@nottingham.ac.uk> Dear all, As part of a strategic expansion, the School of Computer Science at the University of Nottingham is seeking to make multiple new appointments at the Assistant Professor level: https://tinyurl.com/38f753d5 These positions are aimed at early career academics who recently completed or will soon complete their PhD, and have a reduced teaching responsibility for the first three years. Applications in the area of the Functional Programming (FP) lab are strongly encouraged! The FP lab is keen to receive applications from candidates with a strong publication record (e.g. papers in leading venues such as LICS, POPL, ICFP, JFP, TOPLAS, etc) and the potential to secure external funding. The group recently grew its profile in type theory with the appointment of Nicolai Kraus and Ulrik Buchholtz. To complement these appointments, we particularly welcome applications from candidates who would bring further or other areas of expertise. Further information about the FP lab is available from: https://tinyurl.com/y2ekdkqa The deadline for applications is Tuesday 24th May 2022. -- Graham Hutton and Thorsten Altenkirch 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. From benoit.montagu at inria.fr Tue May 17 14:05:33 2022 From: benoit.montagu at inria.fr (Benoit Montagu) Date: Tue, 17 May 2022 16:05:33 +0200 Subject: [Haskell-cafe] ML Family Workshop 2022: Final Call for Presentations Message-ID: <65e357e9-b67e-93d9-c7be-b715c6726a74@inria.fr> We are happy to invite submissions to the ML Family Workshop 2022, to be held during the ICFP conference week on Thursday, September 15th. The ML family workshop warmly welcomes submission touching on the programming languages traditionally seen as part of the “ML family” (Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml, etc.). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to exchange experience of further developing ML ideas. The workshop does not have proceedings, making it the perfect venue to run some ideas with the community or present some work in progress within a friendly environment. The PC has a broad expertise and submissions are 3 pages long: when in doubt, just submit! Currently, the workshop is scheduled to be an in-person event. We will give to the authors of accepted abstracts the opportunity to give their talks remotely if necessary, in case they could not travel. See the detailed CFP online on the ICFP website: https://icfp22.sigplan.org/home/mlfamilyworkshop-2022#Call-for-Presentations Important dates ---------------     Friday 3th June (any time zone): Abstract submission deadline     Tuesday 28th June: Author notification     Thursday 15th August: ML Family Workshop Program committee -----------------     Kenichi Asai (Ochanomizu University)     Arthur Azevedo de Amorim (Boston University)     Dariusz Biernacki (University of Wrocław)     Stephen Dolan (Jane Street)     Kavon Farvardin (Apple)     Armaël Guéneau (Inria)     Sam Lindley (University of Edinburgh)     Guido Martínez (CIFASIS-CONICET)     Keiko Nakata (SAP Innovation Center Potsdam)     Lionel Parreaux (Hong Kong University of Science and Technology)     Matija Pretnar (University of Ljubljana)     Mike Rainey (Carnegie Mellon University)     Yann Régis-Gianas (Nomadic Labs)     KC Sivaramakrishnan (IIT Madras and Tarides)     Ningning Xie (University of Cambridge)     Chair: Benoît Montagu (Inria) Submission details ------------------ See the online CFP for the details on the expected submission format. Submissions must be uploaded to the workshop submission website https://ml2022.hotcrp.com/ before the submission deadline. From markus.l2ll at gmail.com Wed May 18 07:46:46 2022 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Wed, 18 May 2022 10:46:46 +0300 Subject: [Haskell-cafe] Package takeover request for rapid In-Reply-To: References: <858d6ff1-ee5c-41e2-e695-92334e03dc80@ifi.lmu.de> Message-ID: Hi all, it's now been two weeks, would it be ok to continue? I've created an organization here https://github.com/haskell-rapid/ so it would be easy to add more maintainers, and added an issue tracker as well (forks don't have one by default). I did contact github and cited this thread and the takeover process but since I have no legal relation to the deceased then they didn't want to move the repository. But I actually think it's fine the way it is. I also set master branch to where the upstream master is and moved the dependency bounds to the dev branch for the time being. On Wed, Apr 20, 2022, 13:12 Brandon Allbery wrote: > Has anyone asked Github forhelp? I'd imagine they have some way to > migrate repositories in this case by now. > > On Wed, Apr 20, 2022 at 8:04 AM Andreas Abel > wrote: > > > > > By default I'd maintain it here: https://github.com/eyeinsky/rapid. > > > > At the least, this would need an issue tracker... > > > > > Are there any other options (a github organization perhaps)? > > > > Personally, I prefer maintaining third-party packages on github > > organizations (see e.g. https://github.com/blaze-builder ). It is > > easier to co-maintain and to install new maintainers. > > > > Github also offers transfer of repositories, but this has to be done by > > the owner. Unfortunately, since Ertugrul passed away, it might be > > difficult to transfer the whole repository (with issues etc.). > > > > Cheers, > > Andreas > > > > On 2022-04-19 16:01, Markus Läll wrote: > > > Hi Andreas, > > > > > > Yup, let's wait the two weeks. > > > > > > By default I'd maintain it here: https://github.com/eyeinsky/rapid. > > > Are there any other options (a github organization perhaps)? > > > > > > On Tue, Apr 19, 2022 at 3:53 PM Andreas Abel > wrote: > > >> > > >> Hello Markus, > > >> > > >> thanks for the initiative! > > >> > > >> The takeover is probably fine. It might be contested by other > > >> applicants, but there aren't really any stakeholders on the source > code > > >> of rapid. As far as github tells me, the code was single-handedly > > >> written by the now passed-away author. > > >> > > >> Maybe we should wait the suggested 2 weeks for any contestants before > we > > >> finalize the takeover. > > >> > > >> You will need help to get added to > > >> > > >> https://hackage.haskell.org/package/rapid/maintainers/ > > >> > > >> by one of the hackage admins (CCed). > > >> > > >> You would likely have to move the code to another github account, > would you? > > >> > > >> Cheers, > > >> Andreas (in my role as a hackage trustee) > > >> > > >> P.S.: I bumped the base-bound of rapid on hackage to ease building > with > > >> newer GHCs. > > >> > > >> On 2022-04-19 14:15, Markus Läll wrote: > > >>> Hi > > >>> > > >>> I would like to take over https://hackage.haskell.org/package/rapid > > >>> > > >>> The author of the package Ertugrul Söylemez, once an active member of > > >>> the community perhaps best known for netwire, passed away in 2018. > [1] > > >>> The work required for the package thus far, and for which I've kept a > > >>> fork for, is to bump version bounds as GHCs progress. > > >>> > > >>> [1] > https://github.com/esoeylemez/rapid/pull/2#issuecomment-427065739 > > >>> > > > > > > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Thu May 19 19:52:53 2022 From: gershomb at gmail.com (Gershom B) Date: Thu, 19 May 2022 15:52:53 -0400 Subject: [Haskell-cafe] Package takeover request for rapid In-Reply-To: References: <858d6ff1-ee5c-41e2-e695-92334e03dc80@ifi.lmu.de> Message-ID: Ok. You've now been added as a hackage maintainer for rapid. Cheers, Gershom On Wed, May 18, 2022 at 3:47 AM Markus Läll wrote: > > Hi all, > > it's now been two weeks, would it be ok to continue? > > I've created an organization here https://github.com/haskell-rapid/ so > it would be easy to add more maintainers, and added an issue tracker as > well (forks don't have one by default). > > I did contact github and cited this thread and the takeover process > but since I have no legal relation to the deceased then they didn't > want to move the repository. But I actually think it's fine the way it is. > > I also set master branch to where the upstream master is and moved the > dependency bounds to the dev branch for the time being. > > > On Wed, Apr 20, 2022, 13:12 Brandon Allbery wrote: >> >> Has anyone asked Github forhelp? I'd imagine they have some way to >> migrate repositories in this case by now. >> >> On Wed, Apr 20, 2022 at 8:04 AM Andreas Abel wrote: >> > >> > > By default I'd maintain it here: https://github.com/eyeinsky/rapid. >> > >> > At the least, this would need an issue tracker... >> > >> > > Are there any other options (a github organization perhaps)? >> > >> > Personally, I prefer maintaining third-party packages on github >> > organizations (see e.g. https://github.com/blaze-builder ). It is >> > easier to co-maintain and to install new maintainers. >> > >> > Github also offers transfer of repositories, but this has to be done by >> > the owner. Unfortunately, since Ertugrul passed away, it might be >> > difficult to transfer the whole repository (with issues etc.). >> > >> > Cheers, >> > Andreas >> > >> > On 2022-04-19 16:01, Markus Läll wrote: >> > > Hi Andreas, >> > > >> > > Yup, let's wait the two weeks. >> > > >> > > By default I'd maintain it here: https://github.com/eyeinsky/rapid. >> > > Are there any other options (a github organization perhaps)? >> > > >> > > On Tue, Apr 19, 2022 at 3:53 PM Andreas Abel wrote: >> > >> >> > >> Hello Markus, >> > >> >> > >> thanks for the initiative! >> > >> >> > >> The takeover is probably fine. It might be contested by other >> > >> applicants, but there aren't really any stakeholders on the source code >> > >> of rapid. As far as github tells me, the code was single-handedly >> > >> written by the now passed-away author. >> > >> >> > >> Maybe we should wait the suggested 2 weeks for any contestants before we >> > >> finalize the takeover. >> > >> >> > >> You will need help to get added to >> > >> >> > >> https://hackage.haskell.org/package/rapid/maintainers/ >> > >> >> > >> by one of the hackage admins (CCed). >> > >> >> > >> You would likely have to move the code to another github account, would you? >> > >> >> > >> Cheers, >> > >> Andreas (in my role as a hackage trustee) >> > >> >> > >> P.S.: I bumped the base-bound of rapid on hackage to ease building with >> > >> newer GHCs. >> > >> >> > >> On 2022-04-19 14:15, Markus Läll wrote: >> > >>> Hi >> > >>> >> > >>> I would like to take over https://hackage.haskell.org/package/rapid >> > >>> >> > >>> The author of the package Ertugrul Söylemez, once an active member of >> > >>> the community perhaps best known for netwire, passed away in 2018. [1] >> > >>> The work required for the package thus far, and for which I've kept a >> > >>> fork for, is to bump version bounds as GHCs progress. >> > >>> >> > >>> [1] https://github.com/esoeylemez/rapid/pull/2#issuecomment-427065739 >> > >>> >> > > >> > > >> > > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> >> -- >> brandon s allbery kf8nh >> allbery.b at gmail.com From plredmond at ucsc.edu Thu May 19 20:15:23 2022 From: plredmond at ucsc.edu (Patrick L Redmond) Date: Thu, 19 May 2022 13:15:23 -0700 Subject: [Haskell-cafe] [template haskell] Sharing names between constructors and types Message-ID: Hello Haskell Cafe, When can a type not share the name of a constructor? Defining a type and a constructor with the same name, manually, as follows, seems to be acceptable: data F = F | T data T However, if the type is generated by Template Haskell, it is no longer acceptable, as follows: voidType :: Name -> DecsQ voidType n = do d <- dataD (return []) n [] Nothing [] [] return [d] In a separate module: data F = F | T $(voidType 'T) This will result in a "Multiple declarations of ‘T’" error. Is this expected? Thank you, Patrick From plredmond at ucsc.edu Thu May 19 22:11:12 2022 From: plredmond at ucsc.edu (Patrick L Redmond) Date: Thu, 19 May 2022 15:11:12 -0700 Subject: [Haskell-cafe] [template haskell] Sharing names between constructors and types In-Reply-To: References: Message-ID: I worked around the issue. Apologies for the noise. I'm still learning, but I think the reason for this error is: * The name passed to `voidType` contains module information, and possibly other information. * By reusing the name in the output of `voidType` (as a type) we are incorrectly overriding the existing name (of a constructor), even though they're ostensibly different namespaces. A workaround is to perform `mkName $ nameBase n` inside `voidType`. On Thu, May 19, 2022 at 1:15 PM Patrick L Redmond wrote: > > Hello Haskell Cafe, > > When can a type not share the name of a constructor? > > Defining a type and a constructor with the same name, manually, as > follows, seems to be acceptable: > > data F = F | T > data T > > However, if the type is generated by Template Haskell, it is no longer > acceptable, as follows: > > voidType :: Name -> DecsQ > voidType n = do > d <- dataD (return []) n [] Nothing [] [] > return [d] > > In a separate module: > > data F = F | T > $(voidType 'T) > > This will result in a "Multiple declarations of ‘T’" error. Is this expected? > > Thank you, > Patrick From x at tomsmeding.com Fri May 20 06:11:15 2022 From: x at tomsmeding.com (Tom Smeding) Date: Fri, 20 May 2022 06:11:15 +0000 Subject: [Haskell-cafe] [template haskell] Sharing names between constructors and types In-Reply-To: References: Message-ID: <212f3a35-6628-016b-2c87-801f7b930edc@tomsmeding.com> A `NameG`, the constructor of `Name` that your name probably has, has a `NameSpace` field that indicates in what namespace the name lives. See the documentation: https://hackage.haskell.org/package/template-haskell-2.18.0.0/docs/Language-Haskell-TH-Syntax.html#t:NameSpace If you have the name of a type (with namespace `TcClsName`) and want to use it as a data constructor (which normally has namespace `DataName`), you probably need to change the namespace. - Tom On 20/05/2022 00:11, Patrick L Redmond via Haskell-Cafe wrote: > I worked around the issue. Apologies for the noise. > > I'm still learning, but I think the reason for this error is: > > * The name passed to `voidType` contains module information, and > possibly other information. > * By reusing the name in the output of `voidType` (as a type) we are > incorrectly overriding the existing name (of a constructor), even > though they're ostensibly different namespaces. > > A workaround is to perform `mkName $ nameBase n` inside `voidType`. > > > On Thu, May 19, 2022 at 1:15 PM Patrick L Redmond wrote: >> >> Hello Haskell Cafe, >> >> When can a type not share the name of a constructor? >> >> Defining a type and a constructor with the same name, manually, as >> follows, seems to be acceptable: >> >> data F = F | T >> data T >> >> However, if the type is generated by Template Haskell, it is no longer >> acceptable, as follows: >> >> voidType :: Name -> DecsQ >> voidType n = do >> d <- dataD (return []) n [] Nothing [] [] >> return [d] >> >> In a separate module: >> >> data F = F | T >> $(voidType 'T) >> >> This will result in a "Multiple declarations of ‘T’" error. Is this expected? >> >> Thank you, >> Patrick > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From meng.wang at bristol.ac.uk Fri May 20 08:42:43 2022 From: meng.wang at bristol.ac.uk (Meng Wang) Date: Fri, 20 May 2022 08:42:43 +0000 Subject: [Haskell-cafe] Research fellow position at University of Bristol Message-ID: Dear Haskellers, The programming languages group at Bristol is recruiting a research fellow to join our dynamic research group https://bristolpl.github.io/. Our research is ranked highly internationally and there is a strong focus on Haskell. We welcome functional programmers anywhere in the world to apply! (Another similar post at the level of research associate is also available.) https://www.bristol.ac.uk/jobs/find/details/?jobId=274355&jobTitle=Research%20Fellow Meng Wang, PhD (Oxon) Senior Lecturer of Programming Languages Head of PL research group School International Director SCEEM (CS, EEE, EMath) School, University of Bristol PS. A selection of recent papers can be found below. They should give a good indication of the type of PL research conducted at Bristol: - Perera et al. (2022). Linked visualisations via Galois dependencies. POPL 2022. 10.1145/3498668 - Xie et al. (2022). Staging with Class. POPL 2022. 10.1145/3498723 - Yamaguchi et al. (2021). Synbit: Synthesizing Bidirectional Programs using Unidirectional Sketches. OOPSLA 2021. 10.1145/3485482 - Qian Z et al. (2021). Client-Server Sessions in Linear Logic. ICFP 2021. 10.1145/3473567 - Jones E & Ramsay S. (2021). Intensional Refinement Datatypes. POPL 2021. 10.1145/3445980 - Gratzer D et al. (2020). Multimodal Dependent Type Theory. LICS 2020. 10.1145/3373718.3394736 - Matsuda K & Wang M. (2020). Sparcl: A Language for Partially-Invertible Computation. ICFP 2020. 10.1145/3409000 - Zhang J et al. (2019). A Study of Bug Resolution Characteristics in Popular Programming Languages. IEEE Transactions on Software Engineering. 10.1109/TSE.2019.2961897 - Abate A et al. (2019). Automated Formal Synthesis of Provably Safe Digital Controllers for Continuous Plants. Acta Informatica, vol 57. 10.1007/s00236-019-00359-1 - Almeida et al. (2019). Machine-Checked Proofs for Cryptographic Standards: Indifferentiability of Sponge and Secure High-Assurance Implementations of SHA-3. CCS 2019. 10.1145/3319535.336321 -------------- next part -------------- An HTML attachment was scrubbed... URL: From 414owen at gmail.com Sat May 21 14:43:51 2022 From: 414owen at gmail.com (Owen Shepherd) Date: Sat, 21 May 2022 15:43:51 +0100 Subject: [Haskell-cafe] [ANN]: simfin 1.0.0 - Simple financial data API wrapper Message-ID: Hello everyone, I've released a small library that wraps the SimFin (https://simfin.com/) API. SimFin collates and organises financial data, and provides a nice little web API which provides historical prices, ratios, financial statement extracts, etc. Hackage link: https://hackage.haskell.org/package/simfin-1.0.0 Enjoy, - Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at joyful.com Sat May 21 20:39:55 2022 From: simon at joyful.com (Simon Michael) Date: Sat, 21 May 2022 10:39:55 -1000 Subject: [Haskell-cafe] haskell-links.org update In-Reply-To: <2151D4D2-3820-4B18-AAE9-671FDA7F95B5@joyful.com> References: <2151D4D2-3820-4B18-AAE9-671FDA7F95B5@joyful.com> Message-ID: <847B6A16-5B4A-4CF9-94E5-4FC672C85ED2@joyful.com> FYI, https://haskell-links.org no longer requires javascript to search links. There have also been UI tweaks and back end changes (see https://github.com/simonmichael/haskell-links#timeline ) and some discussion at https://discourse.haskell.org/t/ann-haskell-links-org-searchable-links-database . Best, -Simon > On May 16, 2022, at 12:52, Simon Michael wrote: > > Hello Haskell friends, > > Recently I said this on reddit: > > > There's no way these very frequent reddit and chat requests for learning materials can capture all the existing resources. There are too many, and folks who know where they are get burned out reposting them. There have been many attempts to gather them, haskell.org/documentation being the most obvious, but none of them have fully succeeded. We could really do with some more systematic, scalable (crowd-sourced, lightweight) approach. > > Then I experimented and set up https://haskell-links.org . This is version 1, providing: > > - A searchable read-only view of the Haskell links collected by lambdabot, the popular #haskell IRC bot. > > - A redirector/link shortener/memory aid, for jumping to any of these links via their short ID. Eg: > > https://haskell-links.org/doc > https://haskell-links.org/books > https://haskell-links.org/ghc-guide > > - Collected links to other Haskell search tools, making this a fast way to get to anywhere in Haskelldom. > > After contemplation and discussion on #haskell, I believe version 2 should allow web editing and use its own database. But I wanted to share this one as it's a nice simple setup. I hope you might find useful ! Help is welcome, see README. > > Best, > -Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat May 21 20:51:01 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 21 May 2022 22:51:01 +0200 (CEST) Subject: [Haskell-cafe] haskell-links.org update In-Reply-To: <847B6A16-5B4A-4CF9-94E5-4FC672C85ED2@joyful.com> References: <2151D4D2-3820-4B18-AAE9-671FDA7F95B5@joyful.com> <847B6A16-5B4A-4CF9-94E5-4FC672C85ED2@joyful.com> Message-ID: On Sat, 21 May 2022, Simon Michael wrote: > FYI, https://haskell-links.org no longer requires javascript to search links. No need for JavaScript is good news! From ben at well-typed.com Tue May 24 16:44:53 2022 From: ben at well-typed.com (Ben Gamari) Date: Tue, 24 May 2022 12:44:53 -0400 Subject: [Haskell-cafe] GHC 9.4.1-alpha2 now available Message-ID: <8735gy98yb.fsf@smart-cactus.org> The GHC developers are happy to announce the availability of the second 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-alpha2 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. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by Hadrian, it's possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. 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-cases.rst [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md [release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha2/docs/users_guide/9.4.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From lemming at henning-thielemann.de Tue May 24 17:20:16 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 24 May 2022 19:20:16 +0200 (CEST) Subject: [Haskell-cafe] GHC 9.4.1-alpha2 now available In-Reply-To: <8735gy98yb.fsf@smart-cactus.org> References: <8735gy98yb.fsf@smart-cactus.org> Message-ID: On Tue, 24 May 2022, Ben Gamari wrote: > As always, do give this release a try and open a [ticket] if you see > anything amiss. On Linux-Deb11 many files in /usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220523/bin/ /usr/local/ghc-9.4.0/lib/ghc-9.4.0.20220523/lib/ have no read and exec permission for 'group' and 'other' users. From miao at decentral.ee Thu May 26 10:15:14 2022 From: miao at decentral.ee (Miao ZhiCheng) Date: Thu, 26 May 2022 13:15:14 +0300 Subject: [Haskell-cafe] Should there be a haskell template for inclusion polymorphism in Haskell? Message-ID: Hi Haskellers! Here are some of my thoughts about polymorphism in Haskell especially the inclusion polymorphism, with questions in the end. ~IGNORE THESE LHS BOILER PLATES~ > {-# LANGUAGE GADTs #-} > module Main where > import Unsafe.Coerce ( unsafeCoerce ) ~IGNORE THESE LHS BOILER PLATES~ * Classification of Polymorphism Let's assume that we are following the classification of polymorphism where there are four types of it: ?? Btw, does anyone have a good citation of this classification? I got it from all over the Internet instead: e.g https://www.tutorialspoint.com/types-of-polymorphisms-ad-hoc-inclusion-parametric-and-coercion ** Overloading Polymorphism It allows function with same name to act in different manner for different types. ** Coercion Polymorphism Also called as casting sometimes. ** Inclusion Polymorphism Also called as subtyping. This allows to point derived classes using base class pointers and references. ** Parametric Polymorphism Also called early Binding, it allows to use same piece of code for different types. We can get it by using templates. ** Sub Classifications In terms of being ad-hoc or universal: - Overloading and Coercion are ad-hoc, - Inclusion and Parametric are universal. In terms of being compile-time vs run-time: - Coercion, Overloading, Parametric are all compile-time polymorphism, - while only Inclusion is run-time polymorphism. * Different Polymorphism in Haskell In terms of their counter parties in Haskell language: ** Overloading Polymorphismin Haskell I think type classes basically provides such overloading ad-hoc polymorphism. Some thinks so too: https://stackoverflow.com/questions/6636107/how-does-haskell-handle-overloading-polymorphism > class Fooable a where > foo :: a -> Int > instance Fooable Int where > foo = id > instance Fooable Bool where > foo _ = 42 ** Coercion Polymorphism in Haskell I think Haskell has both `Coercible` & `unsafeCoerce` for handling representational equality in compile time. But I am not sure if c/c++ style of conercion between similar types such as int/float/double is something Haskell would want to inject these magic conversion code ever. ** Parametric Polymorphism in Haskell This is probably what Haskell is best at the most, demonstrated by the classic `map` function definition: > map' :: (a -> b) -> [a] -> [b] > map' _ [] = [] > map' f (x:xs) = f x : map' f xs Note that, one could also combine parametric and overloading together using constraints: > double :: Num a => a -> a > double x = x + x This `double` function is parametric, but constrained only to work with Num type classes, hence their implementations are overloaded. ** Inclusion Polymorphism in Haskell Ok, finally inclusion polymorphism is what I want to focus on and have some questions here. Before that, I do want to mention one observation, inclusion polymorphism probably is most likely the old OOP habits that die hard. For me at least, since I consider myself a recovering OOP run-time polymorphism addict, and my guess is that unless the use case do need run-time polymorphism, e.g. run-time execution layer abstration, it is often better off using other type of polymorphism to achieve the same result. And even Bjarne Stroustrup is flirting with the idea: [[https://www.youtube.com/watch?v=xcpSLRpOMJM][Bjarne Stroustrup - Object Oriented Programming without Inheritance - ECOOP 2015]] Let's think of translating this piece of pseudo OOP style code into haskell. ``` interface Num { Num (+)(Num a, Num b); Num (*)(Num a, Num b); Num abs(Num a); Num negate(Num a); Num signum(Num a); Num fromInteger(Integer); } interface Show { String show(Show a); } class AnyNum implements Num, Show { // trivially implements Num Show interfaces } // Now we can use AnyNum, AnyNum, etc. through their Num or Show interfaces. ``` In Haskell though, thanks to the ability of having existential type, AnyNum is actually quite nice to write: > data AnyNum where > MkAnyNum :: (Num a, Show a) => a -> AnyNum But in order to use AnyNum like using interfaces in our pseudo code, we would have to write these boiler plates and in some cases using unsafeCoerce due to not using Typeable run-time information: > instance Num AnyNum where > (+) (MkAnyNum a) (MkAnyNum b) = MkAnyNum $ a + unsafeCoerce b > (*) (MkAnyNum a) (MkAnyNum b) = MkAnyNum $ a + unsafeCoerce b > abs (MkAnyNum a) = MkAnyNum . abs $ a > negate (MkAnyNum a) = MkAnyNum . negate $ a > signum (MkAnyNum a) = MkAnyNum . signum $ a > fromInteger = MkAnyNum . fromInteger > instance Show AnyNum where > show (MkAnyNum a) = show a Here is some test code that demonstrate how distressful unsafeCoerce is: > main = do > let a = MkAnyNum(1 :: Int) > let b = MkAnyNum(2 :: Double) > let c = MkAnyNum(3 :: Int) > print $ show $ a + b > print $ show $ a + c Outputs are: ``` λ> "4611686018427387905" "4" ``` Few observations: - If there is at most one occurance of the usage of the type class, there is no need for the unsafeCoerce. - Otherwise, unsafeCoerce is required, or otherwise those functions could be left to "undefined". So my central questions for discussions are: - Is inclusion polymorphism something we should use at all in Haskell? - These boiler plate code maybe better be generated using Haskell template instead, is there one already, or should there be one? Cheers, Miao -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Thu May 26 21:32:38 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 26 May 2022 23:32:38 +0200 Subject: [Haskell-cafe] Should there be a haskell template for inclusion polymorphism in Haskell? Message-ID: > So my central questions for discussions are: > > - Is inclusion polymorphism something we should use at all in Haskell? > - These boiler plate code maybe better be generated using Haskell template > instead, is there one already, or should > there be one? Maybe one of the authors of a sub-typing library can share a more informed opinion on this. My view as a mathematician: A type being a subtype of another is a relation between types. Relations between types is what multi-parameter type classes is about. Hence it seems that this is how subtypes in Haskell ought to be done. For example, in the attenuation and records-sop package, the latter of which is based on genercis-sop, which depends on Template Haskell. So without having used any of the mentioned packages, I believe your second question can be answered with "yes". Regarding the first question, we should probably ask ourselves how much type-safety we're sacrificing for the convenience we gain. The Num example you gave shows one possible danger: While a subtype relation may hold mathematically, the implementiation details may cause this relation to fail in reality. Example: All floating point numbers are rationals, aren't they? So there should be a subtype relation. But how to convert NaN, -infinity or -0 of type Double to a pair of Integers? Olaf From gruen0aermel at gmail.com Fri May 27 01:20:01 2022 From: gruen0aermel at gmail.com (Aaron VonderHaar) Date: Thu, 26 May 2022 18:20:01 -0700 Subject: [Haskell-cafe] Should there be a haskell template for inclusion polymorphism in Haskell? In-Reply-To: References: Message-ID: Hi Miao, > ``` > interface Num { > Num (+)(Num a, Num b); > Num abs(Num a); > Num fromInteger(Integer); > ... > } > ``` I'm trying to follow through this and I'm afraid I'm not seeing how your example OOP interface would work. What would the implementation of `AnyNum.abs` be? It seems like it has no way of knowing whether the argument actually contains a Double or not? Wouldn't the `Num` interface instead need to be along the lines of the following? ``` interface Num { T (+)(T a, T b); T abs(T a); T fromInteger(Integer); } ``` or possibly ``` interface Num { Num (+)(Num a, Num b); Num abs(Num a); Num fromInteger(Integer); } ``` I'm thinking that the OOP version for your original Num interface would have the same unsafe casting issues that your haskell translation has. Or could you add an example of how `AnyNum.abs` would be implemented in the OOP version? --Aaron V. On Thu, May 26, 2022 at 3:18 AM Miao ZhiCheng via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > Hi Haskellers! > > Here are some of my thoughts about polymorphism in Haskell especially the > inclusion polymorphism, with questions in the > end. > > ~IGNORE THESE LHS BOILER PLATES~ > > > {-# LANGUAGE GADTs #-} > > module Main where > > import Unsafe.Coerce ( unsafeCoerce ) > > ~IGNORE THESE LHS BOILER PLATES~ > > * Classification of Polymorphism > > Let's assume that we are following the classification of polymorphism > where there are four types of it: > > ?? Btw, does anyone have a good citation of this classification? I got it > from all over the Internet instead: > e.g > https://www.tutorialspoint.com/types-of-polymorphisms-ad-hoc-inclusion-parametric-and-coercion > > ** Overloading Polymorphism > > It allows function with same name to act in different manner for different > types. > > ** Coercion Polymorphism > > Also called as casting sometimes. > > ** Inclusion Polymorphism > > Also called as subtyping. This allows to point derived classes using base > class pointers and references. > > ** Parametric Polymorphism > > Also called early Binding, it allows to use same piece of code for > different types. We can get it by using templates. > > ** Sub Classifications > > In terms of being ad-hoc or universal: > > - Overloading and Coercion are ad-hoc, > - Inclusion and Parametric are universal. > > In terms of being compile-time vs run-time: > > - Coercion, Overloading, Parametric are all compile-time polymorphism, > - while only Inclusion is run-time polymorphism. > > * Different Polymorphism in Haskell > > In terms of their counter parties in Haskell language: > > ** Overloading Polymorphismin Haskell > > I think type classes basically provides such overloading ad-hoc > polymorphism. > > Some thinks so too: > https://stackoverflow.com/questions/6636107/how-does-haskell-handle-overloading-polymorphism > > > class Fooable a where > > foo :: a -> Int > > instance Fooable Int where > > foo = id > > instance Fooable Bool where > > foo _ = 42 > > ** Coercion Polymorphism in Haskell > > I think Haskell has both `Coercible` & `unsafeCoerce` for handling > representational equality in compile time. > > But I am not sure if c/c++ style of conercion between similar types such > as int/float/double is something Haskell would > want to inject these magic conversion code ever. > > ** Parametric Polymorphism in Haskell > > This is probably what Haskell is best at the most, demonstrated by the > classic `map` function definition: > > > map' :: (a -> b) -> [a] -> [b] > > map' _ [] = [] > > map' f (x:xs) = f x : map' f xs > > Note that, one could also combine parametric and overloading together > using constraints: > > > double :: Num a => a -> a > > double x = x + x > > This `double` function is parametric, but constrained only to work with > Num type classes, hence their implementations > are overloaded. > > ** Inclusion Polymorphism in Haskell > > Ok, finally inclusion polymorphism is what I want to focus on and have > some questions here. > > Before that, I do want to mention one observation, inclusion polymorphism > probably is most likely the old OOP habits > that die hard. For me at least, since I consider myself a recovering OOP > run-time polymorphism addict, and my guess is > that unless the use case do need run-time polymorphism, e.g. run-time > execution layer abstration, it is often better off > using other type of polymorphism to achieve the same result. And even > Bjarne Stroustrup is flirting with the idea: > [[https://www.youtube.com/watch?v=xcpSLRpOMJM][Bjarne Stroustrup - Object > Oriented Programming without Inheritance - ECOOP 2015]] > > Let's think of translating this piece of pseudo OOP style code into > haskell. > > ``` > interface Num { > Num (+)(Num a, Num b); > Num (*)(Num a, Num b); > Num abs(Num a); > Num negate(Num a); > Num signum(Num a); > Num fromInteger(Integer); > } > > interface Show { > String show(Show a); > } > > class AnyNum implements Num, Show { > // trivially implements Num Show interfaces > } > > // Now we can use AnyNum, AnyNum, etc. through their Num or > Show interfaces. > ``` > > In Haskell though, thanks to the ability of having existential type, > AnyNum is actually quite nice to write: > > > data AnyNum where > > MkAnyNum :: (Num a, Show a) => a -> AnyNum > > But in order to use AnyNum like using interfaces in our pseudo code, we > would have to write these boiler plates and in > some cases using unsafeCoerce due to not using Typeable run-time > information: > > > instance Num AnyNum where > > (+) (MkAnyNum a) (MkAnyNum b) = MkAnyNum $ a + unsafeCoerce b > > (*) (MkAnyNum a) (MkAnyNum b) = MkAnyNum $ a + unsafeCoerce b > > abs (MkAnyNum a) = MkAnyNum . abs $ a > > negate (MkAnyNum a) = MkAnyNum . negate $ a > > signum (MkAnyNum a) = MkAnyNum . signum $ a > > fromInteger = MkAnyNum . fromInteger > > instance Show AnyNum where > > show (MkAnyNum a) = show a > > Here is some test code that demonstrate how distressful unsafeCoerce is: > > > main = do > > let a = MkAnyNum(1 :: Int) > > let b = MkAnyNum(2 :: Double) > > let c = MkAnyNum(3 :: Int) > > print $ show $ a + b > > print $ show $ a + c > > Outputs are: > ``` > λ> > "4611686018427387905" > "4" > ``` > > Few observations: > > - If there is at most one occurance of the usage of the type class, there > is no need for the unsafeCoerce. > - Otherwise, unsafeCoerce is required, or otherwise those functions could > be left to "undefined". > > So my central questions for discussions are: > > - Is inclusion polymorphism something we should use at all in Haskell? > - These boiler plate code maybe better be generated using Haskell template > instead, is there one already, or should > there be one? > > > Cheers, > Miao > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From miao at decentral.ee Fri May 27 10:42:36 2022 From: miao at decentral.ee (Miao ZhiCheng) Date: Fri, 27 May 2022 13:42:36 +0300 Subject: [Haskell-cafe] Should there be a haskell template for inclusion polymorphism in Haskell? In-Reply-To: References: Message-ID: > Hi Miao, > > interface Num { > Num (+)(Num a, Num b); > Num abs(Num a); > Num fromInteger(Integer); > ... > } > > I'm trying to follow through this and I'm afraid I'm not seeing how your example OOP interface would work. > What would the implementation of `AnyNum.abs` be? It seems like it has no way of knowing whether the argument actually contains a Double or not? > > Wouldn't the `Num` interface instead need to be along the lines of the following? > > ``` > interface Num { > T (+)(T a, T b); > T abs(T a); > T fromInteger(Integer); > } > ``` > > or possibly > > ``` > interface Num { > Num (+)(Num a, Num b); > Num abs(Num a); > Num fromInteger(Integer); > } > ``` Hi Aaron, You are right, I was a bit rushing in the end, and I should write a proper example instead of pseudo code. Here is a rewrite in actual C++: https://github.com/hellwolf/haskell-examples/blob/master/2022-05-25-inclusion-polymorphism/AnyNum.cpp While re-writing, it's clear that you cannot fit Num class in OOP, in C++ it's rather using generics ```c++ // generics/compile-time ad-hoc "type classes" // T: type of the number // C: container of the number template class Num { typedef Num ThisNum; protected: int _val; public: Num(int val) { _val = val; } // default implementation should work for int/double/etc. public: static C add(const ThisNum& a, const ThisNum& b) { return C(a._val + b._val); } static C mul(const ThisNum& a, const ThisNum& b) { return C(a._val * b._val); } static C abs(const ThisNum& a) { return C(std::abs(a._val)); } static C negate(const ThisNum& a) { return C(std::negate(a._val)); } static C signum(const ThisNum& a) { return C(T(std::signbit(a._val))); } static C fromInteger(T x) { return C(x); } }; ``` This looks very much similar to the Haskell `Num` type class. And the OOP-style stuff for Num and Show could rather be: ```c++ // run-time/inclusion polymorphism classes: class INum { public: virtual void operator +=(const INum&) = 0; virtual void operator *=(const INum&) = 0; }; class IShow { public: virtual std::string show() const = 0; }; class IAnyNum: public INum, public IShow {}; ``` So the question back to can we express the += and *= inclusion polymorphism for Haskell data types. It seems to me that sub-typing libraries Olaf suggested could be something to look into. > > I'm thinking that the OOP version for your original Num interface would have the same unsafe casting issues that your haskell translation has. > Or could you add an example of how `AnyNum.abs` would be implemented in the OOP version? Yes, indeed, without using `Typeable`, there is unsafe casting issue. In the C++ version I fixed, it uses dynamic_cast, which is basically using RTTI (similar to Haskell Typeable) to throw a run-time error if mismatched. Also you were right, there is no sensible abs for the OOP version. The OOP Num should be "object-oriented" ones such as "+=", "*=", etc. Miao, On Fri, May 27, 2022 at 4:20 AM Aaron VonderHaar wrote: > Hi Miao, > > > ``` > > interface Num { > > Num (+)(Num a, Num b); > > Num abs(Num a); > > Num fromInteger(Integer); > > ... > > } > > ``` > > I'm trying to follow through this and I'm afraid I'm not seeing how your > example OOP interface would work. > What would the implementation of `AnyNum.abs` be? It seems like > it has no way of knowing whether the argument actually contains a Double or > not? > > Wouldn't the `Num` interface instead need to be along the lines of the > following? > > ``` > interface Num { > T (+)(T a, T b); > T abs(T a); > T fromInteger(Integer); > } > ``` > > or possibly > > ``` > interface Num { > Num (+)(Num a, Num b); > Num abs(Num a); > Num fromInteger(Integer); > } > ``` > > I'm thinking that the OOP version for your original Num interface would > have the same unsafe casting issues that your haskell translation has. > Or could you add an example of how `AnyNum.abs` would be > implemented in the OOP version? > > --Aaron V. > > On Thu, May 26, 2022 at 3:18 AM Miao ZhiCheng via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > >> Hi Haskellers! >> >> Here are some of my thoughts about polymorphism in Haskell especially the >> inclusion polymorphism, with questions in the >> end. >> >> ~IGNORE THESE LHS BOILER PLATES~ >> >> > {-# LANGUAGE GADTs #-} >> > module Main where >> > import Unsafe.Coerce ( unsafeCoerce ) >> >> ~IGNORE THESE LHS BOILER PLATES~ >> >> * Classification of Polymorphism >> >> Let's assume that we are following the classification of polymorphism >> where there are four types of it: >> >> ?? Btw, does anyone have a good citation of this classification? I got it >> from all over the Internet instead: >> e.g >> https://www.tutorialspoint.com/types-of-polymorphisms-ad-hoc-inclusion-parametric-and-coercion >> >> ** Overloading Polymorphism >> >> It allows function with same name to act in different manner for >> different types. >> >> ** Coercion Polymorphism >> >> Also called as casting sometimes. >> >> ** Inclusion Polymorphism >> >> Also called as subtyping. This allows to point derived classes using base >> class pointers and references. >> >> ** Parametric Polymorphism >> >> Also called early Binding, it allows to use same piece of code for >> different types. We can get it by using templates. >> >> ** Sub Classifications >> >> In terms of being ad-hoc or universal: >> >> - Overloading and Coercion are ad-hoc, >> - Inclusion and Parametric are universal. >> >> In terms of being compile-time vs run-time: >> >> - Coercion, Overloading, Parametric are all compile-time polymorphism, >> - while only Inclusion is run-time polymorphism. >> >> * Different Polymorphism in Haskell >> >> In terms of their counter parties in Haskell language: >> >> ** Overloading Polymorphismin Haskell >> >> I think type classes basically provides such overloading ad-hoc >> polymorphism. >> >> Some thinks so too: >> https://stackoverflow.com/questions/6636107/how-does-haskell-handle-overloading-polymorphism >> >> > class Fooable a where >> > foo :: a -> Int >> > instance Fooable Int where >> > foo = id >> > instance Fooable Bool where >> > foo _ = 42 >> >> ** Coercion Polymorphism in Haskell >> >> I think Haskell has both `Coercible` & `unsafeCoerce` for handling >> representational equality in compile time. >> >> But I am not sure if c/c++ style of conercion between similar types such >> as int/float/double is something Haskell would >> want to inject these magic conversion code ever. >> >> ** Parametric Polymorphism in Haskell >> >> This is probably what Haskell is best at the most, demonstrated by the >> classic `map` function definition: >> >> > map' :: (a -> b) -> [a] -> [b] >> > map' _ [] = [] >> > map' f (x:xs) = f x : map' f xs >> >> Note that, one could also combine parametric and overloading together >> using constraints: >> >> > double :: Num a => a -> a >> > double x = x + x >> >> This `double` function is parametric, but constrained only to work with >> Num type classes, hence their implementations >> are overloaded. >> >> ** Inclusion Polymorphism in Haskell >> >> Ok, finally inclusion polymorphism is what I want to focus on and have >> some questions here. >> >> Before that, I do want to mention one observation, inclusion polymorphism >> probably is most likely the old OOP habits >> that die hard. For me at least, since I consider myself a recovering OOP >> run-time polymorphism addict, and my guess is >> that unless the use case do need run-time polymorphism, e.g. run-time >> execution layer abstration, it is often better off >> using other type of polymorphism to achieve the same result. And even >> Bjarne Stroustrup is flirting with the idea: >> [[https://www.youtube.com/watch?v=xcpSLRpOMJM][Bjarne Stroustrup - >> Object Oriented Programming without Inheritance - ECOOP 2015]] >> >> Let's think of translating this piece of pseudo OOP style code into >> haskell. >> >> ``` >> interface Num { >> Num (+)(Num a, Num b); >> Num (*)(Num a, Num b); >> Num abs(Num a); >> Num negate(Num a); >> Num signum(Num a); >> Num fromInteger(Integer); >> } >> >> interface Show { >> String show(Show a); >> } >> >> class AnyNum implements Num, Show { >> // trivially implements Num Show interfaces >> } >> >> // Now we can use AnyNum, AnyNum, etc. through their Num or >> Show interfaces. >> ``` >> >> In Haskell though, thanks to the ability of having existential type, >> AnyNum is actually quite nice to write: >> >> > data AnyNum where >> > MkAnyNum :: (Num a, Show a) => a -> AnyNum >> >> But in order to use AnyNum like using interfaces in our pseudo code, we >> would have to write these boiler plates and in >> some cases using unsafeCoerce due to not using Typeable run-time >> information: >> >> > instance Num AnyNum where >> > (+) (MkAnyNum a) (MkAnyNum b) = MkAnyNum $ a + unsafeCoerce b >> > (*) (MkAnyNum a) (MkAnyNum b) = MkAnyNum $ a + unsafeCoerce b >> > abs (MkAnyNum a) = MkAnyNum . abs $ a >> > negate (MkAnyNum a) = MkAnyNum . negate $ a >> > signum (MkAnyNum a) = MkAnyNum . signum $ a >> > fromInteger = MkAnyNum . fromInteger >> > instance Show AnyNum where >> > show (MkAnyNum a) = show a >> >> Here is some test code that demonstrate how distressful unsafeCoerce is: >> >> > main = do >> > let a = MkAnyNum(1 :: Int) >> > let b = MkAnyNum(2 :: Double) >> > let c = MkAnyNum(3 :: Int) >> > print $ show $ a + b >> > print $ show $ a + c >> >> Outputs are: >> ``` >> λ> >> "4611686018427387905" >> "4" >> ``` >> >> Few observations: >> >> - If there is at most one occurance of the usage of the type class, there >> is no need for the unsafeCoerce. >> - Otherwise, unsafeCoerce is required, or otherwise those functions could >> be left to "undefined". >> >> So my central questions for discussions are: >> >> - Is inclusion polymorphism something we should use at all in Haskell? >> - These boiler plate code maybe better be generated using Haskell >> template instead, is there one already, or should >> there be one? >> >> >> Cheers, >> Miao >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miao at decentral.ee Fri May 27 10:50:38 2022 From: miao at decentral.ee (Miao ZhiCheng) Date: Fri, 27 May 2022 13:50:38 +0300 Subject: [Haskell-cafe] Should there be a haskell template for inclusion polymorphism in Haskell? In-Reply-To: References: Message-ID: Very interesting that you are mentioning looking into multi-parameter type classes! I will think a bit about it. And thanks for the libraries you suggested, will also need to take some times to look into them FWIW: I made an actual OOP-style code in C++ to demonstrate the difference between compile-time and run-time polymorphism https://github.com/hellwolf/haskell-examples/blob/master/2022-05-25-inclusion-polymorphism/AnyNum.cpp On Fri, May 27, 2022 at 12:32 AM Olaf Klinke wrote: > > So my central questions for discussions are: > > > > - Is inclusion polymorphism something we should use at all in Haskell? > > - These boiler plate code maybe better be generated using Haskell > template > > instead, is there one already, or should > > there be one? > > Maybe one of the authors of a sub-typing library can share a more > informed opinion on this. My view as a mathematician: > A type being a subtype of another is a relation between types. > Relations between types is what multi-parameter type classes is about. > Hence it seems that this is how subtypes in Haskell ought to be done. > For example, in the attenuation and records-sop package, the latter of > which is based on genercis-sop, which depends on Template Haskell. So > without having used any of the mentioned packages, I believe your > second question can be answered with "yes". > Regarding the first question, we should probably ask ourselves how much > type-safety we're sacrificing for the convenience we gain. The Num > example you gave shows one possible danger: While a subtype relation > may hold mathematically, the implementiation details may cause this > relation to fail in reality. Example: All floating point numbers are > rationals, aren't they? So there should be a subtype relation. But how > to convert NaN, -infinity or -0 of type Double to a pair of Integers? > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Fri May 27 15:45:15 2022 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 27 May 2022 17:45:15 +0200 Subject: [Haskell-cafe] Should there be a haskell template for inclusion polymorphism in Haskell? In-Reply-To: References: Message-ID: <7cb8a98c781da0546bcf7df1f858733ab2018d7a.camel@aatal-apotheke.de> On Fri, 2022-05-27 at 13:50 +0300, Miao ZhiCheng wrote: > Very interesting that you are mentioning looking into multi-parameter type > classes! I will think a bit about it. > > And thanks for the libraries you suggested, will also need to take some > times to look into them > > FWIW: I made an actual OOP-style code in C++ to demonstrate the difference > between compile-time and run-time polymorphism > https://github.com/hellwolf/haskell-examples/blob/master/2022-05-25-inclusion-polymorphism/AnyNum.cpp > > > On Fri, May 27, 2022 at 12:32 AM Olaf Klinke wrote: > > > > So my central questions for discussions are: > > > > > > - Is inclusion polymorphism something we should use at all in Haskell? > > > - These boiler plate code maybe better be generated using Haskell > > template > > > instead, is there one already, or should > > > there be one? > > > > Maybe one of the authors of a sub-typing library can share a more > > informed opinion on this. My view as a mathematician: > > A type being a subtype of another is a relation between types. > > Relations between types is what multi-parameter type classes is about. > > Hence it seems that this is how subtypes in Haskell ought to be done. > > For example, in the attenuation and records-sop package, the latter of > > which is based on genercis-sop, which depends on Template Haskell. So > > without having used any of the mentioned packages, I believe your > > second question can be answered with "yes". > > Regarding the first question, we should probably ask ourselves how much > > type-safety we're sacrificing for the convenience we gain. The Num > > example you gave shows one possible danger: While a subtype relation > > may hold mathematically, the implementiation details may cause this > > relation to fail in reality. Example: All floating point numbers are > > rationals, aren't they? So there should be a subtype relation. But how > > to convert NaN, -infinity or -0 of type Double to a pair of Integers? > > > > Olaf > > > > Miao, Your existential type AnyNum is the union of all number types, but even set-theoretically there is no way of extending individual operations on many sets to a single operation on the union of all sets, even when the operations commute with subset inclusion. That ony works if the union is directed (see attached), that is, if for every two sets A and B there is a third set C in the union of which both other sets are a subset. So in order to implement AnyNum (5 :: Rational) + AnyNum (NaN :: Double) you first have to find a single other Num type that Rational and Double can be cast into, then perform the (+) there. What the libraries like generics-sop, attenuation and to some extent the Prelude do is to construct a hierarchy either via multi-parameter type classes A `IsSubtypeOf` B or constrained classes like Num a => Fractional a That may culminate in a most inclusive type or type class, providing all the operations of its ancestors. Notice the reversal of inclusions: Integer `IsSubtypeOf` Rational fromInteger :: Integer -> Rational instance Num Integer instance Fractional Rational Rational `IsSubclassOf` Num Instead of the union of all types under consideration, maybe the intersection is useful to you. Attached is a module that implements the initial object of a class (which I think in the case of Num is isomorphic to Integer), that is a type that can do everything every other Num type can do, but nothing more. AnyNum is the terminal object of Num. -- The initial object in the Num class newtype FreeNum = FreeNum { runNum :: forall r. (Integer -> r) -> -- fromInteger (r -> r -> r) -> -- (+) (r -> r -> r) -> -- (*) (r -> r) -> -- negate (r -> r) -> -- abs (r -> r) -> -- signum r } On this, we can implement numeric operations without casting. Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: FreeNum.hs Type: text/x-haskell Size: 2924 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Directed.hs Type: text/x-haskell Size: 926 bytes Desc: not available URL: From ben at well-typed.com Fri May 27 17:01:16 2022 From: ben at well-typed.com (Ben Gamari) Date: Fri, 27 May 2022 13:01:16 -0400 Subject: [Haskell-cafe] GHC.X.Hackage and GHC's release cycle Message-ID: <87v8tq7vwz.fsf@smart-cactus.org> Hello all, Recently in the Haskell Foundation's stability working group we have been discussing various practical issues that Haskell users and prospective adopters encounter around the ecosystem. During these discussions the topic of GHC's release schedule and the ecosystem's process migration to new GHC releases has come up repeatedly. To address some of these issues, I have opened a pair of somewhat-related HF Tech Proposals: * the GHC.X.Hackage proposal ([ghc.x.hackage]) seeks to extend the [head.hackage] infrastructure used to test GHC to enable use by library maintainers in porting and testing their libraries on new GHC releases. * the [tick-tock] release proposal seeks to provide better guidance to users needing long release lifecycles by designating every other release as a "long-term support" release, with 18-month backport window. Given the wide applicability of these proposals we hope to gather feedback from a broad swath of the community. If you have questions, opinions, or concerns on either, please leave your feedback on the respective proposal. We look forward to hearing from you. Thanks! - Ben [ghc.x.hackage]: https://github.com/haskellfoundation/tech-proposals/pull/27 [head.hackage]: https://ghc.gitlab.haskell.org/head.hackage/ [tick-tock]: https://github.com/haskellfoundation/tech-proposals/pull/34 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From zubin at well-typed.com Fri May 27 19:31:48 2022 From: zubin at well-typed.com (Zubin Duggal) Date: Sat, 28 May 2022 01:01:48 +0530 Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 9.2.3 released Message-ID: <20220527193148.xaj72eelctawugcm@zubin-msi> The GHC developers are very happy to at announce the availability of GHC 9.2.3. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.3). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html Blog Post: https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html This release includes many bug-fixes and other improvements to 9.2.2 including: * A fix to a critical linking bug on Windows causing the 9.2.2 release to be unusable (#21196). * Numerous bug fixes for regressions and other issues in the typechecker (#2147, #21515, #20582, #20820, #21130, #21479). * Correctness bugs in the code generator and compiler backends (#21396, #20959, #21465). * Packaging fixes on many platforms (#20760, #21487, #21402). * Many others. See the [release notes][] for a full list. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, 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 compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From shayne.fletcher.50 at gmail.com Fri May 27 23:24:32 2022 From: shayne.fletcher.50 at gmail.com (Shayne Fletcher) Date: Fri, 27 May 2022 19:24:32 -0400 Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 9.2.3 released In-Reply-To: References: <20220527193148.xaj72eelctawugcm@zubin-msi> Message-ID: there are already tickets covering this see https://gitlab.haskell.org/ghc/ghc/-/issues/21633 & -- https://gitlab.haskell.org/ghc/ghc/-/issues/21634. i have found that `allow-newer:true` and `resolver: nightly-2022-05-27` in `hadrian/stack.yaml` provides a workaround for the moment. On Fri, May 27, 2022 at 7:08 PM George Colpitts wrote: > Hi > > https://gitlab.haskell.org/ghc/ghc/-/issues/21506, ghc-9.4.1-alpha1 does > not install on macos, exists on 9.2.3 also. The workaround given in 21506 > works. Do you want a ticket for this? > > Thanks > George > > > On Fri, May 27, 2022 at 4:41 PM Zubin Duggal wrote: > >> >> The GHC developers are very happy to at announce the availability of GHC >> 9.2.3. Binary distributions, source distributions, and documentation are >> available at [`downloads.haskell.org`]( >> https://downloads.haskell.org/ghc/9.2.3). >> >> Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html >> Blog Post: >> https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html >> >> This release includes many bug-fixes and other improvements to 9.2.2 >> including: >> >> * A fix to a critical linking bug on Windows causing the 9.2.2 release >> to be unusable (#21196). >> >> * Numerous bug fixes for regressions and other issues in the >> typechecker (#2147, #21515, #20582, #20820, #21130, #21479). >> >> * Correctness bugs in the code generator and compiler backends (#21396, >> #20959, #21465). >> >> * Packaging fixes on many platforms (#20760, #21487, #21402). >> >> * Many others. See the [release notes][] for a full list. >> >> As some of the fixed issues do affect correctness users are encouraged >> to upgrade promptly. >> >> We would like to thank Microsoft Azure, GitHub, IOG, 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 compiling, >> >> - Zubin >> >> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> [release notes]: >> https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Shayne Fletcher -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher.50 at gmail.com Fri May 27 23:25:11 2022 From: shayne.fletcher.50 at gmail.com (Shayne Fletcher) Date: Fri, 27 May 2022 19:25:11 -0400 Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 9.2.3 released In-Reply-To: References: <20220527193148.xaj72eelctawugcm@zubin-msi> Message-ID: oops, sorry, no my mistake. please disregard. On Fri, May 27, 2022 at 7:24 PM Shayne Fletcher < shayne.fletcher.50 at gmail.com> wrote: > there are already tickets covering this see > https://gitlab.haskell.org/ghc/ghc/-/issues/21633 & > -- https://gitlab.haskell.org/ghc/ghc/-/issues/21634. i have found > that `allow-newer:true` and `resolver: nightly-2022-05-27` in > `hadrian/stack.yaml` provides a workaround for the moment. > > On Fri, May 27, 2022 at 7:08 PM George Colpitts > wrote: > >> Hi >> >> https://gitlab.haskell.org/ghc/ghc/-/issues/21506, ghc-9.4.1-alpha1 does >> not install on macos, exists on 9.2.3 also. The workaround given in 21506 >> works. Do you want a ticket for this? >> >> Thanks >> George >> >> >> On Fri, May 27, 2022 at 4:41 PM Zubin Duggal >> wrote: >> >>> >>> The GHC developers are very happy to at announce the availability of GHC >>> 9.2.3. Binary distributions, source distributions, and documentation are >>> available at [`downloads.haskell.org`]( >>> https://downloads.haskell.org/ghc/9.2.3). >>> >>> Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html >>> Blog Post: >>> https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html >>> >>> This release includes many bug-fixes and other improvements to 9.2.2 >>> including: >>> >>> * A fix to a critical linking bug on Windows causing the 9.2.2 release >>> to be unusable (#21196). >>> >>> * Numerous bug fixes for regressions and other issues in the >>> typechecker (#2147, #21515, #20582, #20820, #21130, #21479). >>> >>> * Correctness bugs in the code generator and compiler backends (#21396, >>> #20959, #21465). >>> >>> * Packaging fixes on many platforms (#20760, #21487, #21402). >>> >>> * Many others. See the [release notes][] for a full list. >>> >>> As some of the fixed issues do affect correctness users are encouraged >>> to upgrade promptly. >>> >>> We would like to thank Microsoft Azure, GitHub, IOG, 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 compiling, >>> >>> - Zubin >>> >>> >>> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >>> [release notes]: >>> https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > -- > Shayne Fletcher > -- Shayne Fletcher -------------- next part -------------- An HTML attachment was scrubbed... URL: From meng.wang at bristol.ac.uk Sat May 28 15:20:05 2022 From: meng.wang at bristol.ac.uk (Meng Wang) Date: Sat, 28 May 2022 15:20:05 +0000 Subject: [Haskell-cafe] Research fellow position at University of Bristol In-Reply-To: References: Message-ID: Dear All, Here is the second post at Bristol PL group. It is at the research associate level which is suitable for fresh PhD graduates. https://www.bristol.ac.uk/jobs/find/details/?jobId=274941&jobTitle=Research%20Associate%20or%20Senior%20Research%20Associate Best regards, Meng Wang, PhD (Oxon) Senior Lecturer of Programming Languages Head of PL research group School International Director SCEEM (CS, EEE, EMath) School, University of Bristol From: Meng Wang Date: Friday, 20 May 2022 at 09:42 To: haskell-cafe at haskell.org , haskell at haskell.org Subject: Research fellow position at University of Bristol Dear Haskellers, The programming languages group at Bristol is recruiting a research fellow to join our dynamic research group https://bristolpl.github.io/. Our research is ranked highly internationally and there is a strong focus on Haskell. We welcome functional programmers anywhere in the world to apply! (Another similar post at the level of research associate is also available.) https://www.bristol.ac.uk/jobs/find/details/?jobId=274355&jobTitle=Research%20Fellow Meng Wang, PhD (Oxon) Senior Lecturer of Programming Languages Head of PL research group School International Director SCEEM (CS, EEE, EMath) School, University of Bristol PS. A selection of recent papers can be found below. They should give a good indication of the type of PL research conducted at Bristol: - Perera et al. (2022). Linked visualisations via Galois dependencies. POPL 2022. 10.1145/3498668 - Xie et al. (2022). Staging with Class. POPL 2022. 10.1145/3498723 - Yamaguchi et al. (2021). Synbit: Synthesizing Bidirectional Programs using Unidirectional Sketches. OOPSLA 2021. 10.1145/3485482 - Qian Z et al. (2021). Client-Server Sessions in Linear Logic. ICFP 2021. 10.1145/3473567 - Jones E & Ramsay S. (2021). Intensional Refinement Datatypes. POPL 2021. 10.1145/3445980 - Gratzer D et al. (2020). Multimodal Dependent Type Theory. LICS 2020. 10.1145/3373718.3394736 - Matsuda K & Wang M. (2020). Sparcl: A Language for Partially-Invertible Computation. ICFP 2020. 10.1145/3409000 - Zhang J et al. (2019). A Study of Bug Resolution Characteristics in Popular Programming Languages. IEEE Transactions on Software Engineering. 10.1109/TSE.2019.2961897 - Abate A et al. (2019). Automated Formal Synthesis of Provably Safe Digital Controllers for Continuous Plants. Acta Informatica, vol 57. 10.1007/s00236-019-00359-1 - Almeida et al. (2019). Machine-Checked Proofs for Cryptographic Standards: Indifferentiability of Sponge and Secure High-Assurance Implementations of SHA-3. CCS 2019. 10.1145/3319535.336321 -------------- next part -------------- An HTML attachment was scrubbed... URL: From npolikarpova at eng.ucsd.edu Sun May 29 18:52:15 2022 From: npolikarpova at eng.ucsd.edu (Nadia Polikarpova) Date: Sun, 29 May 2022 11:52:15 -0700 Subject: [Haskell-cafe] Haskell Symposium 2022: Abstract Deadline Extended to June 1st Message-ID: <1bc4d6af-e73d-053c-ee8e-25dc96228490@eng.ucsd.edu> The Haskell'22 abstract deadline has been extended to *Wednesday, June 1st*. Please register your submissions by this date! The full submission deadline is still *Friday, June 3rd*. Please find the updated CFP below. Nadia Polikarpova (Haskell'22 chair) ========================================================================= ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2022 Ljubljana, Slovenia Thu 15 -- Fri 16 September, 2022 http://www.haskell.org/haskell-symposium/2022/ ========================================================================= The ACM SIGPLAN Haskell Symposium 2022 will be co-located with the 2022 International Conference on Functional Programming (ICFP). Differently from previous years, Haskell'22 will use a single-track submission process (that is, we will only have the regular track and no early track). The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * Tutorials, to document how to use a particular language feature, programming technique, tool or library within the Haskell ecosystem; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. Like an experience report and a functional pearl, tutorials should make a contribution from which other Haskellers can benefit. What distinguishes a tutorial is that its focus is on explaining an aspect of the Haskell language and/or ecosystem in a way that is generally useful to a Haskell audience. Tutorials for many such topics can be found online; the distinction here is that by writing it up for formal review it will be vetted by experts and formally published. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. If your contribution is not a research paper, please mark the title of your experience report, functional pearl, tutorial or system demonstration as such, by supplying a subtitle (Experience Report, Functional Pearl, Tutorial Paper, System Demonstration). Submission Details ================== Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2022 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors' own related work should be in the third person (e.g., not "We build on our previous work" but rather "We build on the work of "). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Tutorial: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Abstract submission: 1 June 2022 (Wed) Paper submission: 3 June 2022 (Fri) Notification: 1 July 2022 (Fri) Deadlines are anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/), and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism). Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell22.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors can distinguish between anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the conference chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Proceedings =========== Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permission-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy (http://www.acm.org/publications/policies/copyright-policy) and ACM Author Rights (http://authors.acm.org/main.html). Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artifacts ========= Authors of accepted papers are encouraged to make auxiliary material (artifacts like source code, test data, etc.) available with their paper. They can opt to have these artifacts published alongside their paper in the ACM Digital Library (copyright of artifacts remains with the authors). If an accepted paper's artifacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artifacts Available badge (https://www.acm.org/publications/policies/artifact-review-badging#available). Applications for such a badge can be made after paper acceptance and will be reviewed by the PC chair. Program Committee ================= Lennart Augustsson Epic Games Jean-Philippe Bernardy University of Gothenburg Iavor Diatchki Galois, Inc Michael Gale Tweag William Hallahan Yale University Makoto Hamana Gumma University Andrew Hirsch MPI SWS John Hughes Chalmers University of Technology Alexis King Tweag James Koppel Massachusets Institute of Technology Rudy Matela Channable Dominic Orchard University of Kent Nadia Polikarpova (chair) University of California, San Diego Eric Seidel Bridgewater Associates Satnam Singh Groq Wouter Swierstra Utrecht University Hiroshi Unno University of Tsukuba Marco Vassena Utrecht University Dimitrios Vytiniotis DeepMind If you have questions, please contact the chair at: npolikarpova at ucsd.edu ========================================================================= From kindaro at gmail.com Tue May 31 08:25:36 2022 From: kindaro at gmail.com (Ignat Insarov) Date: Tue, 31 May 2022 11:25:36 +0300 Subject: [Haskell-cafe] Hiding type variables from the signature? Message-ID: Hello café, hope you all doing well! I have this code [1]. Its purpose is to provide an `fmap` that works at any depth. Here is the gist of the gist: ```Haskell fmapz ∷ forall seed fruit seed' fruit' peels recursive. Squeezish seed seed' fruit fruit' peels recursive ⇒ (seed → seed') → fruit → fruit' fmapz function = stretch . fmap @(Squeezed (Strip seed fruit)) function . squeeze ``` As the examples show, it works, and even has some type inference. However, the type signature is unwieldy. It seems like it should have only 4 variables, but I have to also do some type level book-keeping for which the other 2 variables are needed. These book-keeping type variables are determined by type families from the other 4, so surely I can hide them inside a type synonym or something like that? I tried giving a quantified constraint, like so: ```Haskell type Squeezish ∷ ★ → ★ → ★ → ★ → Constraint type Squeezish seed seed' fruit fruit' = forall peels recursive. Squeezish' seed seed' fruit fruit' peels recursive class Squeezish' seed seed' fruit fruit' (peels ∷ [★ → ★]) (recursive ∷ Bool) instance ( peels ~ Strip seed fruit , ForAll peels Functor , Squeezy seed' fruit' peels recursive , Squeezy seed fruit peels recursive ) ⇒ Squeezish' seed seed' fruit fruit' peels recursive ``` — But then the constraints from the context of `Squeezish'` fail to make it to the use site and numerous errors arise. What can I do to solve this problem? Or is it theoretically impossible? [1]: https://gist.github.com/kindaro/6056f753bcf356ced96b817fee72533c From kindaro at gmail.com Tue May 31 10:06:41 2022 From: kindaro at gmail.com (Ignat Insarov) Date: Tue, 31 May 2022 13:06:41 +0300 Subject: [Haskell-cafe] Hiding type variables from the signature? In-Reply-To: References: Message-ID: Alright, I managed to circumvent this problem by adding more type classes with functional dependencies. Problematic version, for reference: https://gist.github.com/kindaro/6056f753bcf356ced96b817fee72533c/335e4399f50c74da59e033c2c4fa3551a2e6491e Current version: https://gist.github.com/kindaro/6056f753bcf356ced96b817fee72533c/b556f85589a8e12d104a2cc6a46a917679128735 ```Haskell fmapz :: forall peels seed seed'. Functors seed seed' peels => (seed -> seed') -> Dress seed peels -> Dress seed' peels fmapz function = stretch . fmap @(Squeezed peels) function . squeeze ``` — Much more better! From benoit.montagu at inria.fr Tue May 31 15:57:14 2022 From: benoit.montagu at inria.fr (Benoit Montagu) Date: Tue, 31 May 2022 17:57:14 +0200 Subject: [Haskell-cafe] ML Family Workshop 2022: DEADLINE EXTENSION Message-ID: <405c5cf9-1c8c-7c3a-ed57-369ad8d5cbf1@inria.fr> To increase your chances of submitting your work to the ML workshop, *the submission deadline is extended by a week*. The new deadline is Friday 10th June (AoE). A quick reminder: - The workshop does not have proceedings, making it the perfect venue   to run some ideas with the community or present some work in   progress within a friendly environment. - The work load as an author is low: submissions are only 3 pages long   (excluding references) - YOU have the power to make the ML workshop a success! - You have one more full week to submit to   (please register your submission early!) - All the details are here: - The ML workshop is colocated with ICFP 2022 -- Benoît Montagu, chair of the ML workshop 2022 From miao at decentral.ee Tue May 31 23:54:34 2022 From: miao at decentral.ee (Miao ZhiCheng) Date: Wed, 1 Jun 2022 02:54:34 +0300 Subject: [Haskell-cafe] Should there be a haskell template for inclusion polymorphism in Haskell? In-Reply-To: <7cb8a98c781da0546bcf7df1f858733ab2018d7a.camel@aatal-apotheke.de> References: <7cb8a98c781da0546bcf7df1f858733ab2018d7a.camel@aatal-apotheke.de> Message-ID: Hi Olaf! Sorry for a bit of delay, I finally managed to digest your inputs. Your existential type AnyNum is the union of all number types, but even > set-theoretically there is no way of extending individual operations on > many sets to a single operation on the union of all sets, even when the > operations commute with subset inclusion. That ony works if the union > is directed (see attached), that is, if for every two sets A and B > there is a third set C in the union of which both other sets are a > subset. > So in order to implement > AnyNum (5 :: Rational) + AnyNum (NaN :: Double) > you first have to find a single other Num type that Rational and Double > can be cast into, then perform the (+) there. > Thank you for the example! I managed to play around with it, and added a bit more general examples: ``` instance Castable Integer Double where cast1 = fromInteger instance Castable Rational Double where cast1 = fromRational instance Castable Double Double where cast1 = id instance (Castable a Double, Castable b Double) => Directed Num a b Double where castUnion _ (a, b) = (cast1 a, cast1 b) genericPlus :: forall a b c. (Num a, Num b, Num c, Directed Num a b c) => a -> b -> c genericPlus = castOp (Proxy :: Proxy Num) (+) main = do print $ show $ genericPlus (2 :: Integer) (5 :: Integer) print $ show $ genericPlus (1/3 :: Rational) (5 :: Integer) print $ show $ genericPlus (1/3 :: Rational) (2/3 :: Rational) print $ show $ genericPlus (4 :: Integer) (2/3 :: Rational) ``` That's interesting, it also makes me think how the C language style of "implicit casting" is working under the hood. > > What the libraries like generics-sop, attenuation and to some extent > the Prelude do is to construct a hierarchy either via multi-parameter > type classes > A `IsSubtypeOf` B > or constrained classes like > Num a => Fractional a > That may culminate in a most inclusive type or type class, providing > all the operations of its ancestors. Notice the reversal of > inclusions: > > Integer `IsSubtypeOf` Rational > fromInteger :: Integer -> Rational > instance Num Integer > instance Fractional Rational > Rational `IsSubclassOf` Num > > Instead of the union of all types under consideration, maybe the > intersection is useful to you. Attached is a module that implements the > initial object of a class (which I think in the case of Num is > isomorphic to Integer), that is a type that can do everything every > other Num type can do, but nothing more. AnyNum is the terminal object > of Num. > > -- The initial object in the Num class > newtype FreeNum = FreeNum { > runNum :: forall r. > (Integer -> r) -> -- fromInteger > (r -> r -> r) -> -- (+) > (r -> r -> r) -> -- (*) > (r -> r) -> -- negate > (r -> r) -> -- abs > (r -> r) -> -- signum > r > } > > On this, we can implement numeric operations without casting. > That's the next level... I don't think I can manage to figure out how to define "operations in NumSig num" or even a `freeDouble` today... Although it already deviates from my original inquiry, which was about run-time polymorhpism and have some sort of OO-style INum class in Haskell. As later I figured out, a "+=" operator would make more sense for "objects", and type checkings could be run-time using Typeable. But I learned something already, fun exercise so far though! Best regards, Miao > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: