August 2021 - Haskell-Cafe

ghcup and XDG support
by Sven Panne 22 Aug '21

22 Aug '21

The ghcup-hs README contains a rather nebulous remark ( https://github.com/haskell/ghcup-hs#xdg-support) Note that ghcup makes some assumptions about structure of files in XDG_BIN_HOME. So if you have other tools installing e.g. stack/cabal/ghc into it, this will likely clash. In that case consider disabling XDG support. Which assumptions does it make? What will clash and when? I very much prefer XDG-style installations, but I don't want to find out the downsides the hard way afterwards... ;-) Cheers, S.

1 0

Re: [Haskell-cafe] Maintainership of 3 packages on Hackage by Adjoint Inc
by Sumit Raja 21 Aug '21

21 Aug '21

Hi Ivan, Stephen Diehl (https://github.com/sdiehl) has been very helpful in the past with these packages. I haven't seen any activity from other Adjoint members in a while. Maye Stephen is on this list and can help. As an aside, are you using these libraries for research purposes or in the wild? I'm interested in their suitability for non-research purposes or if something like blst (https://github.com/supranational/blst) with a Haskell FFI wrapper is more suitable/secure. Regards Sumit Message: 2 > Date: Thu, 19 Aug 2021 20:48:08 +0300 > From: Ivan Gromakovskii <ivan(a)serokell.io> > To: haskell-cafe(a)haskell.org > Subject: [Haskell-cafe] Maintainership of 3 packages on Hackage by > Adjoint Inc > Message-ID: <7c42266b-8747-e980-c1e5-5036f8b314e3(a)serokell.io> > Content-Type: text/plain; charset="utf-8" > > Hello, > > I am a Haskell software developer and I use some packages maintained by > Adjoint Inc from Hackage. Specifically, I am interested in 3 packages: > > • elliptic-curve <https://hackage.haskell.org/package/elliptic-curve> > > • pairing <https://hackage.haskell.org/package/pairing> > > • galois-field <https://hackage.haskell.org/package/galois-field> > > Latest versions of these packages have upper bound restrictions on their > dependencies which do not allow to build them with latest versions > available on Hackage. For two packages these restrictions are already > updated in the source repos on GitHub, they just need to be updated on > Hackage. For the third one I opened a PR > <https://github.com/adjoint-io/galois-field/pull/32> on GitHub. > > I opened an issue > <https://github.com/adjoint-io/elliptic-curve/issues/21> about updating > elliptic-curve and commented > <https://github.com/adjoint-io/pairing/issues/21> another one about > pairing. Unfortunately, both issues were closed even though Hackage > versions were not updated. My PR wasn't closed, but apparently I was > banned or something because now I can't write comments there. > > Since I was unable to get any information on GitHub, I tried to contact > the maintainer by email (info(a)adjoint.io) written in the "maintainer" > field in all 3 packages, saying that I can make all the updated myself > if they give me permission. Unfortunately, this email address doesn't > seem to work because I got "Delivery Status Notification (Failure)" in > response. > > So it looks like these packages are effectively unmaintained, but > require some maintenance. I found the "Taking over a package > <https://wiki.haskell.org/Taking_over_a_package>" page which is exactly > about my case. I think I am in the situation where I cannot contact the > author/maintainer, that's why I am writing to Haskell Cafe. I can't CC > the maintainer (info(a)adjoint.io) because the address simply doesn't > exist. If anybody on the mailing list can reach out to Adjoint, please > do that, I'll be very thankful. > > Best, > > Ivan >

1 0

Call for Participation: Haskell Implementors' Workshop 2021
by Ningning Xie 20 Aug '21

20 Aug '21

Call for Participation ACM SIGPLAN Haskell Implementors' Workshop Sunday 22 Aug 20:00-05:00 (Seoul) https://icfp21.sigplan.org/home/hiw-2021 We are happy to announce that Haskell Implementors' Workshop is taking place this Sunday, co-located with ICFP 2021. The workshop will be live streamed on Youtube. We invite you to watch the talks, and attend the workshop. The program features 11 exciting talks, along with 4 lightning talks. The keynote is given by Bengt Marten Agren (Standard Chartered Bank), on "Haskell reinterpreted – large-scale real-world experience with the Mu compiler in Financial Markets". Program details: https://icfp21.sigplan.org/home/hiw-2021#program Keynote details: https://icfp21.sigplan.org/details/hiw-2021-papers/14/Haskell-reinterpreted… Program Committee ----------------- * Dominique Devriese (Vrije Universiteit Brussel) * Daan Leijen (Microsoft Research) * Andres Löh (Well-Typed LLP) * Julie Moronuki (Typeclass Consulting) * John Wiegley (DFINITY) * Ningning Xie (the University of Hong Kong) * Edward Z. Yang (Facebook AI Research) Contact ------- * Ningning Xie <xnningxie(a)gmail.com>

1 0

Maintainership of 3 packages on Hackage by Adjoint Inc
by Ivan Gromakovskii 19 Aug '21

19 Aug '21

Hello, I am a Haskell software developer and I use some packages maintained by Adjoint Inc from Hackage. Specifically, I am interested in 3 packages: • elliptic-curve <https://hackage.haskell.org/package/elliptic-curve> • pairing <https://hackage.haskell.org/package/pairing> • galois-field <https://hackage.haskell.org/package/galois-field> Latest versions of these packages have upper bound restrictions on their dependencies which do not allow to build them with latest versions available on Hackage. For two packages these restrictions are already updated in the source repos on GitHub, they just need to be updated on Hackage. For the third one I opened a PR <https://github.com/adjoint-io/galois-field/pull/32> on GitHub. I opened an issue <https://github.com/adjoint-io/elliptic-curve/issues/21> about updating elliptic-curve and commented <https://github.com/adjoint-io/pairing/issues/21> another one about pairing. Unfortunately, both issues were closed even though Hackage versions were not updated. My PR wasn't closed, but apparently I was banned or something because now I can't write comments there. Since I was unable to get any information on GitHub, I tried to contact the maintainer by email (info(a)adjoint.io) written in the "maintainer" field in all 3 packages, saying that I can make all the updated myself if they give me permission. Unfortunately, this email address doesn't seem to work because I got "Delivery Status Notification (Failure)" in response. So it looks like these packages are effectively unmaintained, but require some maintenance. I found the "Taking over a package <https://wiki.haskell.org/Taking_over_a_package>" page which is exactly about my case. I think I am in the situation where I cannot contact the author/maintainer, that's why I am writing to Haskell Cafe. I can't CC the maintainer (info(a)adjoint.io) because the address simply doesn't exist. If anybody on the mailing list can reach out to Adjoint, please do that, I'll be very thankful. Best, Ivan

1 0

Re: [Haskell-cafe] Fwd: Unlock instructions
by Amy de Buitléir 19 Aug '21

19 Aug '21

I got one of those emails as well, and I don't remember setting up an account there.

1 0

Assistant/Associate Professorships in Nottingham
by Graham Hutton 16 Aug '21

16 Aug '21

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 or Associate Professor level: https://tinyurl.com/wruwpnpt https://tinyurl.com/284svw4y Applications in the area of the Functional Programming (FP) lab are strongly encouraged! The FP lab is keen to receive applications from candidates with an excellent publication record (e.g. papers in leading venues such as LICS, POPL, ICFP, JFP, TOPLAS, etc) and the ability to secure external funding to support their research. Further information about the FP lab is available from: https://tinyurl.com/y2ekdkqa The deadline for applications is Monday 20th September 2021. The advert mentions some specific research areas, but the positions are open to applicants from any area of Computer Science. -- 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.

1 0

Parsing XML
by John Arnold 15 Aug '21

15 Aug '21

I am building a prototype for processing ISO 20022 Payment Initiation messages. These messages are in XML format and I want the prototype to be built using Haskell. Conducting a search for 'Haskell XML parsing' yields postings that are in the region of 10+yrs old. I am sure there are packages that have been developed/update in the recent past. Any thoughts?

8 7

Deprecation being transitively reported for re-exported definitions
by Ivan Perez 15 Aug '21

15 Aug '21

Hello Café, TL;DR: should the deprecation GHC option be transitively reported for re-exported definitions? I have a library that is exposing too much. As a minimal example, say the library contains: - Module A, which defines several functions and types. - Module B, which exports *specific definitions* from module A and has none of its own. It so happens that, to keep things as clean and abstract as possible, only module B should be exposed. As per library policy, we give users time to adapt. A way to do that would be to deprecate module A, but configure B to ignore deprecations (-Wno-deprecations) so GHC does not complain during the compilation of the library itself. My expectation was that library users who imported *A directly* would get a warning, but importing definitions in A *via B* would not give out any warnings. That, however, is not what is happening: In the use of ‘functionInA’ (imported from B, but defined in A): Deprecated: "This module will be hidden in future versions." There are "workarounds": I could move all definitions in A to new module C, deprecate A, and re-export C in B, or I could re-define the exported definitions in B as identities of those in A (easy for functions, probably more cumbersome for data constructors or classes.) However, more generally, if you use a function from A in a NEW function definition in B and then export *that second definition instead*, the compiler won't tell *the library user* that B is internally relying on a deprecated function. Reexporting a function without changes could conceptually be seen as an "extreme" case of that, where where the name and the implementation in B coincide with those in A. So I ask: should deprecation work the way it is working in the first place? All the best, Ivan

5 6

Functional Art, Music, Modeling and Design (FARM 2021) Aug 21: Call for Participation
by Daniel Winograd-Cort 14 Aug '21

14 Aug '21

====================================================================== FARM 2021 9th ACM SIGPLAN International Workshop on Functional Art, Music, Modeling and Design 27 August, 2021, co-virtual with ICFP 2021 https://functional-art.org/2021/ ====================================================================== The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. Registration ------------ You can register via the ICFP 2021 registration: http://icfp21.sigplan.org/attending/registration Don't be confused that it says ~ICFP~ - FARM is part of a larger event around ICFP 2021, and you can register for FARM without registering for ICFP. Keynote ------- Phoenix Perry will hold the keynote. Accepted papers --------------- minimum: a self-extensible programming language for sound and music Tomoya Matsuura and Kazuhiro Jo MidifilePerformer: a case study for chronologies Juliette Chabassier, Myriam Desainte-Catherine, Jean Haury, Marin Pobel and Bernard Serpette Temporal-Scope Grammars for Polyphonic Music Generation Lukas Eibensteiner, Martin Ilčík and Michael Wimmer The W-calculus: A Synchronous Framework for the Verified Modelling of Digital Signal Processing Algorithms Emilio Jesus Gallego Arias, Pierre Jouvelot, Sylvain Ribstein and Dorian Desblancs Human-in-the-loop Program Synthesis for Live Coding Mark Santolucito Live Performances ----------------- FARM 2021 will feature a session of live performances: - John Leo, Logical Soundness - Emiddio Vasquez, Title TBA - José Miguel Fernandez, Homotopy Workshop Organisation --------------------- Workshop Chair: Daniel Winograd-Cort (Luminous Computing) Program Chair: Jean-Louis Giavitto (IRCAM Paris) Publicity Chair: Michael Sperber (Active Group GmbH) Performance Chair: John MacCallum (HfMT Hamburg)

1 0

[Haskell] [ANNOUNCE] GHC 8.10.6 released
by Zubin Duggal 14 Aug '21

14 Aug '21

The GHC team is very pleased to announce the availability of GHC 8.10.6. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.6/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_6.html Blog Post: https://www.haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html This is a bugfix release, fixing many issues present in GHC 8.10.5, including: - A fix for segmentation faults in GHCi on `aarch64-darwin` due to an incorrect foreign import in `haskeline`. See [this blog post](https://www.haskell.org/ghc/blog/20210709-capi-usage.html) by Ben Gamari for more details on how your library could be affected. - A fix for a critical bug affecting Haskell Language Server (HLS) among other applications caused by missing RTS symbols required for statically linked builds of the GHC library (#19763). - No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were actually supported (#19973, #19829, #19959). - Numerous bug fixes for the new LLVM based `aarch64-darwin` backend (#20132). - Fixes and stability improvements for the non-moving GC (#19715). - Many other bug fixes for the RTS (#18033, #20132, #20093, #19421). - Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `integer-simple` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Previous releases were still linked against the `GMP` library due to a misconfiguration of the builders. - A significant refactoring of `process` fixing numerous bugs mostly on Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)) - A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build (#19958, #19948). - Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950). A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.6/docs/html/users_guide/8.10.…. As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0