September 2022 - Haskell-Cafe

Props to cpphs; why so little used?
by Anthony Clayden 20 Sep '22

20 Sep '22

Thank you to the author and maintainers of cpphs https://hackage.haskell.org/package/cpphs It has tightly-focussed functionality for what I wanted to do: a more haskell-friendly counterpart to cpp. How to get it to behave as I wanted wasn't always obvious. I made some notes https://stackoverflow.com/a/73768057/2840542 Haskell libraries generally use cpp -- and then users complain how awkward it can be. I don't see that cpp does anything better/different vs cpphs -- that is, cpphs understands all the #if compiler_version logic. Then why isn't every library preferring cpphs? AntC

4 4

Re: [Haskell-cafe] Cabal: other-modules necessary?
by Tom Ellis 20 Sep '22

20 Sep '22

Ah, that's interesting Oleg, thanks. I like the idea of Cabal being able to specify the exact mapping between modules and source files. Tom On Fri, Sep 16, 2022 at 04:05:53PM +0300, Oleg Grenrus wrote: > That is error generated by GHC. > > The culprit is `ghc --make` mode which discovers modules/files on its own. > > If there were a way to say (for Cabal to GHC) that use these files to > compile the component, and fail otherwise, then -Wmissing-home-modules > would turn into error. > > In fact, it would be great if it where possible to say that *this* > module is in *that* file, something like `MyFoo:src/MyFoo.hs`. > > That would also solve a problem of having same hs-source-dirs for > different components, as Cabal would be able to tell GHC that "don't > look for this modules locally, use dependencies". As currently GHC will > eagerly look for modules locally first. Always. > > - Oleg > > On 16.9.2022 12.23, Tom Ellis wrote: > > On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote: > >> The cabal user guide says (in section 6.2.12): "Every module in the package > >> must be listed in one of other-modules, library:exposed-modules or > >> executable:main-is fields." > >> > >> However, I only get a warning message, when I comment out the other-modules > >> field in my .cabal file. The program compiles. This is the message: > >> > >> <no location info>: warning: [-Wmissing-home-modules] > >> These modules are needed for compilation but not listed in your .cabal > >> file's other-modules: > >> Hsskripte Sicherung SicherungAktionen Text Wahl Zeit > >> > >> Is it really necessary to specify all the imported modules? If so, why does > >> the program compile? Can that warning message be turned off? > > In response to all the sibling replies at once, is there a good reason > > for this behaviour? Succeeding but then failing later with obscure > > errors (once the original warning message is nowhere to be seen) seems > > like the worst of all worlds. Suppose cabal errored here and failed > > to proceed. What would be the downside of that (besides backward > > incompatibility)?

2 1

[TFP 2023 Call for Papers] 24th International Symposium on Trends in Functional Programming
by Peter Achten 20 Sep '22

20 Sep '22

