- Haskell-Cafe - Haskell.org

Surprising interaction between @-patterns and nested patterns
by Tom Ellis 05 Jan '23

05 Jan '23

Consider the following: let x0 = (undefined, ()) ; ((_, _), _) = x0 in x0 `seq` () () but then combining the patterns into an @-pattern, which really feels like it shouldn't change semantics: let x1@((_, _), _) = (undefined, ()) in x1 `seq` () -> undefined Does this strike anyone else as odd? The reason for this behaviour is that let x@p = rhs in body is translated to case rhs of ~(x@p) -> body according to section 3.12 of The Report[1] which is then translated to (\x -> body) (case rhs of x@p -> x) if p binds no variables, according to section 3.17.3 of The Report[2], and then to (\x -> body) (case rhs of p -> (\x -> x) rhs) which is equivalent to (\x -> body) (case rhs of p -> rhs) Putting it all together let x0 = (undefined, ()) ; ((_, _), _) = x0 in x0 `seq` () desugars as (\x0 -> x0 `seq` ()) (let v = (undefined, ()) in case v of ((_, _), _) -> v) which evaluates as let v = (undefined, ()) in case v of ((_, _), _) -> () This seems very odd to me. Why should combining two non-diverging patterns into an @-pattern cause divergence? Specifically, the translation from let x@p = rhs in body to case rhs of ~(x@p) -> body seems highly dubious. It comes from the more general rule translating let p = rhs in body to case rhs of ~p in body but it seems to interact badly with @-patterns. It seems like the rule for @-patterns should be something like let x@p = rhs in body translates to case rhs of ~(x@(~p)) in body Then the original expression containing x1 would not diverge. Does anyone else have a view on this matter? Tom [1] https://www.haskell.org/onlinereport/exps.html#sect3.12 [2] https://www.haskell.org/onlinereport/exps.html#sect3.17.3

4 5

CLC Election January 2023
by Andrew Lelechenko 05 Jan '23

05 Jan '23

The terms of three CLC members are ending in January, so we are seeking new nominations! # Who should apply? Anyone who meets the following criteria should apply: * Candidates should have enough bandwidth to review merge requests to `base` on a semi-frequent basis (3 to 5 per month), and sustain this for their 3 years term in a healthy manner. * Candidates should be able to contribute opinions and analysis to issues raised by the community as a part of the CLC proposal process on a semi-frequent basis (3 to 5 per month). * Candidates should be good communicators, and at least be able to articulate to the CLC team when they will be available vs. unavailable. * Candidates should be productive, and be able to follow through on merge requests and conversations to their completion in a diligent and timely manner. We encourage any and all who satisfy these requirements to apply. Please note that we are not looking for the biggest galaxy brain in the room - quite the opposite. We are looking for productive, motivated individuals who want to help support the ecosystem that we love. As such, we hope to build a broad sample of the community. # How can I apply? To apply for one of these positions, send an email to clc.nominations.2023(a)gmail.com that consists of the following data: * The header “CLC Election January 2023 - {your name}”. * Why you think you’re a good fit given the above criteria. * If applicable, please point us to some code you’ve written. Please apply before Feb 1. Best regards, Andrew

1 0

[TFP 2023 Call For Participation] 24th International Symposium on Trends in Functional Programming
by Peter Achten 02 Jan '23

02 Jan '23

# TFP 2023 -- Call For Participation (trendsfp.github.io) ## Dates Registration: Friday 6th January, 2023 TFPIE Workshop: Thursday 12th January, 2023 TFP Symposium: Friday 13th - Sunday 15th January, 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. ## 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

Special holiday Munich Haskell Meeting, 2023-01-04 @ 19:30
by Leah Neukirchen 30 Dec '22

30 Dec '22

Dear all, Next week, our special holiday Munich Haskell Meeting will take place on Wednesday, January 4 at Augustiner-Gaststätte Rumpler at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this nuudel so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://nuudel.digitalcourage.de/cs8eLiDLkwZEd5hO Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