# TFP 2023 -- Call for Papers (trendsfp.github.io) ## Important Dates Submission deadline: pre-symposium, full papers, Wednesday 23rd November, 2022 Submission deadline: pre-symposium, draft papers, Friday 16th December, 2022 Notification: pre-symposium submissions, Friday 23rd December, 2022 Registration: Friday 6th January, 2023 TFPIE Workshop: Thursday 12th January, 2023 TFP Symposium: Friday 13th - Sunday 15th January, 2023 Submission deadline: post-symposium review, Friday 17th February, 2023 Notification: post-symposium submissions, Friday 31st March, 2023 The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. This year, TFP will take place in-person at UMass Boston, Massachusetts in the United States. It is co-located with the Trends in Functional Programming in Education (TFPIE) workshop, which will take on the day before the main symposium. Please be aware that TFP has several submission deadlines. The first, November 23, is for authors that wish to have their full paper reviewed prior to the symposium. Papers that are accepted in this way must also be presented at the symposium. The second, December 16, is for authors that wish to present their work or work-in progress at the symposium first without submitting to the full review process for publication. These authors can then take into account feedback received at the symposium and submit a full article for review by the third deadline, February 17. ## Scope The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research Articles: Leading-edge, previously unpublished research work * Position Articles: On what new trends should or should not be * Project Articles: Descriptions of recently started new projects * Evaluation Articles: What lessons can be drawn from a finished project * Overview Articles: Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: * Functional programming and multicore/manycore computing * Functional programming in the cloud * High performance functional computing * Extra-functional (behavioural) properties of functional programs * Dependently typed functional programming * Validation and verification of functional programs * Debugging and profiling for functional languages * Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. * Interoperability with imperative programming languages * Novel memory management techniques * Program analysis and transformation techniques * Empirical performance studies * Abstract/virtual machines and compilers for functional languages * (Embedded) domain specific languages * New implementation strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2023 program chair, Stephen Chang. ## Best Paper Awards TFP awards two prizes for the best papers each year. First, to reward excellent contributions, TFP awards a prize for the best overall paper accepted for the post-conference formal proceedings. Second, a prize for the best student paper is awarded each year. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, then that paper will receive both prizes. ## Instructions to Authors Papers must be submitted at: <https://easychair.org/conferences/?conf=tfp23> Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. Further, pre-symposium submissions may either be full (earlier deadline) or draft papers (later deadline). ## Pre-symposium formal review Papers to be formally reviewed before the symposium should be submitted before the early deadline and will receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected for publication but accepted for presentation may be resubmitted for the post-symposium formal review. ## Post-symposium formal review Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. ## Paper categories Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. ## Format Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site. ## Program Committee Peter Achten, Radboud University Nijmegen, Netherlands Nada Amin, Harvard University, USA Ambrose Bonnaire-Sergeant, Untypable LLC, USA Laura M. Castro, University of A Coruña, Spain Stephen Chang (Chair), University of Massachusetts Boston, US John Clements, Cal Poly, USA Youyou Cong, Tokyo Institute of Technology, Japan Paul Downen, University of Massachusetts Lowell, USA Kathy Gray, Meta Platforms, Inc., UK Ben Greenman, University of Utah, USA Jason Hemann, Seton Hall University, USA Patricia Johann, Appalachian State University, USA Alexis King, Tweag, USA Julia Lawall, Inria-Paris, France Barak Pearlmutter, Maynooth University, Ireland Norman Ramsey, Tufts University, USA Ilya Sergey, National University of Singapore, Singapore Melinda Tóth, Eötvös Loránd University, Hungary Ningning Xie, University of Toronto, Canada

1 0

Cabal: other-modules necessary?
by Volker Wysk 16 Sep '22

16 Sep '22

Hi The cabal user guide says (in section 6.2.12): "Every module in the package must be listed in one of other-modules, library:exposed-modules or executable:main-is fields." However, I only get a warning message, when I comment out the other-modules field in my .cabal file. The program compiles. This is the message: <no location info>: warning: [-Wmissing-home-modules] These modules are needed for compilation but not listed in your .cabal file's other-modules: Hsskripte Sicherung SicherungAktionen Text Wahl Zeit Is it really necessary to specify all the imported modules? If so, why does the program compile? Can that warning message be turned off? Apart from that, I'm happy with cabal. :-) Cheers, Volker

7 12

Cabal problem, broken packages?
by Volker Wysk 16 Sep '22

16 Sep '22

Hi! I've lately set up the Haskell environment on my Linux box, with no problems. Then I have installed some packages with "cabal install", again without problems. But now I'm trying to install another package and I get a dependency conflict. It doesn't seem to matter which package I try to install: desktop ~ $ cabal install rfc5051 Resolving dependencies... cabal: Could not resolve dependencies: [__0] next goal: directory (user goal) [__0] rejecting: directory-1.3.8.0 (constraint from user target requires ==1.3.7.1) [__0] trying: directory-1.3.7.1 [__1] next goal: ghc (user goal) [__1] rejecting: ghc-9.4.2, ghc-9.4.1, ghc-9.2.4, ghc-9.2.3, ghc-9.2.2, ghc-9.2.1, ghc-9.0.2, ghc-8.10.7, ghc-8.10.2, ghc-8.10.1 (constraint from user target requires ==8.8.4) [__1] rejecting: ghc-8.8.4/installed-8.8... (conflict: directory==1.3.7.1, ghc => directory==1.3.6.0/installed-1.3...) [__1] rejecting: ghc-8.8.3, ghc-8.8.1, ghc-8.6.5, ghc-8.6.4, ghc-8.6.1, ghc-8.4.4, ghc-8.4.3, ghc-8.4.1, ghc-8.2.2, ghc-8.2.1, ghc-9.2.3.20220620 (constraint from user target requires ==8.8.4) [__1] fail (backjumping, conflict set: directory, ghc) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: directory, ghc This doesn't make much sense to me. How can I repair it? Are the packages broken? Can a solution somehow be specified? Cheers, Volker

4 16

What became of James Cook? (Need package update)
by Olaf Klinke 14 Sep '22

14 Sep '22

Dear Café, does anyone happen to know what became of James Cook? (The programmer [1,2] a.k.a. mokus, not the explorer.) On github his last commit was in May. I've been trying to contact him at mokus(a)deepbondi.net three timessince March, but no luck. I'm using his package [3] which does not have a public repo. It needs minor adjustments to comply with the MonadFail change. Currently I have no intentions to properly take over the package, since James does seem to be an active developer generally, but James hasn't answered my request to become a hackage co-maintainer of [3] either. Does anyone know alternative channels to reach James? Or could such a minor adjustment [4] be made by the hackage trustees? Thanks Olaf [1] https://hackage.haskell.org/user/JamesCook [2] https://github.com/mokus0 [3] https://hackage.haskell.org/package/dbf [4] dbf-0.0.0.2 is broken by the removal of "fail" from the Monad class, as src/Database/XBase/Dbf/Structures.hs uses fail in line 61 and binary does not implement MonadFail for its PutM Monad. A quick workaround is to replace the call to fail by error. (Which should be semantically equivalent for the old Control.Monad.fail)

1 0

Build haddock documentation of a cabal project
by coot＠coot.me 13 Sep '22

13 Sep '22

Hello Haskell Cafe Next release of `cabal` and `haddock` will gain the capability of building documentation of a cabal project. A few weeks ago when the PR (https://github.com/haskell/cabal/pull/8162) was still in review I wrote a blog post about it: https://coot.me/posts/cabal-haddock-project.html Cheers, Marcin

2 1

OOPSLA 2023: Round 1 Call for Papers
by Andreea Costea 12 Sep '22

12 Sep '22

======================================================================== PACMPL Issue OOPSLA 2023 Call for Papers OOPSLA 2023 will be held as part of The ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH'23) October 23-27, 2023, Lisbon, Portugal https://2023.splashcon.org/track/splash-2023-oopsla ======================================================================== ### Important dates ROUND 1: Submission Deadline: Fri Oct 28, 2022 Author Response: Wed Dec 07 - Fri Dec 9 Author Notification: Thu Dec 22 Submission of Revisions: Mon Feb 13 - Fri Feb 24 ROUND 2: Submission Deadline: Fri Apr 14, 2023 Author Response: Wed Jun 14 - Fri Jun 16 Author Notification: Fri Jun 30 Submission of Revisions: Mon Aug 14 - Fri Aug 18 Camera ready: Thu Aug 31 Papers accepted at either of the rounds will be published in the 2023 volume of PACMPL(OOPSLA) and invited to be presented at the SPLASH conference in October 2023. ### Scope The OOPSLA issue of the Proceedings of the ACM on Programming Languages (PACMPL) welcomes papers focusing on all practical and theoretical investigations of programming languages, systems and environments. Papers may target any stage of software development, including requirements, modeling, prototyping, design, implementation, generation, analysis, verification, testing, evaluation, maintenance, and reuse of software systems. Contributions may include the development of new tools, techniques, principles, and evaluations. ### Review Process PACMPL(OOPSLA) has two _rounds_ of reviewing. The final outcome of each round can be one of Accept, Revise or Reject. *Accept*: Accepted papers will appear at the next PACMPL(OOPSLA). *Revise*: Papers in this category are invited to submit a revision to the _next round_ of submissions with a specific set of expectations to be met. When authors resubmit, they should clearly explain how the revisions address the comments of the reviewers. The revised paper will be re-evaluated, and either accepted or rejected. Resubmitted papers will retain the same reviewers throughout the process. *Reject*: Rejected papers will not be included in the 2023 volume of PACMPL(OOPSLA). Papers in this category are not guaranteed a review if resubmitted less than one year from the date of original submission. A paper will be judged to be a resubmission if it is substantially similar to the original submission. The judgment that a paper is a resubmission of the same work and whether, in this case, it will be reviewed or not is at the discretion of the Chair. Obviously, this same policy applies to papers that were rejected for inclusion in the 2022 volume of PACMPL(OOPSLA). Each _round_ of reviewing consists of two _phases_. The first phase evaluates the papers and results in an early notification of Reject, Revise, or Conditional Accept. During the first phase, authors will be able to read their reviews and respond to them. The second phase is restricted to conditionally accepted papers. Authors must make a set of mandatory revisions. The second phase assesses whether the required revisions have been addressed. The outcome can be Accept, Revise or Reject. ### Submissions Submitted papers must be at most **23 pages** in 10 point font. There is no page limit on references. No appendices are allowed on the main paper, instead authors can upload supplementary material with no page or content restrictions, but reviewers may choose to ignore it. Submissions must adhere to the "ACM Small" template available from [the ACM](http://www.acm.org/publications/authors/submissions). Papers are expected to use author-year citations. Author-year citations may be used as either a noun phrase, such as "The lambda calculus was originally conceived by Church (1932)", or a parenthetic phase, such as "The lambda calculus (Church 1932) was intended as a foundation for mathematics". PACMPL uses double-blind reviewing. Authors' identities are only revealed if a paper is accepted. Papers must 1. omit author names and institutions, 2. use the third person when referencing your work, 3. anonymise supplementary material. Nothing should be done in the name of anonymity that weakens the submission; see the DBR FAQ. When in doubt, contact the Review Committee Chairs. Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by [SIGPLAN's Republication Policy](http://www.sigplan.org/Resources/Policies/Republication). Submitters should also be aware of [ACM's Policy and Procedures on Plagiarism](http://www.acm.org/publications/policies/plagiarism_policy). Submissions are expected to comply with the [ACM Policies for Authorship](https://www.acm.org/publications/authors/information-for-author…. ### Artifacts Authors should indicate with their initial submission if an artifact exists, describe its nature and limitations, and indicate if it will be submitted for evaluation. Accepted papers that fail to provide an artifact will be requested to explain the reason they cannot support replication. It is understood that some papers have no artifacts. ### Publication PACMPL is a Gold Open Access journal, all papers will be freely available to the public. Authors can voluntarily cover the article processing charge ($400), but payment is not required. The official publication date is the date the journal are made available in the ACM Digital Library. The journal issue and associated papers may be published up to two weeks prior to the first day of the conference. ### Additional Information Consult FAQ in Call for Papers at: https://2023.splashcon.org/track/splash-2023-oopsla ### Review Committee PC Chair: Mira Mezini (TU Darmstadt) Derek Dreyer (MPI-SWS, DE)- Associate Chair Sophia Drosopolou (Facebook; Imperial College, UK)- Associate Chair Patrick Eugster (USI, Switzerland; Purdue U.)- Associate Chair Shriram Krishnamurthi (Brown University, USA)- Associate Chair Jonathan Aldrich (CMU, USA) Karim Ali (U. Alberta, Canada) Peter Alvaro (UC Santa Cruz, USA) Stefanie Balzer (CMU, USA) Osbert Bastani (U. Penn, USA) Annette Bieniusa (U. Kaiserslautern, Germany) Sebastian Burkhardt (MSR, Switzerland) Satish Chandra (Facebook, USA) James Cheney (University of Edinburgh; Alan Turing Institute, UK) Albert Cohen (Google, France) Wolfgang De Meuter (VUB, BE) Dominique Devriese (KU Leuven, Belgium) Dana Drachsler Cohen (Technion, Israel) Jana Dunfield (Queen’s University in Kingston, Ontario, CA) Sebastian Erdweg (U. Mainz, Germany) Matthew Flatt (U. Utah, USA) Jeremy Gibbons (U. Oxford, UK) Anitha Gollamudi (UMass, USA) Elisa Gonzalez Boix (VUB, Belgien) Andrew Gordon (MS Research, Edinburgh, UK) Dan Grossman (U. Washington, USA) Arjun Guha (Northeastern U., USA) Philipp Haller (KTH, Sweden) Görel Hedin (Lund University, Sweden) Steven Holtzen (Northeastern U., USA) Justin Hsu (Cornell University, USA) Atsushi Igarashi (Kyoto U., Japan) Ranjit Jhala (UC San Diego, USA) Gowtham Kaki (U. Colorado, USA) Neel Krishnaswami (Cambridge, UK) Burcu Kulahcioglu Ozkan (Delft University of Technology, The Netherlands) Sorin Lerner (UCSD, USA) Hongjin Liang (Nanjing University, CN) Crista Lopes (UC Irvine, USA) Kenji Maillard (Inria Nantes & University of Chile) Hidehiko Masuhara (Tokyo Institute of Technology, Japan) Ana Milanova (Rensselaer Polytechnic Institute) Heather Miller (CMU, USA) Ragnar Mogk (TU Darmstadt, DE) Anders Møller (Aarhus U,, Danemark) Fabrizio Montesi (Univ. of Southern Denmark, Denmark) Sarah Nadi (U. Alberta, Canada) James Noble (U. Wellington, New Zealand) Bruno C. d. S. Oliveira (U. Hong Kong, Hong Kong) Klaus Ostermann (U. Tübingen, Germany) Mangpo Phothilimthana (Google Brain, USA) Benjamin Pierce (UPenn, USA) Nadia Polikarpova (UC San Diego, USA) Michael Pradel (U. Stuttgart, Germany) Shaz Qadeer (Facebook, USA) Marianna Rapoport (Amazon Web Services, Canada) Cindy Rubio-González (UC Davis, USA) Sukyoung Ryu (KAIST, Korea) Guido Salvaneschi (U. St. Gallen, Switzerland) Mark Santolucito (Columbia, USA) Ilya Sergey (National University of Singapore, Singapore) Armando Solar-Lezama (MIT, USA) Manu Sridharan (University of California, USA) Charles Sutton (Google, UK) Joseph Tassarotti (New York University, USA) Ross Tate (Cornell U., USA) Peter Thiemann (U. Freiburg, Germany) Bernardo Toninho (Universidade Nova de Lisboa, Portugal) Viktor Vafeiadis (MPI, Germany) Tijs van der Storm (CWI; University of Groningen, Netherlands) Vasco Vasconcelos (U. Lisbon, Portugal) Jan Vitek (Northeastern U./Czech Technical University) Dimitrios Vytiniotis (DeepMind, UK) David Walker (Princeton, USA) Conrad Watt (U. Cambridge, UK) Pascal Weisenburger (U. St. Gallen, Switzerland) Qirun Zhang (Gatech, USA)

1 0

Combine pattern synonyms and record wild cards
by rowan goemans 12 Sep '22

12 Sep '22

Hello all, I'm playing with pattern synonyms to create a more intuitive API. Essentially what I would like is to allow a record wild card through a pattern synonym. Allow me to illustrate with an example. I have a data type. `data Foo a = Foo { unFoo :: a }` and a type `FooMaybe a = Maybe (Foo a)`. Now I have a pattern synonym `pattern FooJust x = Just (Foo x)`. This works and I can match on it no problem. But by doing this I lose the ability to use RecordWildCards. I can do this `myFun (Just Foo{..}) but not this `myFun FooJust{..}`. Is there some way to use pattern synonym while preserving the ability of using record wild cards? Best regards, Rowan Goemans

1 0

Re: [Haskell-cafe] Generic "annotations" on type definitions
by Olaf Klinke 11 Sep '22

11 Sep '22

> Hello all, > > I was recently thinking about a generic programming application > (auto-generating UI code from data definitions) that would benefit from the > ability to "annotate" data definitions. For example, let's say you have a > type > > data Foo = Foo {barred :: Boolean} > > You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps > the generic UI code defaults to making a check-box for Boolean values, but > you would rather have it be a radio button. It would be advantageous to be > able to write something like e.g. > > data Foo = Foo {barred :: Boolean # RenderMode RadioButton} > > In many languages, you have the ability to annotate data fields in a way > which has no bearing whatsoever on the first-order behavior or > representation of the type, and is only reflected via the language's > generic programming API. For example, in Java, you have > > class Foo { > @RenderMode(RadioButton) > bool barred; > } > > And in Rust, you have > struct Foo { > #[render_mode(radio_button)] > barred : bool > } > > In Haskell, I do not believe we have any such system in place for > interfacing with Generics. > > The closest I am familiar with is from the optparse-generic package, where > you write code of the form > > data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton} > > See > https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Gen…:: > :: > > This is basically a clever way to sort of re-create what we have available > in Rust or Java, using type families, but with the annoying downside that > it makes interacting with your type in normal code much more cumbersome, > and is also relatively confusing to read and write. > > Compare Rust's Clap package, which is very similar to optparse-generic, but > more convenient to work with because the annotations don't impact normal > usage of the type. > > See https://docs.rs/clap/latest/clap/#example > > Would it be technically feasible to add such a thing to GHC's Generics > support? I could imagine something like updating the GHC.Generics Meta > type's MetaCons constructor to > > MetaCons Symbol FixityI Bool *[Annotation]* > > Best, > Will Why not use special syntax in comments, like we do for Haddock, doctests etc. data Foo = Foo { barred :: Boolean -- ^ #GUI[RenderMode RadioButton] } There is a functional language capable of auto-generating input forms: Clean https://clean.cs.ru.nl/Clean with the iTask library on top. It can also generate forms for recursive types. The Dutch coast guard uses it to interactively design queries to a database of marine vessel movements. It'd be cool if Haskell's Generics also could do that. Olaf

3 3