[Haskell] [ANNOUNCE] Haskell Language Server 1.9.0.0 released
by Zubin Duggal 26 Dec '22

26 Dec '22

Binaries for this release are available at https://downloads.haskell.org/~hls/haskell-language-server-1.9.0.0/ The prebuilt binaries in this release support the following GHC versions: - 8.10.7 - 9.0.2 - 9.2.5 - 9.4.3 - 9.4.4 These binaries can be installed using [GHCup](https://www.haskell.org/ghcup/) or version [2.0.0 and above](https://github.com/haskell/vscode-haskell/releases) of the VSCode extension. ## Changelog - Binaries for GHC 9.4.3, GHC 9.4.4 and GHC 9.2.5. - Dropped support for GHC 8.8 and GHC 8.10. - New plugins including: - Expanding record wild cards using hls-explicit-record-fields-plugin (#3304). - Formatting cabal fields using cabal-fmt via hls-cabal-fmt-plugin (#2047). - Warnings and errors for cabal files using hls-cabal-plugin (#2954). - Folding ranges using hls-code-range-plugin (#3058). - Support for many plugins like the refactor, splice, retrie, gadt, hlint, fourmolu and class plugins. - Completion for record dot fields (#3080). - Performance and memory usage improvements. - And many more bug fixes and improvements! For the full release notes, see https://github.com/haskell/haskell-language-server/releases/tag/1.9.0.0

1 1

[ANNOUNCE] GHC 9.4.4 is now available
by Ben Gamari 25 Dec '22

25 Dec '22

The GHC developers are happy to announce the availability of GHC 9.4.4. Binary distributions, source distributions, and documentation are available at downloads.haskell.org [1]. This release is primarily a bugfix release. Bugs fixed include: * An issue where the wrong labels were used in the eventlog for events emitted when using info table profiling which was broken in 9.4.3 (#22452) * Fix a long standing bug where invalid eventlogs would be produced with long command-lines (#20221) * Fix a regression in eta-expansion which resulted in serious performance regressions in 9.4.3 (#22424) * Fix the `-fdefer-diagnostics` flag (#22391) * Fixes to several subtle compiler panics (#22491, #22416, #22549, #22475, #22039) * Add necessary write barriers to `IORef` operations, avoiding potential soundness issues on architectures with weakly-ordered memory models (#22468) Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new Hadrian build system, it is 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]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC's Windows toolchain. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, 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 Haskelling, - Ben [1]: https://downloads.haskell.org/ghc/9.4.4 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

2 3

Meetup in Bay area
by Ivan Perez 23 Dec '22

23 Dec '22

Hi, Is there a Haskell or FP meetup in the Bay area? Cheers, Ivan

2 1

lens and Maybe value
by PICCA Frederic-Emmanuel 20 Dec '22

20 Dec '22

Hello, I have a data whcih contain a Maybe value data A = A (_a = Maybe a) I would like to use a lens in order to merge two values with this log replace the value only if it is a (Just a) So My question is is there something more elegant than let myA' = case ma of Nothing -> conf (Just na) -> (a .~ na) myA Thanks for your help Frederic

4 10

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 232, Issue 6
by Douglas McIlroy 19 Dec '22

19 Dec '22

This note is to suggest an approach to introducing Haskell. It is not a pitch for a gig to do so. A big selling point for Haskell is how clean and simple some kinds of Haskell code are. My personal hobby horse of this type is stream processing. Lazy evaluation makes for dramatic simplification, as can be seen in a couple of offerings on my website. I have given talks based on this theme to (mathematically inclined) audiences who have absolutely no Haskell nous. For folks who know freshman calculus, power series computations in Haskell are an eye-opener--no fussing with storage allocation and no subscripts at all! Only rudimentary Haskell ideas need to be discussed to make these functions intelligible. https://www.cs.dartmouth.edu/~doug/powser.html. Another Haskell example, a basic prime-number sieve, reduces a page of C code, or a half-page of shell script to two elegant lines of code. https://www.cs.dartmouth.edu/~doug/sieve/sieve.pdf Doug McIlroy On Mon, Dec 19, 2022 at 7:19 AM <haskell-cafe-request(a)haskell.org> wrote: > > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Request for a presentation on Haskell (Jonathan Drews) > 2. Re: Request for a presentation on Haskell (Ivan Perez) > 3. Re: Request for a presentation on Haskell (Jonathan Drews) > 4. Re: Request for a presentation on Haskell (Ivan Perez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 18 Dec 2022 18:13:02 -0700 > From: Jonathan Drews <jondrews(a)fastmail.com> > To: haskell-cafe(a)haskell.org > Subject: [Haskell-cafe] Request for a presentation on Haskell > Message-ID: <Y5+6ntGmiRUZ4xd1(a)leo.my.domain> > Content-Type: text/plain; charset=us-ascii > > Hi Folks: > > I would like to know if anyone from the Haskell organization would > like to give a presentation on Haskell to our BSD User Group (BSD = > Berkeley Software Development). We are the South Eastern Michigan BSD > User Group (http://www.semibug.org/) Myself and several other members > are very intereested in Haskell and would like to learn more about > this language. > > You would make the presentation online, by means of Jitsi. The date I > am hoping for is January 17th, 2023. I can move that date if need be. > The talks are usually given in the evenings. Contact me off list for > more details. > > Thanks in advance. > > -- > Kind regards, > Jonathan > > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > > > > ------------------------------ > > Message: 2 > Date: Sun, 18 Dec 2022 20:02:35 -0800 > From: Ivan Perez <ivanperezdominguez(a)gmail.com> > To: Jonathan Drews <jondrews(a)fastmail.com>, Haskell Cafe > <haskell-cafe(a)haskell.org> > Subject: Re: [Haskell-cafe] Request for a presentation on Haskell > Message-ID: > <CACZKWELYiL7qUP_qJ733PhZHHRcve0-OYO6iV8PZdMt5Lj5sSA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Jonathan, > > I might be available, if you are interested. Most of my work is > Haskell-centric. I've made commercial games and apps (mobile, desktop, > web). In the last 5y I've focused on runtime monitoring and language > transformation (very broadly speaking). > > See https://ivanperez.io/ for details. > > If you are interested, we can continue the discussion off-list. > > Thanks, > > Ivan > > On Sun, 18 Dec 2022 at 17:13, Jonathan Drews <jondrews(a)fastmail.com> wrote: > > > Hi Folks: > > > > I would like to know if anyone from the Haskell organization would > > like to give a presentation on Haskell to our BSD User Group (BSD = > > Berkeley Software Development). We are the South Eastern Michigan BSD > > User Group (http://www.semibug.org/) Myself and several other members > > are very intereested in Haskell and would like to learn more about > > this language. > > > > You would make the presentation online, by means of Jitsi. The date I > > am hoping for is January 17th, 2023. I can move that date if need be. > > The talks are usually given in the evenings. Contact me off list for > > more details. > > > > Thanks in advance. > > > > -- > > Kind regards, > > Jonathan > > > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > ~ > > > > _______________________________________________ > > 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. >

1 0

Request for a presentation on Haskell
by Jonathan Drews 19 Dec '22

19 Dec '22

Hi Folks: I would like to know if anyone from the Haskell organization would like to give a presentation on Haskell to our BSD User Group (BSD = Berkeley Software Development). We are the South Eastern Michigan BSD User Group (http://www.semibug.org/) Myself and several other members are very intereested in Haskell and would like to learn more about this language. You would make the presentation online, by means of Jitsi. The date I am hoping for is January 17th, 2023. I can move that date if need be. The talks are usually given in the evenings. Contact me off list for more details. Thanks in advance. -- Kind regards, Jonathan ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

2 3